Hi Dee,

'Lion' and 'Swim' were placeholder error messages that I never got round to fleshing out.

The good news is that I've updated the error messages now, and they should also point to a line number.

'Lion' was an error message that should have informed you that the block_when (or block_when_not) conditions have to reference a regular boolean (that you can set true and false) rather than a dynamic boolean. This is down to the 8-bit game engine not supporting them. It should be easy to avoid using dynamic booleans in this context.

'Swim' is a little interesting because I don't see anything in your code that should trigger it. I've rewritten the message as this now.

Block condition invalid, supported conditions are:
      'block_when', 'block_when_not', 'block_when_carried',
      'block_when_not_carried', 'block_when_not_exists',
      'block_when_exists', 'block_when_worn', &
      'block_when_not_worn'.

but, as I say, in your included code, I don't see you not using one of those conditions.

When you see the (above) message, look at the line number of the error, and send me the block code that is failing (you can switch out any specific text that is secret of course).

Let me know how you get along.

Hi Christopher,

(1) I'll take a look at the line breaks.

(2) No changing of colour yet in the 8-bit export to DAAD, but I will look at that too.

(3) Yes, there is no headerbar in the export with graphics mode. Please do set the header for each of your locations on the understanding that you'll have the option of a title bar, or to include your location header as a prefix to your location description, in capitals, in a future version.

Thanks for your reports. Hopefully none of these issues block your game, and glad to hear you are sanity checking the output of the exporter early.

Chris

I made an update to the exporter. The append mode should now work on the exporter (not putting the output on different lines).

There is a chance.

Regarding local event handlers not working on export to DAAD, one of the DAAD guys mentioned that in one of the previous game jams, so I stopped using them. I now put all event handlers in the global event handlers. The only downside is that you have to do an is_at test where appropriate. The upside is that all my event handlers are now in one place, so it's easier to manage.

Question for Chris: Is this still the case? If so, it might be worth mentioning in the guide on 8-bit export, assuming it's not already in there.

Thanks for the reports Dee.

1) The first issue is down to DAAD (and a lot of other 8 bit text adventure systems) only using the first 5 letters for words. I need to pre-validate this before exporting a little bit better, and document this gotcha too (which upon review I did not document).

That said, nouns and verbs should be able to overlap in the converter

For example, in excalibur, you must type:

OIL WINCH (oil is verb)

and 

GET OIL (oil is noun)

2) I'll check this out.

3) They should be working. Are they verb or noun aliases that are not working or something else?

I see that the ZX Spectrum +3 / Next emulator is available for Linux.

https://github.com/chernandezba/zesarux/releases

The first 5 letters of a word should be unique.

This doesn't work (in 8-bit mode) yet, but I'll work on mapping is_within_direct {}.

start_at = lake
locations {
   forest : location "You are in a forest." ;
   lake   : location "You are by a lake" ;
}
objects {
   lamp  : object "a lamp" at = "forest" ;
}
connections {
   from, direction, to = [
      forest, south, lake, 
   ]
}
on_tick {
   : if (is_within_direct { outer -> ( "forest" ) inner -> ( "lamp" )  }) {
      : print "The lamp is in the forest (directly)." ;
   }
   : else {
      : print "The lamp is NOT in the forest (directly)." ;
   }
}

Here's another hacky way to test if the NPC is in another room. I'm pretty sure this will work in 8-bit mode.

   : match "test me" {
      : goto "new_room";
      : if (is_beside "npc") {
         : print "The npc is there.";
      }
      : else {
         : print "The npc isn't there.";
      }
      : goto "old_room";
      : done;
   }

Regarding items in containers, I do this a lot. Here is some sample code from 'Seeker of Magic'. It is probably more complicated than what you need, but you can simplify it to suit your needs. You start out with a tin box. The tin box can be opened and closed. If you examine it when it is initially opened, you can see that it contains a silver key and a parchment. You can take these, providing you have room in your inventory, but you can't put them back again. (This is the only down side.) Note that there is only one boolean used to keep track of the state of the tin box. It uses has_not_created to keep track of whether or not the objects have been removed from the box.

// Tin box
   : match "examine box" {
      : if (is_present "tin_box") {
         : append "It's dark grey and dusty from the ashes. ";
         : if (is_box_open) {
            :if (has_not_created "silver_key" && has_not_created "parchment") {
               : print "It contains a silver <key<13>> and a <parchment<13>>.";
               : done;
            }
            :if (has_not_created "silver_key") {
               : print "It contains a silver <key<13>>.";
               : done;
            }
            :if (has_not_created "parchment") {
               : print "It contains a <parchment<13>>.";
               : done;
            }
            : print "It's empty.";
            : done;
         }
         : else {
            : print "It's closed.";
            : done;
         }
      }
   }
   : match "open box" {
      : if (is_present "tin_box" && is_box_open) {
         : print "It's already open.";
         : done;
      }
      : set_true "is_box_open";
      :if (has_not_created "silver_key" && has_not_created "parchment") {
         : print "It contains a silver <key<13>> and a <parchment<13>>.";
         : done;
      }
      :if (has_not_created "silver_key") {
         : print "It contains a silver <key<13>>.";
         : done;
      }
      :if (has_not_created "parchment") {
         : print "It contains a <parchment<13>>.";
         : done;
      }
      : print "It's empty.";
      : done;
   }
   : match "close box" {
      : if (is_present "tin_box" && !is_box_open) {
         : print "It's already closed.";
         : done;
      }
      : set_false "is_box_open";
      : print "It's now closed.";
      : done;
   }
