Which will access the array only once as opposed to four times. However, the way it is originally written can create some very interesting results. Suppose the global ActIndex is changed halfway through a function by another function during execution. Two different and unrelated objects will be manipulated! This can (and does, but rarely) happen in the original code.

When left as it is in the original engine, there would be unforeseen side effects when objects are deleted.

When the player is energized, the base properties for the player element are actually modified. This means if you have "dead" players (players with no stats) then whenever they are drawn they will have whatever character the player is set to have.

If a player enters a board while energized and the player character is set to 1, all the dead smileys on that board will have char 1. When the player is not energized, dead players will always have a char of 2.

In the past week I rewrote everything from the ground up. Much better compatibility this time. Still trying to wrap my head around Mission:Enigma's gate bug, I can't seem to figure it out. In the meantime, I am writing tests for ZZT. Got a bunch of flag tests down. There are 8 failure points so far.

Still haven't solved the M:E bug. It's terrible to track because it is so unpredictable and relies on the order of objects and a bug in ZZT's code that references an incorrect object (sometimes outside of the valid table).

Scrolls roll open and closed now.

Video, audio, scroll, messenger and input are all made modular. The Roton engine contains built-in interfaces for all of these that work well with .NET, and Lyon uses only the built-in ones. However, if you decide you don't want messages or scrolls to be displayed the same way, you can create your own interface when you use the Roton engine. (not like I really anticipate people using it like a library anyway) This means manipulation of the world doesn't have to be tied to a video/audio/input interface anymore.

Centipedes match the game exactly. Some of them were turning around and moving on the same turn, this was fixed.

ZZT and Super ZZT handle object death a little differently. ZZT will keep the under-color if the under-element matches the #BECOME line (so #become fake will be whatever color fake it's on regardless of its own color). However, Super ZZT will use the color of the object itself. The engine will pick which mode to use appropriately.

Saving worlds now consolidates ZZT-OOP code the same way as the original game. The lowest-numbered object will now always hold the code, and everything that binds it will be a higher index. This solves a few rare/obscure bugs resulting from saving.

Who is online

Users browsing this forum: No registered users and 2 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum