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
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.
This may be fixed.
This is a test build with this fix in place, and I would appreciate external verification. Please do not use this build for anything else.
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
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.
Wall Walking + Doors are fixed.
I may want to add a quest rule for this, as this new behaviour may annoy other users. This only applies to NES Dungeon Doors with diagonal movement enabled.
If you want to try the doors changes, I would appreciate feedback on this. I will roll all of the other changes into beta 9 soon, but for the present, you can try this:
This fix seems to work pretty good! I tested it against Fragments of Old, a quest with diagonal movement. Unlocking and moving between screens seems to work a lot better.
Found a relatively minor bug (this happened in 2.50.2 as well, which is where I found it initially).
When you have the 'select A Button Weapon' rule activated and have only a wooden sword (the wooden sword is what had the issue - I'm unsure of whether this happens with other items) the sword will rotate between which buttons are used for it, beginning with being in the A-button slot, then both, then the B-button slot, with usability moving accordingly (i.e. it's not just a visual thing). It doesn't scroll based on time either, but whenever Link moves screens or picks up an item (hearts, rupees, etc.)
..Can you add some check boxes like in secret combos to like, choose where underwater effects are the same as you can choose darkrooms in certain screens on maps?
Also something like warp character to room, - if all enemies are defeated in a room or something?
Also; some kind of Auto simple NPC checkbox to say a message string in a room and then disappear even if an entire maps rules does not allow it? -Plus not to appear even if you walk back into the room unless you leave the map itself and come back- so that it can repeat again?
Spoiler
(I cant script, i don't understand scripting, i will never be able to script or add scripts, there are no videos on youtube how to script.)
It seems like every-time somebody updates something in the Zelda Classic, they don't seem to change very much in the model itself, just trivial things i don't even find a problem with.
Edited by SkyLizardGirl, 17 September 2017 - 11:50 PM.
Found a relatively minor bug (this happened in 2.50.2 as well, which is where I found it initially).
When you have the 'select A Button Weapon' rule activated and have only a wooden sword (the wooden sword is what had the issue - I'm unsure of whether this happens with other items) the sword will rotate between which buttons are used for it, beginning with being in the A-button slot, then both, then the B-button slot, with usability moving accordingly (i.e. it's not just a visual thing). It doesn't scroll based on time either, but whenever Link moves screens or picks up an item (hearts, rupees, etc.)
Thank you, I will look into it. To clarify, to reproduce this, I need to do the following:
Create a querst with an A+B item ruleset, and an A+B item subscreen pair.
Give Link the LV1 Sword (or possibly, any sword; or possibly any single active item).
Collect dropset item drops, and the weapon will change slots.
Is that correct?
Hey Zoria?
..Can you add some check boxes like in secret combos to like, choose where underwater effects are the same as you can choose darkrooms in certain screens on maps?
Also something like warp character to room, - if all enemies are defeated in a room or something?
Also; some kind of Auto simple NPC checkbox to say a message string in a room and then disappear even if an entire maps rules does not allow it? -Plus not to appear even if you walk back into the room unless you leave the map itself and come back- so that it can repeat again?
It seems like every-time somebody updates something in the Zelda Classic, they don't seem to change very much in the model itself, just trivial things i don't even find a problem with.
There will be no features added to 2.53 that make the quest output fully incompatible with playing quests in 2.50.2. New features will start in 2.54, hopefully in December.
Spoiler
(I cant script, i don't understand scripting, i will never be able to script or add scripts, there are no videos on youtube how to script.)
Spoiler
I had Let's Script streams, and I posted videos from them. Saffith also did, a few years ago. I stopped as it was a pure waste of my time, to schedule the event, prep for it, sit down and start streaming, then wait--all for an empty room. No-one showed up that requested the streams, or that wanted specific content, so I discontinued the streams entirely.
There should be some videos on my channel from one or two sessions. Hell, one session became a glorified test run of 'Engage to Zeldawok' in 2.54, and I am almost sure that I posted both ends of that, and the dev session of Triforce Knight that followed. It was a train wreck, and I will not spend my time recording without a good reason.
This is the most useful video, and I created it for no better reason than because I can. I do not recall if anyone requested a tutorial for the Moosh Bottles, but I do recall several users grumbling about the difficulty in setting them up, so I streamed a set-up video, and posted it.
I apparently only posted the results video for the difficulty menu script, although I recall recording the entire process. I may have not liked the output quality, and scrapped it??? I had to do that in a few instances, as the font rendering output was unreadable with the video compression, and thus, the 3 to 4 hour videos were useless.
Thank you, I will look into it. To clarify, to reproduce this, I need to do the following:
Create a querst with an A+B item ruleset, and an A+B item subscreen pair.
Give Link the LV1 Sword (or possibly, any sword; or possibly any single active item).
Collect dropset item drops, and the weapon will change slots.
Is that correct?
Yes, though the weapon will also change slots on changing screen (at least when scrolling to a different screen; haven't tested with other types of warp)
Yes, though the weapon will also change slots on changing screen (at least when scrolling to a different screen; haven't tested with other types of warp)
Please post an example quest with this bug, and verify the conditions required to replicate it.
If you need to keep the quest private, please send me a message on Skype, or Discord, with it; or send me a PM on AGN, or post a new message in the existing thread that you have with me for the music files. My mailbox here is overfull, and I cannot accept new threads at present.
( It may be possible that the quest in which you encountered it is using an incorrect subscreen type, or QR setting. ??? )
Are you certain that you tested this in 2.53, and not merely 2.50.2?
Yes, though the weapon will also change slots on changing screen (at least when scrolling to a different screen; haven't tested with other types of warp)
I checked the quest. You have an error of some kind on your active subscreen.
I am not sure precisely what the error is at present, but if I change to the Active, New A+B subscreen in the dungeon DMap, the issue goes away. It is a bit hard to track down these issues, because of all of the subscreen objects. It could be that you have more than one object set tot he swords class though. That would certainly cause what you are seeing.
When I changed the active subscreen tot he stock Active, new (A+B), the problem went away. I also verified that the stock subscreens do not do this in a new quest (I tested Avtive and Passive, new and Alt, A+B).
Your simplest solution may be to duplicate the Active, New, A+B subscreen, and re-do your gfx and positioning. One small subscreen error can cause a lot of havoc, so change a little bit at a time, save, test, and duplicate the subscreen before you edit it.
Edit: I found your error. You started the object IDs for button items at 1, rather than at 0. Change the Position IDs for the items to start at 0, so the wrod is 0, the boomerange is 1, and so forth; then update the directional settings to match.
Pardon me; this reply took way too long. I suddenly got hit with story inspiration, and spent the last week or two doing nothing but research.
Lüt, 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.
Also yeah Lüt, your bug reporting is amazing. I should get to testing this version myself xD
Thanks guys
It's honestly been quite a time eater, but when it was announced that the 2.50.x series (such as it was numbered at the time) was coming to an end, I looked at all the stuff I'd done and all the stuff I was still working on, and realized how big of a thing this had become in my life. So I decided it was finally time to dig through my "possible bugs and issues" list that I'd been building up over the last 2 years, and present as much of it in an expanded report format as I could.
And to that extent...
Keep up the good work.
...people should be happy to know that my list is reaching its end!
Well, my ZC list, at least.
Spoiler
There's always ZQ after
But for now, updates to previous issues, and a few more points to consider:
Image Output Corruption 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?
It was actually all 6 image formats in both programs, but it's no longer an issue.
I tried outputting images from both ZC and ZQ in every format using the latest B8 update, and they all came out fully functional.
Also, it was probably already confirmed as fixed, but I've had no issue importing or exporting images from the tile page.
Water Damage Jig Update:
The root cause of this bug (Link pops out of water when hit by his own fire, his own bombs, or a damage combo) should be fixed now.
Yep, tried it with both hitbox sizes. Can't recreate it anymore.
I'm surprised this was the first thing somebody else (so enthusiastically) joined in requesting.
My first impression - the fix works great. Exactly the way I'd hoped.
However, I wanted to check its precise functional range using a half tile grid, so I came up with these two test rooms representing possible door-blocking arrangements that could be used in a quest:
In the left room, everything worked exactly the same in 2.50.2 and 2.53 B8. In the right room, everything worked exactly the same in 2.50.2 and 2.53 B8, except for...
Spoiler
... the undersides of the blocks in front of the eastern and western doors:
In 2.50.2 (left), the doors can't be opened, no matter how you approach them. In 2.53 B8 (right), the doors can be opened, any way you approach them.
This is using the standard small hitbox. The large hitbox negates this issue.
So... I guess the sensitivity for the bottom of the side-doors needs to be moved up a pixel or two?
And then, some new points (more inconsistencies than bugs):
Since further elaboration was requested: enabling 8-way movement causes Link to get hung up on the edges between water and solid ground when passing between two such combos. The delay seems to match that of a standard push-block, as if Link were "pushing" his way in to or out of the water, but I have no way to legitimately calculate it.
This demo starts you on a small island and provides a series of walkable water decorations that loop from bottom to top around the screen and back to the island. It is currently set up with 4-way movement. Grab the flippers, jump into the water, swim/walk your way through the decoration loop, and climb back onto the island. No delay anywhere. Now load the demo in ZQ, enable 8-way movement, and try it again.
It may or may not be a bug - perhaps it's even intentional - but it's inconsistent, I've only ever heard people complain about the hangup when they use 8-way in their quests, and I don't believe anybody has anything to gain from the lag, so if possible, I suggest having 8-way water transitions mimic their 4-way counterparts.
Minimap Display Lingers On NES Scrolling Warp: [Demo Quest]
When using a scrolling warp between different DMaps with different level numbers, if the DMap being warped to is an NES Dungeon type, and you have the map item for the original DMap but not for the one being warped to, the minimap will flash the layout of the new DMap for a brief moment before disappearing.
This demo gives you a single start room with a map item in it. Pick up the map to get a minimap displaying a bunch of rooms that don't actually exist. Take the left side door to scroll warp to a new DMap. After the screen fades in, the DMap title will change, then there will be about 12 frames where the minimap for the new DMap is displayed, before it flickers out of existence.
I believe this happens during the frames that Link is pushed into the room by the NES Dungeon type, as it doesn't happen when an Interior DMap type is used, so perhaps it could be fixed by having the minimap update process be done after the fade-in, rather than after the walk-in.
Debug Console Closing Method Differences:
If you load ZC and go to "Misc" -> "Show Debug Console," a separate DOS-prompt-like ZConsole screen shows up. If you click "Show Debug Console" again, the ZConsole screen closes and ZC continues. But if you click the X at the upper right of the ZConsole screen, the entire ZC program closes without even asking if you want to quit ZC, let alone save the game you're playing.
If it weren't obvious, my suggestion would be to have the X function the same as clicking "Show Debug Console" does (which, at that point, should probably say "Hide Debug Console") - because I can imagine at least one person getting genuinely pissed off at an unexpected program closure.
Slower Magic vs. Heart Refill Rate:
When using a potion or stepping on a fairy ring flag, Link's health refills twice as fast as his magic.
I know why it happens. Hearts have 16 units per container, magic has 32 units per container, and the game consistently restores each on the same single-unit basis.
But all any player is going to see is two hearts fill up while only one magic container fills up.
Further, depending how much magic the player is given, it can notably undermine the "Fast Heart Refill" quest rule (which I know first hand, as an update I'm doing currently has a magic meter that takes nearly 15 seconds to fill, even with the fast refill QR enabled).
So if it were possible to match the two refill rates on the surface rather than in the code, that would be great.
And one last thing - I notice that, with a few of these latest beta builds, I'll have to set my keyboard controls up a few times before they're finally saved upon exiting the program. The program doesn't crash, and I have no idea what I might be doing differently that it eventually saves, but that's all I can say. Might be worth double-checking the control save process.
And one last thing - I notice that, with a few of these latest beta builds, I'll have to set my keyboard controls up a few times before they're finally saved upon exiting the program. The program doesn't crash, and I have no idea what I might be doing differently that it eventually saves, but that's all I can say. Might be worth double-checking the control save process.
Are you running ZC and ZQuest at the same time? That might do it; whichever one is closed second would overwrite the first one's configuration changes.
Are you running ZC and ZQuest at the same time? That might do it; whichever one is closed second would overwrite the first one's configuration changes.
Not surprisingly, I believe that would be it.
Almost all my time using these latest beta builds was while I was making and editing all these test quests. And I think the reason why it "eventually saved," was because I was closing ZQ out for the day.
Alright, I'm going to call that "problem solved" then. Thanks for pointing out the obvious