The official thread for Beta 9 will follow, but in the interim, here is the Beta 9 update, which fixes doors in diagonal movement, fixes the issues with Link in water, flying through land tiles when he is hit by his own weapons, and potentially fixes issues with wizzrobe and other floating/flying enemies spawning on solid combos (when they should not), or flying through walls.

Here is Beta 9, fixing a number of issues that the userbase had previously reported. See the Changelog below for more information. As before, the Build ID for this release is '31', to distinguish between 2.50.3RC1 (Build ID '30') and earlier ZC releases.

We would appreciate bug reports on any of the following:

Playing quests made in 1.92, 2.10, 2.50.x and reporting any compatibility bugs.

Verification that scripts made in 2.50.0, 2.50.1, 2.50.2, and 2.50.3RC1 still work.

Testing that scripts compiled in 2.53.0 work properly in 2.53.0.

Tests that scripted quests compiled and saved in 2.53.0 work proper;y on 2.50.2 (and/or 2.50.3RC1).

Bug reports on any changes, or new features.

Bug reports on joystick configuration.

Please note: The std.zh files in this package may not represent what will be included in the final release. It is likely that the std.zh changes will be pushed forward to 2.54 or later, and not included; but they will be available as a separate download. The latest versions of all common ZScript headers will be included in the final release.

This release is built on the Allegro library, version 4.4.3, with some special fixes applies, and it includes new Allegro library files.

Removed an extra constant declaration in std_functions.zh.Changed the 'Import Script]' file selection dialogue. It now shows files with types of .zh, .zs, .zlib,.zscript, and a few other minor typed used by the userbase, rather than solely showing '.z' files. ( ZoriaRPG, 24th September, 2017 )

Refactored the sanity checks for Game->Get/SetCombo* (except for SetComboSolid). These functions will now reportany invalid refs passed to them (invalid map, screen, position) to allegro.log and abort, or return -1 to the user.The prior code either allowed passing an invalid ref, or never informed the user that it was invalid. ( ZoriaRPG, 23rd September, 2017 )

Modified GetHighestLevelitem() in std.zh, to use a setting in std.cgf: This setting determines the highest item IDthat GetHighestlevelitem() will check, rather than one version stopping at 143, and another at 255. ( ZoriaRPG, 22nd September, 2017 )

Removed std_constants_shortcuts.zh from std.zh.Removed extra (unintended) array 'GlobalBuggr[214747] from std.zh.Fixed some issues with NPCA_* constants.Added NPC Attribute constants for all npc types, and every field with a lister.Fixed values for Direction to Degree and Radian conversions in std_functions and std_constants. ( ZoriaRPG )

Updated qst.dat. Now, new quests will autosave, if you have timed save, or quest backup enabled. The error 'This questwas created in an older version of ZQuest' will no longer appear on new quests. ZoriaRPG, 1st September, 2017 )

Fixed file selection dialogues in Zelda Classic. After selecting a quest in the Load Quest dialogue, the default buttonis now 'OK', rather than browse, so hitting the enter key after selecting a file does not put you into a file select loop.This was likewise something that I did before, but it was somehow lost in various commits. ( ZoriaRPG, 1st September, 2017 )

Fixed a bug where the lens of truth stole the script of the last item used, and ran it every frame. ( ZoriaRPG, 20th August, 2017 )

New Allegro libraries using Allegro 4.4.3, with some patches.Fixed issues with the infinite wallet.Fixed Link's attack not being cancelled when he is frozen.Fixed the race condition issue with keyboard input in Allegro 4.4.3. ( DarkDragon, 13th August, 2017 )

Fixed an issue with scrolling between land and water. ( DarkDragon, 11th August, 2017 )

Fixed an issue where the subscreen did not always update, by checking item validity when changing dmaps. ( DarkDragon, 10th August, 2017 )

Fixed a bug in ZQuest that was corrupting ag.cfg. ( DarkDragon; and ZoriaRPG, July, 2017 )

Fixed a bug where MIDI files could not be loaded in ZQuest. ( DarkDragon, July 2017 )

Updated std.zh to 2.50.3 version, plus some rearranging in a std_zh path.Updated all included headers to their current versions.Pruned some files.Unlocked 1st.qst and 2nd.qst. ( ZoriaRPG, 11th July, 2017 )

Fixed improper error return values on some ffscript functions.Seem to have fixed reported bug of ZC crashing if the user shifts focus when assigning joypad buttons.In any case, I can not replicate it in this build, and I did change a read_button function that was a bit bonkers. ( ZoriaRPG, 2nd July, 2017 )

All the fixes to the infinite wallet work great, and I can't find any more ways to break it.

However, it seems the fixes created a new problem with the start finite rupee counter: buying items in shops doesn't deduct rupees. You still need to have the minimum amount of rupees necessary to purchase the item in the first place, but once you purchase it, your rupees don't drain.

