Ever since I rediscovered EZZT, I was going to make a format based off both MZX, ZZT and SZZT using it, But I may use the newer format you suggested!
I don't advise using the new format for anything but playing around. Most people will still be using the original ZZT.
For fun, I did export a world in XML format. :)
Scrolls will actually open. They will also work more accurately to the original game, other Things on the board will not be executed in between scrolls coming up from the same code.
Standard strings are no longer used. All OOP code is kept in its native format and manipulated as such, so loading and saving should not change its contents because of Unicode.
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.
Going to separate the ZZT engine code into a library called Roton. Lyon will be the user interface. This way, you could reference it in another .NET project that could be written in VB, C#, etc.
The required files for distribution will be increased - to run any future version of Lyon, you will need Roton.dll in the same folder (which will be provided, of course).
Another side effect of this is that Lyon and Roton source will be updated and distributed separately.
I think I'll have the default drum sounds included in the DLL and add the ability to specify your own drum sounds. It'll keep a cleaner directory and allow for some more customization.
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.
