Commodore wrote:It is still the legendarily buggy Link's Adventure.
Very cool. Lyon now reproduces this bug exactly. I also managed, on the same board, to lock up both ZZT and Lyon in the exact same function! Reproducing this bug causes others to surface in interesting ways.
I never expected the built-in monsters to be so buggy.
Try this build, should fix all the issues you mentioned. The darkness bug was caused by the code I put in so that conveyors fully surrounded by objects would operate fine (I will probably fix this and break it so it works like ZZT)
System.IndexOutOfRangeException
at Roton.VideoGDI.CancelUpdate(Int32 X, Int32 Y)
at Roton.Environment.BoardFade()
at Roton.Environment.ExecuteMain()
at Roton.Environment.ExecuteMain()
at Roton.Environment.Execute()
at Lyon.GameForm.Tick()
tried to load a szzt save file with a zzt window open
Commodore wrote:System.IndexOutOfRangeException
at Roton.VideoGDI.CancelUpdate(Int32 X, Int32 Y)
at Roton.Environment.BoardFade()
at Roton.Environment.ExecuteMain()
at Roton.Environment.ExecuteMain()
at Roton.Environment.Execute()
at Lyon.GameForm.Tick()
tried to load a szzt save file with a zzt window open
Ohhh yeah. Lyon does NOT like it when you change game engines that way. The game window is coded so that everything is set up on initialization. I need to make it so that it opens up a new window if the engine is different.
Here's a release that fixes the restore bug. If you change worlds or restore a game within a game window, it will check to make sure that the world types are the same. If they are not, it will open a new window.
Now, go forth and break things!
Next to implement: proper conveyor behavior (buggy when fully surrounded by pushable stat items such as bombs, etc)
System.NullReferenceException
at Roton.File.SaveRLE(ZZTBinaryWriter Target, Tile[] Tiles, Library Library)
at Roton.File.SaveZZTBoard(ZZTBinaryWriter Target, Board B, Library Library)
at Roton.File.SaveZZT(ZZTBinaryWriter Target, Environment Source)
at Roton.File.Save(Stream TargetStream, Environment Source)
at Lyon.MainForm.FileSave(Environment E)
at Lyon.MainForm.SaveGameHandler(Environment E)
at Roton.Environment.ActPlayer(Int32 Index)
at Roton.Environment.Act(Int32 Index)
at Roton.Environment.PerformBoardCycle()
at Roton.Environment.ExecuteMain()
at Roton.Environment.Execute()
at Lyon.GameForm.Tick()
Opposite problem. tried to save over a szzt save file (same as above) while in a zzt game.
The RLE generator crashed there- this would typically be as a result of a corrupted board. Do you have the world this happened on? The type of world wouldn't matter for this kind of error.
Edit: I may have identified one possible cause- when loading boards, if it is determined that the board is corrupted on load, the tiles array is actually left null. There wasn't a provision for this when saving the boards back. There will be a safeguard for the next time. But I would still like to see this in action, just to be sure it is fixed.
Edit 2: Conveyors now work exactly as in ZZT. If you surround a conveyor with bombs, it is possible to remove the player object from the game by lighting them a certain way, making it impossible to quit or do anything else!
Edit 3: I have improved the handling of corrupted boards, they will now be replaced with a blank board (but the board's title will still remain how it is in the file.)
Bugs mentioned above were fixed. I also found one where having a ZZT window maximized while closing it to switch to another window could potentially cause a crash.
Next objective: implement Messenger as it is in ZZT. Currently, it is not part of the thing-list, and is processed separately. However, in order for bugs such as the border illusion trick in ZEOL-7 to work properly, it needs to be in the thing-list. Technical reason: a messenger is created on the target board which executes exactly once, which is what causes that board's border on the screen.
More time-consuming objective: fix #zap and #restore bugs. They have been present since the OOP rewrite and I just haven't gotten around to fixing them.
Making some progress on the zap/restore bug. I've implemented each of the commands correctly but the search routine needs some tweaking- it's zapping more than it should.
I just looked at the VB (i am very rusty) and saw how zap jumps through the send and sendeval routines. Hairy stuff! I hope thats based on the disassembly, it seems like a roundabout way to do a search and replace routine. Maybe I've just been swimming around in machine language for too long...
Commodore wrote:I just looked at the VB (i am very rusty) and saw how zap jumps through the send and sendeval routines. Hairy stuff! I hope thats based on the disassembly, it seems like a roundabout way to do a search and replace routine. Maybe I've just been swimming around in machine language for too long...
Yeah it's nasty. I don't like all the ByRef stuff. I'd rather pass it all via a structure. But it should replicate exactly what I see in assembly. After it's all done, I would refactor it into something that makes sense.
SendEval searches for a label that matches the string, and target as well if applicable.