This demo is merely a quick update to the one I made for the infinite wallet. You can try the 6 different payment rooms. Go to the respawning enemy area at the right to get 10 rupees per enemy. You start without a wallet, but you can pick up wallet 1 (500 rupees) on the second screen up to see that it doesn't make a difference.

When swimming in water, Link remains in the water when hit by enemy fire. Alternatively, when he damages himself, he pops up as if he were on solid ground. Then, when he finally moves, he sinks back into the water.

However, if Link is on a shoreline (1 combo away from solid ground) when he damages himself, and if, after popping up to solid-ground level, he walks onto actual solid ground (including shallow water), the player loses control of him while he does a funky jig across the entire screen in the direction that he exited the water. In the process, he'll become invincible and pass through any object on the screen - even solid combos. The player only regains control of him when he re-enters water, and therein lies a game-breaking problem - if there's no water, Link will pass through every combo on the screen, even solid walls, until he exits that screen and enters the next screen. And if there is no "next screen," then he'll either appear outside the DMap, or get stuck running into the edge of the screen if it's on the edge of the actual 8x16 map.

This demo gives you each possibility by way of the red candle. I suggest working your way from the bottom to the top of the right-side shore first. Stand at the edge, fire the candle into the water, walk into the water, take the hit, rise up to ground level, then walk left back onto the land. The lowest row will show you Link walking across open land and back into water, the middle row will show you Link walking through a solid combo and back into water, and the upper row will show you Link walking through a solid combo and off the screen entirely. Likewise, you can try it vertically as well.

This bug works with both small and large Link hit boxes. However, due to the small hit box making it very hard to replicate the problem vertically, I've enabled the large hit box so you can align Link with north and south shores as easily as the east and west shores.

In 2.50.2, if Link exited to the next screen and landed in deep water, the player would regain control of him. Alternatively, if Link exited to the next screen and remained on solid ground, the player would completely lose control of him. In 2.53.0 versions, the player retains control of Link, and can try walking back to the prior screen. Of course, if there's a solid structure more than 1 combo thick, Link won't be able to return to the playable area, and may possibly be stuck outside the level.

Intriguingly, this only happens with 8-way movement enabled. Standard 4-way movement prevents him from popping up to solid-ground level in the first place. I suspect it has to do with the way he gets temporarily stuck on shorelines when entering and exiting water with 8-way movement enabled. 4-way movement doesn't have this problem.

And honestly, this lag on entering/exiting water with 8-way movement should probably be "fixed" anyway. I don't know why it's different, and I've only ever heard people complain about the hang-up.

This is a rather small inconsistency that might even be considered negligible, but I'll bring it up anyway, just in case.

WIth 8-way movement enabled, locked/boss-locked doors in NES dungeon screens won't open if Link moves toward them while facing the upper wall. To try it, walk upward into the dungeon walls on either side of the door, then press left or right to slide by it. Furthermore, stop in front of the door while still walking upward. It won't open. However, if you let go of the up arrow, then press it again, it will open - and without Link changing position. By contrast, if you walk upward into a wall or barrier on either side of a lock-block/boss-block, then press left or right to slide by it, it will open - immediately. This is consistent with small Link hit box, large Link hit box, and the Freeform Dungeon quest rule enabled or disabled.

Again, tiny issue, but it could possibly confuse newer players into thinking their key doesn't work on that particular door, so if there were a way to give the doors the same sensitivity as the lock blocks, it might be helpful to a few people.

Obviously, this isn't a problem with 4-way movement, as Link can't slide sideways.

Image Output Corruption:

I had mentioned PNG corruption. ZoriaRPG had mentioned he was working on the PNG problem. Turns out we were talking about 2 different things: he was dealing with importing tiles to ZQuest, and I was talking about screenshots and exporting tiles. So here's what I should have clarified and reported earlier:

