z2

As I'm sure most ZZT game-makers who had any particular emphasis on the code aspect in ZZT-OOP will recall you can actually use directional commands on an 'if at all possible' basis.
I'm sure you know the hassles of having an object that is supposed to go one way or another (or follow a route) for a specific period of time only to be stopped up by a wall getting in their path.
They wait for it to be no longer in the way and do not even process commands yet still respond to labels until they can fulfill this directional movement command...
This is a very unusual quirk as far as 'command completion' goes in ZZT-OOP (and by extension ZZT's engine)...
as it allows for 'completion of executed code' to be highly subjective to what else is going on ingame even other than its own code...
and thus shows us that ZZT is so highly abnormal in coding even down to its individual movements on board space.
There is always your alternative 'question marked' movement commands...
Whereas your other type will wait until the command is possible to perform this type will do it exactly at that time but only if it will actually result in movement and otherwise proceed to next lines of code.


One would think that this means that this 'question marked' type of directional commands is far less glitchy in nature than that 'slash marked' type of directional commands.
One would think.
Though then there is another very old yet so quickly forgotten trick to this... and
as far as I know it only works with this 'question marked' type of directional commands.


You can move multiple spaces in the same cycle.
If you so much as preface your object to take only one cycle per code command (generally by prefacing it ''#cycle 1'' very near its top line of code, though some take to actually editing 'cycle' in its 'tile properties', taking advantage of abilities of 'ZZT editors' other than ZZT's editor itself such as KevEdit to add new functionality that is already present in ZZT that's not otherwise possible to have access to) and then use plenty of 'question marked' type of directional commands all in a row they will process them all at once in that same individual cycle.
As I recall they don't even have to be on the same individual line.
As long as they aren't broken up by any 'idle' directions they happen in the same cycle.


''?seek?seek?seek?seek?seek/i?seek?seek?seek?seek?seek/i?seek?seek?seek?seek?seek/i?seek?seek?seek?seek?seek/i'' would follow the player very quickly and ''?opp seek?opp seek?opp seek?opp seek?opp seek/i?opp seek?opp seek?opp seek?opp seek?opp seek/i?opp seek?opp seek?opp seek?opp seek?opp seek/i?opp seek?opp seek?opp seek?opp seek?opp seek/i'' would do pretty much its opposite.
However then ''?seek?seek?seek?seek?seek?i?seek?seek?seek?seek?seek?i?seek?seek?seek?seek?seek?i?seek?seek?seek?seek?seek?i'' would give the player no chance to hide behind a wall or what have you and ''?opp seek?opp seek?opp seek?opp seek?opp seek?i?opp seek?opp seek?opp seek?opp seek?opp seek?i?opp seek?opp seek?opp seek?opp seek?opp seek?i?opp seek?opp seek?opp seek?opp seek?opp seek?i'' would give the player virtually no time to be able to chase them.
When you have even 'idle' directional commands used in this same manner then it tries to determine on an 'if it can be at the time' basis even for whether or not it can wait, and generally determines that it can't because it is supposed to be done all in one cycle anyway, thus discarding its own 'cycle timers' and proceeding to process directional commands all in the exact same cycle.
This is a very unusual quirk in code.


However then I see potential to push 'ZZT Encyclopedia' type of stuff even further than was done in games past, proving that there is still more 'no limits' type of stuff to be found in this very same ZZT engine, if it proves at all possible to use this quirk for more than directional commands.
Would it be possible to use the nature of using 'idle direction' on this 'question marked' type of directional commands for things other than mere board movement in objects?
Imagine you have a series of decoupling timers combined with a series of recoupling timers, in objects on a board, that function in a harmony of a specific reorganization of a lack of harmony by alternating when they use ''/i'' idle and '?i'' idle between their operations towards one another to 'lag down' ZZT's game itself far enough to cause something along the lines of a temporal spacetime warp thus allowing the player tile itself to make use of 'moving multiple spaces at once' or other such things...
You might be able to make more use of more obscure uses of player clones that's for sure... as we've seen them used for 'teleporting your player' in plenty of ZZT games since Flik... but little has been used of more obscure uses of player clones such as 'objects making lit bombs' as seen in ZZT Encyclopedia's third installment...

Just some more bits of cool info to augment your findings.

ZZT OOP keeps track of things that will end a cycle:

- More than 32 commands have been executed. Multiple commands can be on one line. Jumping to a label is considered a command.
- The object has moved. Even /i will trigger this.
- The code is considered finished- for example, #end.
- The object has died. #become triggers this as well. If this flag is set, some extra code is executed at the end. (This is what causes a Scroll to crash if you have a #become or #die command.)
- The object's current instruction is out of bounds (must be >= 0 and < length). An object that executes #end will have its instruction set to -1, but hitting the end of the code will also trigger this condition.
- The code is empty for some reason. Barring corruption, this should never actually happen. (But it does, and I anticipate that instead of solving the source, he just put this in as a failsafe.)

If ?seek fails, this counts as one command, and it will execute the next. #try and ? do not have the same code, and neither do #go and /i. Amusingly, if you #try idle, it will fail and jump to the label. If you #go idle, the object will hang. I'm not sure if ?i fails.

#go and / are very nasty commands for lag. Here's why: if movement fails, the instruction pointer is not moved. If it is trying to execute a move, it will execute this move until the object's commands are consumed. If it tries to move into a square it cannot, the other 31 commands are spent trying to repeat this process. Multiply this by many objects at once and you have a very big performance issue. This is the reason Aura is slow at times. This is also why it seems when you use /rndp rndne, it never seems to fail. That's because if it's up against a wall, it's trying to move a few times. Movement will always end the cycle, however. So one successful move costs far less than 32 failed moves.

Also, I'd like to mention that the Step code is executed completely separately to OOP. You set these values with #walk. This code is, IIRC, executed before OOP is. That's why you see a one cycle latency when you change these values.

One last thing. Jumping to a label actually jumps to the newline just before the label text. This is why when you use jumps, you see gaps in your text output. This is also why you can't jump to a label on the topmost line- there is no preceding newline.

Saxxon wrote:This is also why it seems when you use /rndp rndne, it never seems to fail. That's because if it's up against a wall, it's trying to move a few times. Movement will always end the cycle, however. So one successful move costs far less than 32 failed moves.

This I think explains a problem I was having once. This sort of info is good. There are many ways for inexperienced programmers to lag zzt. Also I really appreciate a good object AI, which is tough in zzt. I was always trying to have enemies that would dodge, seek cover etc, or at least seem like they were doing that.

Some object behaiour is a tad annoying, like the no shooting objects in front of you, and the centipede's tendency to turn when it bumps into your bullet.

The unable-to-shoot-adjacent bug is due to the SpawnProjectile function checking to see if the target location is destructible. Players are destructible and objects are not. The reason your player doesn't get killed but you can kill clones is there's a part in the code specifically for Thing #0, which deducts health instead of kills it.

The centipede bug is just as a result of Thing precedence. A centipede head is coded to always go somewhere. If it can't go in the direction it wants, it finds somewhere else to go. This is contrary to a lot of the other enemy code: if they can't move where they want, they simply don't move that cycle. Most enemies will not move into non-floor spaces (bullets, sharks, stars and bears have additional code for this.)

I'm away from zzt now, but I'm forgetting a detail of the stat list. If I created a bunch of objects, then centipedes, the centipedes would be at the end of the list, updated last, but if I then delete the objects created before this, do the centipedes maintain their position on the list (i.e. so created bullets would have a lower index) or does the list collapse to fill gaps? If I can't do this in the editor could I create the gap at runtime with a bunch of objects that destroy themselves?

Commodore wrote:I'm away from zzt now, but I'm forgetting a detail of the stat list. If I created a bunch of objects, then centipedes, the centipedes would be at the end of the list, updated last, but if I then delete the objects created before this, do the centipedes maintain their position on the list (i.e. so created bullets would have a lower index) or does the list collapse to fill gaps? If I can't do this in the editor could I create the gap at runtime with a bunch of objects that destroy themselves?

ZZT fills gaps. New Things are always created at the end of the list. This actually causes some amusing memory corruption when a Thing is accessed by index and not by reference, and a deletion takes place somewhere in the routine (for example a #put which deletes an object and then subsequently moves- this is what causes that Enigma bug I was hunting so long for.)

Unfortunately, insertion into the Thing list is not possible.

I realize it sounds weird to use the term "Thing" to describe a stat object, but it's the terminology used in Roton.

"Thing" is a wonderful word! And your posts are wonderfully informative -- thanks for doing the research.

I had no idea that / could be bad for lag.

You guys are waaaaay more experienced than I am at this and now I feel like an idjot for bringing this up and talking philosophically on proespects of code that others have already figured out.
Thanks for helping to remind me of my ambitions to ever be that good at code (even if it's only ZZT's code... ).

That wasn't supposed to be discouraging :) I have just been digging around in the disassembly of ZZT for a couple years already. Almost all of ZZT is mapped out, and a good portion of SuperZZT (mostly just the differences in code).

I wouldn't like to consider myself the authoritative source of information for the inner workings of ZZT, but I will say I know a lot. :)