// Key
   : match "examine key" {
      : if (is_present "silver_key" || (is_present "tin_box" && is_box_open && has_not_created "silver_key")) {
         : print "It looks like it's made of silver.";
         : done;
      }
   }
   : match "get key" {
      : if (is_present "tin_box" && is_box_open && has_not_created "silver_key") {
         : if (items_carried() < item_limit()) {
               : pocket "silver_key";
               : print "You take the <key<13>> out of the tin <box<13>>.";
               : done;
         }
         : else {
            : print "You can't carry any more.";
            : done;
         }
      }
   }
// Parchment
   : match "examine parchment" {
      : if (is_present "parchment" || (is_present "tin_box" && is_box_open && has_not_created "parchment")) {
         : print "It's dry and brittle and slightly singed around the edges.";
         : done;
      }
   }
   : match "get parchment" {
      : if (is_present "tin_box" && is_box_open && has_not_created "parchment") {
         : if (items_carried() < item_limit()) {
               : pocket "parchment";
               : print "You take the <parchment<13>> out of the tin <box<13>>.";
               : done;
         }
         : else {
            : print "You can't carry any more.";
            : done;
         }
      }
   }

Are you using "1" as a noun in the game? There should not be a problem with that in theory.

I'm not time rich at the moment, but if you can send me a cut-down version of your adventuron source that can replicate this downstream error, then I'll happily take a look for you.

info@adventuron.io

The code for DAAD is wrong: AUTOG should not depend on the test: AT treestand; It is right if I set Get before the test:

: match "get ladder"  {
   : if (is_beside "ladder") {
      : get ;     
      : if (is_at "treestand") {
         : set_graphic graphic = "treestand2"  target = "treestand" ;         
      }
   }
}

/PRO 11
> _      _    SET has_done_something_
              AUTOG
> _      _    AT treestand
              LET 18 255 LET 19 10

I've got a feeling that PULL and PUSH are built-in verbs, but I'm not certain. At any rate, you only need one statement:

: verb / aliases = [move, pull, push, turn]

You're right, there is currently no way to test for the state of a door., and those event handlers (on door) are not currently mapped in 8-bit mode.

I'll see what I can do at my end, but it'll probably be a week before I can look at this.

You can work around this by manually coding a door, or possibly by using the door_operation function (if it's possible).

This should get you started if you want to take this path (remove the door from the barrier section).

// Boolean section
booleans {
   is_door_locked : boolean "true";
   is_door_open   : boolean "false";
}
// In on_command{} section
: match "open door" {
   // Code your open door logic here
}
: match "close door" {
   // Code your close door logic here
}
: match "unlock door" {
   // Code your unlock door logic here
}
: match "lock door" {
     // Code your lock door logic here
}
// Direction that door is blocking
: match "n _" {
   : if (is_at "your_location_id" && is_door_open == false) {
     // This manually blocks (without using the blocks {} section
     : print "The door is in your way";
     : done;
   }
}

That sounds like a question for Chris. I can't find any way of testing the state of doors. I've done lots of doors, but I always do it manually so that I'm fully in control and my doors are bidirectional. It's pretty easy. Do you want me to post some sample code? If so, is your door lockable? (It sounds like it is.)

You can use an "open/unlocked door" object and a "closed/locked door" object and reuse them in other parts of the game.

When a door is unlocked, I prefer it to be opened automatically as well.

That was just the first example that came to mind. I've had no end of trouble with implicit actions doing stupid things (as a player), so I avoid them like the plague (as an author). I've had quite a few games where I've come to write up the solution and the solution in my notes didn't work because the game had done some sort of implicit action that I was completely oblivious of and I had to do endless trial and error to try and work out what it was.

No thank you. No unexpected surprises in my games. If you want to see if the door is locked, try OPEN DOOR. If it's locked it will tell you. It won't magically select the long brass key from the key ring stored in your backpack and unlock and open the door on your behalf. If you want to unlock the door, you have to say so and you have to say how you want to unlock it. And if you want to open the door, you have to explicitly say OPEN DOOR.

Looking at this too (I think I didn't print out the wearing message properly).