Image output from ZC and ZQ is corrupt. This applies to ZC screenshots (F12), ZQ screenshots (Z), ZQ tilesheet exports, and ZQ "Save to File (Mapmaker)" exports of full maps. These worked in 2.50.3 RC1, but became broken as of 2.53.0 B2, and have remained broken since then (I haven't tested B1, as it was replaced so quickly, so it may have started then).

I confirmed this using all 6 image formats in each version of ZC, and each format in each version produced the same result. I only used PNG output in ZQ, as I figured the source of the problem was the same for each program, and further image format tests would be redundant. Every image from each program failed to open in both Irfanview and Photoshop.

In one instance, the screenshots did work. It was while playing Vaporvania, from the Metroidvania contest. It worked once, in B4, and as many times as I've loaded and reloaded the quest, and taken screenshots on the same screens, I've never gotten it to work again, even using the first savegame, so I'm writing it off as an unreplicable freak incident.

Regardless, I don't believe this is a matter of writing a correct image to a wrong format, as Irfanview catches incorrect image extensions and offers to rename them accordingly. Rather, they seem to be incomplete outputs in some way. These are the error messages I received from each program:

Lut, I just want to say, you are an awesome help with all these bug reports. Like seriously, I've never seen someone so effectively and concisely report bugs in the public forums. Keep up the good work.

Again, tiny issue, but it could possibly confuse newer players into thinking their key doesn't work on that particular door, so if there were a way to give the doors the same sensitivity as the lock blocks, it might be helpful to a few people.

This! This!! This!!! I can't count the number of times I've grinded my teeth because the NES dungeon locked doors were effed up with diagonal movement on. Even if they only gain the new sensitivity when diagonal movement is on, it would still go a long, long way.

All the fixes to the infinite wallet work great, and I can't find any more ways to break it.

However, it seems the fixes created a new problem with the start finite rupee counter: buying items in shops doesn't deduct rupees. You still need to have the minimum amount of rupees necessary to purchase the item in the first place, but once you purchase it, your rupees don't drain.

This demo is merely a quick update to the one I made for the infinite wallet. You can try the 6 different payment rooms. Go to the respawning enemy area at the right to get 10 rupees per enemy. You start without a wallet, but you can pick up wallet 1 (500 rupees) on the second screen up to see that it doesn't make a difference.

When swimming in water, Link remains in the water when hit by enemy fire. Alternatively, when he damages himself, he pops up as if he were on solid ground. Then, when he finally moves, he sinks back into the water.

However, if Link is on a shoreline (1 combo away from solid ground) when he damages himself, and if, after popping up to solid-ground level, he walks onto actual solid ground (including shallow water), the player loses control of him while he does a funky jig across the entire screen in the direction that he exited the water. In the process, he'll become invincible and pass through any object on the screen - even solid combos. The player only regains control of him when he re-enters water, and therein lies a game-breaking problem - if there's no water, Link will pass through every combo on the screen, even solid walls, until he exits that screen and enters the next screen. And if there is no "next screen," then he'll either appear outside the DMap, or get stuck running into the edge of the screen if it's on the edge of the actual 8x16 map.

This demo gives you each possibility by way of the red candle. I suggest working your way from the bottom to the top of the right-side shore first. Stand at the edge, fire the candle into the water, walk into the water, take the hit, rise up to ground level, then walk left back onto the land. The lowest row will show you Link walking across open land and back into water, the middle row will show you Link walking through a solid combo and back into water, and the upper row will show you Link walking through a solid combo and off the screen entirely. Likewise, you can try it vertically as well.

This bug works with both small and large Link hit boxes. However, due to the small hit box making it very hard to replicate the problem vertically, I've enabled the large hit box so you can align Link with north and south shores as easily as the east and west shores.

In 2.50.2, if Link exited to the next screen and landed in deep water, the player would regain control of him. Alternatively, if Link exited to the next screen and remained on solid ground, the player would completely lose control of him. In 2.53.0 versions, the player retains control of Link, and can try walking back to the prior screen. Of course, if there's a solid structure more than 1 combo thick, Link won't be able to return to the playable area, and may possibly be stuck outside the level.

Intriguingly, this only happens with 8-way movement enabled. Standard 4-way movement prevents him from popping up to solid-ground level in the first place. I suspect it has to do with the way he gets temporarily stuck on shorelines when entering and exiting water with 8-way movement enabled. 4-way movement doesn't have this problem.

And honestly, this lag on entering/exiting water with 8-way movement should probably be "fixed" anyway. I don't know why it's different, and I've only ever heard people complain about the hang-up.

This is a rather small inconsistency that might even be considered negligible, but I'll bring it up anyway, just in case.

WIth 8-way movement enabled, locked/boss-locked doors in NES dungeon screens won't open if Link moves toward them while facing the upper wall. To try it, walk upward into the dungeon walls on either side of the door, then press left or right to slide by it. Furthermore, stop in front of the door while still walking upward. It won't open. However, if you let go of the up arrow, then press it again, it will open - and without Link changing position. By contrast, if you walk upward into a wall or barrier on either side of a lock-block/boss-block, then press left or right to slide by it, it will open - immediately. This is consistent with small Link hit box, large Link hit box, and the Freeform Dungeon quest rule enabled or disabled.

Again, tiny issue, but it could possibly confuse newer players into thinking their key doesn't work on that particular door, so if there were a way to give the doors the same sensitivity as the lock blocks, it might be helpful to a few people.

Obviously, this isn't a problem with 4-way movement, as Link can't slide sideways.

Image Output Corruption:

I had mentioned PNG corruption. ZoriaRPG had mentioned he was working on the PNG problem. Turns out we were talking about 2 different things: he was dealing with importing tiles to ZQuest, and I was talking about screenshots and exporting tiles. So here's what I should have clarified and reported earlier:

Image output from ZC and ZQ is corrupt. This applies to ZC screenshots (F12), ZQ screenshots (Z), ZQ tilesheet exports, and ZQ "Save to File (Mapmaker)" exports of full maps. These worked in 2.50.3 RC1, but became broken as of 2.53.0 B2, and have remained broken since then (I haven't tested B1, as it was replaced so quickly, so it may have started then).

I confirmed this using all 6 image formats in each version of ZC, and each format in each version produced the same result. I only used PNG output in ZQ, as I figured the source of the problem was the same for each program, and further image format tests would be redundant. Every image from each program failed to open in both Irfanview and Photoshop.

In one instance, the screenshots did work. It was while playing Vaporvania, from the Metroidvania contest. It worked once, in B4, and as many times as I've loaded and reloaded the quest, and taken screenshots on the same screens, I've never gotten it to work again, even using the first savegame, so I'm writing it off as an unreplicable freak incident.

Regardless, I don't believe this is a matter of writing a correct image to a wrong format, as Irfanview catches incorrect image extensions and offers to rename them accordingly. Rather, they seem to be incomplete outputs in some way. These are the error messages I received from each program:

Photoshop error (JPG format): Could not complete your request because a JPEG marker segment length is too short (the file may be truncated or incomplete).

So, it looks like some integral parts of the files aren't being written. Hopefully there's a clue in those error messages.

I believe 2.53.0 B1/B2 was when you switched to Allegro 4.4, was it not? So perhaps it has to do with the Allegro update?

Oh, a different PNG issue? This is probably being caused by the same thing. (The password global for Allegro is not being set NULL.) In essence, ZQuest is trying to encrypt the images. Does this only affect ZQuest? I suspect it does.

Again, oh boi, new issues that stem from the patches. I'm not terribly surprised by the wallet issue, and I might look into addressing that tonight. The water issues, are DD terriroty for the present, as he put all of those changes in place, and he probably has a better idea on what is going on with it.

8-Way movement and doors. I'll look into this. THe problem may be controller latency related, or some input issue. Does this happen with both keyboards, and joypads? If so, then it is an issue with Links internal direction.

I pushed through another ZLaunch update, to v2.6.1. It does not affect anyone at present, as it would only matter to Linux users, and there is not yet a Linux build of ZLaunch 2.6+. I did include it in an updated 2.53b7 ZIP, and I updated the standalone file for it, too. The changelog (above) reflects the current package.

The drivers tab is for users, who encounter issues as FireSeraphim did, with Allegro selecting the wrong video mode for their hardware. In general, you want 'DirectDraw' as your video driver, but if you run into issues, you can now change it in the launcher. (You no longer need to edit ag.cfg to set it.)

I discovered a bug on my end of things. Someone tinkered with the sprite editor, and now, the sprite IDs are not shown, at all. Someone also reverted me dialogue fix for loading quests. Lovely.

The changelog doesn't say this, so I assume the issue with bitmaps persisting even after quitting a quest is still there?

Also yeah Lüt, your bug reporting is amazing. I should get to testing this version myself xD

I'm not changing this at present. Until we have the new bitmap mechanics in place, this may as well not become an issue where some quest depends on it, and changing it causes issues. The scripter can wipe all bitmaps on Init and OnContinue if they are truly worried about this; or wipe them OnExit, to be polite. .

Beta 8 is in the top post. This addresses PNG saving, and backports some minor enhancements, and miscellaneous bugfixes. See the changelog, for details. The wallet, and water bugs remain unchanged from the reports.

I just fixed the bitmap memory persist bug. Sorry it took so long; in all honesty, well, I just forgot.

You applied that only to master. Did you intend that it also be applied to 2.50.x?

Beta 8 is in the top post. This addresses PNG saving, and backports some minor enhancements, and miscellaneous bugfixes. See the changelog, for details. The wallet, and water bugs remain unchanged from the reports.

You applied that only to master. Did you intend that it also be applied to 2.50.x?

Umm... well yes actually. It's just that I forgot. :googly: I think I have a problem... O_o

All the fixes to the infinite wallet work great, and I can't find any more ways to break it.

However, it seems the fixes created a new problem with the start finite rupee counter: buying items in shops doesn't deduct rupees. You still need to have the minimum amount of rupees necessary to purchase the item in the first place, but once you purchase it, your rupees don't drain.

This demo is merely a quick update to the one I made for the infinite wallet. You can try the 6 different payment rooms. Go to the respawning enemy area at the right to get 10 rupees per enemy. You start without a wallet, but you can pick up wallet 1 (500 rupees) on the second screen up to see that it doesn't make a difference.