118 replies to this topic

[Lüt]

We would appreciate bug reports on any of the following:

Alright, you asked

 

Shop Text Disappears: [Demo Quest]

 

In rooms featuring any kind of Shop interaction, all Shop-related text will disappear if an item from a drop set is collected. This includes the prices, the x next to the rupee icon in standard Shops and Info Shops, and the message string if the "messages disappear" quest rule is disabled. The issue arose for me when I placed certain Shops in rooms with grass.

 

This demo features a standard Shop, an Info Shop, and a More Bombs "Shop." Cut the grass in each room until it spawns an item (the "Nothing Chance" for tall grass drop sets has been significantly reduced). Pick up the item; the Shop text will disappear. The Shop, however, will remain functional. This happens by walking over the item, or using the boomerang, hookshot, or arrow to collect it. Interestingly, picking the item up with the sword doesn't cause the text disappearance.

 

Furthermore, in Info Shops, items from the drop set that are present on screen when you buy the information will remain on screen and become un-pick-up-able by any method after the info string has run. Be sure to leave some grass items on the ground while buying info to see this happen.

 

This behavior is consistent in 2.50.2 and 2.53.0 B2.

 

Passage Subscreen Update: [Demo Quest]

 

When you use Tile Warp Type: "Passageway" to warp to another DMap with a different subscreen, the subscreen won't update to the new DMap's subscreen until an item is picked up. This is true for both passive and active subscreens.

 

This demo features an overworld and two dungeons, #1 (blue) using the same subscreen as the overworld and #2 (green) using a different subscreen. Start on the overworld. Enter the first dungeon; ignore the Amulet and stairway. See the subscreen remain the same. Exit the first dungeon to the overworld. See the subscreen remain the same. Enter the second dungeon; ignore the Silver Rupee and stairway. See the subscreen change. Exit the second dungeon to the overworld. See the subscreen change back. Enter the first dungeon; ignore the item and take the passageway to the second dungeon. See the subscreen remain the same (wrong). Now pick up the Silver Rupee; see the subscreen change (correct). Go back through the passageway to the first dungeon. See the subscreen remain the same (wrong). Now pick up the Amulet; see the subscreen change (correct).

 

This may or may not be relevant, but using Farore's Wind after taking the passageway to the new DMap will restart you in the original DMap even though the new DMap has its own "Continue Here" point.

 

(Each DMap has its own unique level number.)

 

This behavior is consistent in 2.50.2 and 2.53.0 B2.

 

Sword Spin Loss: [Demo Quest]

 

If you have the Tiger Scrolls for Spin Attack and Hurricane Spin, and press and hold the sword attack button while entering a cave with a text string (when the circular fade closes in on Link), your sword will begin to swing upon entry, but the text string will cut off the action while Link is frozen in position. Once the message is finished displaying, your sword will remain on the ground in front of where you entered. Walk around while still holding the sword attack button, wait until the Spin Attack or Hurricane Spin are changed, then go swinging around the room while your sword remains by the cave entrance. The sword will return to you once your attack is finished. If you have the Crossbeams scroll, the beams will fire before your sword returns to you, looking all the stranger.

 

This demo gives you the 3 Tiger Scrolls along with the L2 Charge Ring, and provides you a cave with a Guy and text string to try this with. Only press the sword attack button while the circular fade is closing in on Link as he walks down the cave steps. This same glitch does not occur while walking out of the cave and back to the overworld.

 

This behavior is consistent in 2.50.2 and 2.53.0 B2.

 

Solid Secret Water-Sink: [Demo Quest]

 

In rooms with swimmable water on the edges, changing the water tiles to walkable floor tiles through use of a secret trigger will cause Link to sink into the new floor tiles as if they were still water tiles when he leaves the screen walks back in to it. This only occurs if Link has the flippers.

 

This demo features 2 rooms with water pools and twin side-bridges connecting each room. Start at the lower room and take one of the side-bridges to the upper room. Ignore the flippers and step on the floor button. This will raise a center bridge connecting both rooms via secret state carry-over. Walk down the new center bridge to the lower room and back to the upper room. Nothing happens. Now grab the flippers and walk back down and up again. In each direction, Link will sink into the walkable floor tiles, and you'll have to move to the next walkable tile as if you were climbing out of water.

 

This behavior is consistent in 2.50.2 and 2.53.0 B2.

 

Bombchu (Mis)behavior: [Demo Quest]

 

Ever since I started using ZC 2.50.0 years ago, Bombchus have exploded with a normal bomb explosion when killed by a weapon, but exploded with a super bomb explosion when they made contact with Link. However, when I upgraded to ZC 2.50.2, Bombchus have only ever exploded with a normal bomb explosion when they made contact with Link. This (mis)behavior remains in 2.53.0 B2. I believe it's misbehavior because there was no further indication that their on-contact death was changed for any reason. The ZC Wiki enemy entry even says: "If Link kills it with one of his weapons, it uses a small explosion, but if it runs into to him, it uses a big explosion which deals a damage of 2 hearts." If it was an intentional change, I believe it should be changed back because it undermines the threat of their charge at Link. Otherwise, the wiki (and possinly other documentation) could use an update.

 

This demo features a room with 4 Bombchus that always return on re-entry. You start with a variety of weapons you can use on them. Load it in 2.50.0 to check their normal vs contact deaths, then in 2.50.2 or 2.53.0 B2 to see that both deaths are the same. I have not tried this in 2.50.1.

 

Infinite Wallet Not Infinite: [Demo Quest]

 

This is a strange and complicated topic. Basically, the infinite wallet is not infinite in a number of contexts. It appears infinite on the surface, and in a few instances it truly is. But there's also the default finite rupee count lurking behind that "A" next to the rupee icon on the subscreen.

 

The finite rupee count is built by collecting standard rupee drops from enemy or grass drop sets. Rooms using the "10 Rupees" room type also build your finite rupee count when you pick up the individual rupees.

 

Rooms using the "Secret Money" type do not give you rupees. When you walk over the rupee icon, they don't show how many rupees you would have gotten if you had a standard wallet, nor do they play a pickup sound - and yet, if you walk over the rupee icon, then leave the room and come back in, the Guy and the rupee icon will be removed as if you had picked up the rupees.

 

Info Shops are also fully dependent on this finite rupee count - they do not work with only the infinite wallet. If you want info, you'll have to build your finite rupee count to the price of the info you want. However, once you purchase this info, it is not subtracted from your finite rupee count, and you can re-purchase the info as many times as you want.

 

By contrast, standard Shops do work with the infinite wallet. You can enter with no finite rupees and purchase anything you want for any price you want. However, once you purchase an item, it is subtracted from your finite rupee count, and if you go back to an Info Shop, you may not be able to purchase info if the item you purchased drained your finite rupee count too low.

 

These room types work with the infinite wallet, but also drain your finite rupee count: More Bombs, Door Repair, Life or Money, Gamble.

 

This demo starts you with an infinite wallet (but no starting rupee count) and offers a collection of all these room types. The first screen has the most broken two rooms: the Info Shop and the Secret Money payout. The next screen up has the most functional two rooms: the 10 Rupees and the standard Shop. The screen after that has the last four generally functional rooms: More Bombs, Door Repair, Life or Money, and Gamble. To the right of the start room is a screen with three always-returning Octoroks, all of which drop a 10 rupee coin 100% of the time. Basically, use the Octoroks to rebuild your finite rupee count, and wander between these rooms, testing out the situations I pointed out above and get a feel for how the current infinite wallet truly functions.

 

This behavior is consistent in 2.50.2 and 2.53.0 B2.

 

(I really should have just stuck that line at the beginning of the post and been done with it.)

 

There's some more things, but I'm totally spent bug-chasing for now, and I'm sure this'll be enough to keep you occupied for a while anyway.

[Timelord]

Alright, you asked

 

[... saving space for the benefit of the reader  ]

 

(I really should have just stuck that line at the beginning of the post and been done with it.)

 

There's some more things, but I'm totally spent bug-chasing for now, and I'm sure this'll be enough to keep you occupied for a while anyway.

 

Oh my. We certainly never knew about this stuff. Bombchu has some weapon attributes that may be working here, and I will need to check what they do. In the editor, there are pre-assigned values for Death Attributes 1 and 2, and these may affect explosion size, and damage.

 

The rest of it; expect some delays in the next beta. Some of these may be QR-dependent. The infinite wallet seems the easiest fix. If it is in inventory, and Link's rupee count is < its system cap, make it the system cap. That is how it shouldbehave. i suspect that it merely bypasses some events, rather than updating as I described; as this would explain all of these bugs.

 

It is a very rarely used item, which is likely why this has not been discovered and documented before.

 

Beyond all of this, thank you very much for taking the time to do all of this testing for making demo quests, and for writing very detailed documentation on the issues. All of these things combine to make fixing these sorts of problems far, far, easier.

Edited by ZoriaRPG, 10 August 2017 - 01:37 AM.

[Timelord]

Here is the contents to the Allegro.log file on my end.

Spoiler

 

ZQuest v2.50 Beta (Build 31)
Allocating tunes buffer (16.00k/16.00k)... OK
Allocating map buffer (435.63k/451.63k)... OK
Allocating combo buffer (5.98k/457.60k)... OK
Allocating string buffer (680.00k/1.11M)... OK
Allocating door combo buffer (159.50k/1.27M)... OK
Allocating dmap buffer (234.00k/1.50M)... OK
Allocating combo buffer (1.62M/3.11M)... OK
Allocating color data buffer (314.11k/3.42M)... OK
Allocating tile buffer (8.50M/11.92M)... OK
Allocating tile grab buffer (511.88k/20.42M)... OK
Allocating trash buffer (97.66k/20.51M)... OK
Allocating item buffer (31.12k/20.54M)... OK
Allocating weapon buffer (2.50k/20.54M)... OK
Allocating guy buffer (70.00k/20.61M)... OK
Allocating combo class buffer (33.30k/20.65M)... OK
Allocating combo undo buffer (1.62M/22.26M)... OK
Allocating new tile undo buffer (511.88k/22.76M)... OK
Resetting new tile buffer...OK
Allocating file path buffers (14.00k/22.77M)... OK
Initializing Allegro... OK
Loading data files:
Fonts.Dat...OK
ZQuest.Dat...OK
QST.Dat...OK
SFX.Dat...OK
OK
Initializing sound driver... OK
Overlays not supported

 

 

 

Here's my ag.config for 2.53

Spoiler

[zeldadx]
joystick_index = 0
js_stick_1_x_stick = 0
js_stick_1_x_axis = 0
js_stick_1_x_offset = 0
js_stick_1_y_stick = 0
js_stick_1_y_axis = 1
js_stick_1_y_offset = 0
js_stick_2_x_stick = 1
js_stick_2_x_axis = 0
js_stick_2_x_offset = 0
js_stick_2_y_stick = 1
js_stick_2_y_axis = 1
js_stick_2_y_offset = 0
analog_movement = 1
key_a = 119
key_b = 117
key_s = 67
key_l = 26
key_r = 24
key_p = 75
key_ex1 = 17
key_ex2 = 23
key_ex3 = 1
key_ex4 = 19
key_up = 84
key_down = 85
key_left = 82
key_right = 83
btn_a = 2
btn_b = 4
btn_s = 8
btn_m = 9
btn_l = 5
btn_r = 6
btn_p = 8
btn_ex1 = 3
btn_ex2 = 1
btn_ex3 = 0
btn_ex4 = 0
btn_up = 13
btn_down = 14
btn_left = 15
btn_right = 16
digi = 248
midi = 255
sfx = 248
emusic = 248
pan = 1
zcmusic_bufsz = 64
volkeys = 0
vsync = 0
throttlefps = 1
translayers = 1
snapshot_format = 3
name_entry_mode = 0
showfps = 0
fastquit = 0
clicktofreeze = 1
title = 2
resx = 640
resy = 480
scanlines = 0
load_last = 1
win_qst_dir = C:\Program Files 2\Zelda Classic\ZC 2.53\
ss_enable = 1
ss_after = 14
ss_speed = 2
ss_density = 3
heart_beep = 1
gui_colorset = 0
use_sfx_dat = 1
fullscreen = 1
doublebuffer = 1
triplebuffer = 0
color_depth = 8
frame_rest_suggest = 1
force_exit = 0
debug_console = 0
zc_win_proc_fix = 0
use_dwm_flush = 0
midi_patch_fix = 0
save_indicator = 0

[graphics]
disable_direct_updating = 1

 

 

 

Some of my projects are getting close to 100 FPS for me, so with this there's a good chance some people will have less than 60 FPS playing some of my quests. It's getting dangerously close is what I'm saying and that's why I at least find the fps drop concerning. (You wanted numbers. Please don't just tell me to improve my scripts, I'm trying my best xD)

 

Please try this:

 

In ag.cfg, under [graphics], add this line:

 

gfx_cardw=DXWN

[DarkDragon]

Alright, you asked

 

Shop Text Disappears: [Demo Quest]

 

In rooms featuring any kind of Shop interaction, all Shop-related text will disappear if an item from a drop set is collected. This includes the prices, the x next to the rupee icon in standard Shops and Info Shops, and the message string if the "messages disappear" quest rule is disabled. The issue arose for me when I placed certain Shops in rooms with grass.

 

This demo features a standard Shop, an Info Shop, and a More Bombs "Shop." Cut the grass in each room until it spawns an item (the "Nothing Chance" for tall grass drop sets has been significantly reduced). Pick up the item; the Shop text will disappear. The Shop, however, will remain functional. This happens by walking over the item, or using the boomerang, hookshot, or arrow to collect it. Interestingly, picking the item up with the sword doesn't cause the text disappearance.

 

Furthermore, in Info Shops, items from the drop set that are present on screen when you buy the information will remain on screen and become un-pick-up-able by any method after the info string has run. Be sure to leave some grass items on the ground while buying info to see this happen.

 

This behavior is consistent in 2.50.2 and 2.53.0 B2.

 

Passage Subscreen Update: [Demo Quest]

 

When you use Tile Warp Type: "Passageway" to warp to another DMap with a different subscreen, the subscreen won't update to the new DMap's subscreen until an item is picked up. This is true for both passive and active subscreens.

 

This demo features an overworld and two dungeons, #1 (blue) using the same subscreen as the overworld and #2 (green) using a different subscreen. Start on the overworld. Enter the first dungeon; ignore the Amulet and stairway. See the subscreen remain the same. Exit the first dungeon to the overworld. See the subscreen remain the same. Enter the second dungeon; ignore the Silver Rupee and stairway. See the subscreen change. Exit the second dungeon to the overworld. See the subscreen change back. Enter the first dungeon; ignore the item and take the passageway to the second dungeon. See the subscreen remain the same (wrong). Now pick up the Silver Rupee; see the subscreen change (correct). Go back through the passageway to the first dungeon. See the subscreen remain the same (wrong). Now pick up the Amulet; see the subscreen change (correct).

 

This may or may not be relevant, but using Farore's Wind after taking the passageway to the new DMap will restart you in the original DMap even though the new DMap has its own "Continue Here" point.

 

(Each DMap has its own unique level number.)

 

This behavior is consistent in 2.50.2 and 2.53.0 B2.

 

Sword Spin Loss: [Demo Quest]

 

If you have the Tiger Scrolls for Spin Attack and Hurricane Spin, and press and hold the sword attack button while entering a cave with a text string (when the circular fade closes in on Link), your sword will begin to swing upon entry, but the text string will cut off the action while Link is frozen in position. Once the message is finished displaying, your sword will remain on the ground in front of where you entered. Walk around while still holding the sword attack button, wait until the Spin Attack or Hurricane Spin are changed, then go swinging around the room while your sword remains by the cave entrance. The sword will return to you once your attack is finished. If you have the Crossbeams scroll, the beams will fire before your sword returns to you, looking all the stranger.

 

This demo gives you the 3 Tiger Scrolls along with the L2 Charge Ring, and provides you a cave with a Guy and text string to try this with. Only press the sword attack button while the circular fade is closing in on Link as he walks down the cave steps. This same glitch does not occur while walking out of the cave and back to the overworld.

 

This behavior is consistent in 2.50.2 and 2.53.0 B2.

 

Solid Secret Water-Sink: [Demo Quest]

 

In rooms with swimmable water on the edges, changing the water tiles to walkable floor tiles through use of a secret trigger will cause Link to sink into the new floor tiles as if they were still water tiles when he leaves the screen walks back in to it. This only occurs if Link has the flippers.

 

This demo features 2 rooms with water pools and twin side-bridges connecting each room. Start at the lower room and take one of the side-bridges to the upper room. Ignore the flippers and step on the floor button. This will raise a center bridge connecting both rooms via secret state carry-over. Walk down the new center bridge to the lower room and back to the upper room. Nothing happens. Now grab the flippers and walk back down and up again. In each direction, Link will sink into the walkable floor tiles, and you'll have to move to the next walkable tile as if you were climbing out of water.

 

This behavior is consistent in 2.50.2 and 2.53.0 B2.

 

Bombchu (Mis)behavior: [Demo Quest]

 

Ever since I started using ZC 2.50.0 years ago, Bombchus have exploded with a normal bomb explosion when killed by a weapon, but exploded with a super bomb explosion when they made contact with Link. However, when I upgraded to ZC 2.50.2, Bombchus have only ever exploded with a normal bomb explosion when they made contact with Link. This (mis)behavior remains in 2.53.0 B2. I believe it's misbehavior because there was no further indication that their on-contact death was changed for any reason. The ZC Wiki enemy entry even says: "If Link kills it with one of his weapons, it uses a small explosion, but if it runs into to him, it uses a big explosion which deals a damage of 2 hearts." If it was an intentional change, I believe it should be changed back because it undermines the threat of their charge at Link. Otherwise, the wiki (and possinly other documentation) could use an update.

 

This demo features a room with 4 Bombchus that always return on re-entry. You start with a variety of weapons you can use on them. Load it in 2.50.0 to check their normal vs contact deaths, then in 2.50.2 or 2.53.0 B2 to see that both deaths are the same. I have not tried this in 2.50.1.

 

Infinite Wallet Not Infinite: [Demo Quest]

 

This is a strange and complicated topic. Basically, the infinite wallet is not infinite in a number of contexts. It appears infinite on the surface, and in a few instances it truly is. But there's also the default finite rupee count lurking behind that "A" next to the rupee icon on the subscreen.

 

The finite rupee count is built by collecting standard rupee drops from enemy or grass drop sets. Rooms using the "10 Rupees" room type also build your finite rupee count when you pick up the individual rupees.

 

Rooms using the "Secret Money" type do not give you rupees. When you walk over the rupee icon, they don't show how many rupees you would have gotten if you had a standard wallet, nor do they play a pickup sound - and yet, if you walk over the rupee icon, then leave the room and come back in, the Guy and the rupee icon will be removed as if you had picked up the rupees.

 

Info Shops are also fully dependent on this finite rupee count - they do not work with only the infinite wallet. If you want info, you'll have to build your finite rupee count to the price of the info you want. However, once you purchase this info, it is not subtracted from your finite rupee count, and you can re-purchase the info as many times as you want.

 

By contrast, standard Shops do work with the infinite wallet. You can enter with no finite rupees and purchase anything you want for any price you want. However, once you purchase an item, it is subtracted from your finite rupee count, and if you go back to an Info Shop, you may not be able to purchase info if the item you purchased drained your finite rupee count too low.

 

These room types work with the infinite wallet, but also drain your finite rupee count: More Bombs, Door Repair, Life or Money, Gamble.

 

This demo starts you with an infinite wallet (but no starting rupee count) and offers a collection of all these room types. The first screen has the most broken two rooms: the Info Shop and the Secret Money payout. The next screen up has the most functional two rooms: the 10 Rupees and the standard Shop. The screen after that has the last four generally functional rooms: More Bombs, Door Repair, Life or Money, and Gamble. To the right of the start room is a screen with three always-returning Octoroks, all of which drop a 10 rupee coin 100% of the time. Basically, use the Octoroks to rebuild your finite rupee count, and wander between these rooms, testing out the situations I pointed out above and get a feel for how the current infinite wallet truly functions.

 

This behavior is consistent in 2.50.2 and 2.53.0 B2.

 

(I really should have just stuck that line at the beginning of the post and been done with it.)

 

There's some more things, but I'm totally spent bug-chasing for now, and I'm sure this'll be enough to keep you occupied for a while anyway.

 

Fantastic bug reports. Do any of these need old-quest compatibility support (I'm most concerned about the item pickup canceling message strings... has this feature been exploited in past quests?)

[CSD]

"Solid Secret Water-Sink"

 

Yeah I encountered that one before. The partial work-around for me was to reverse which state was the secret. Anyway I wanted to add that a similar bug occurs (I 'sort-of' reported it before) if you jump through a screen transition over water. Even though you're in the air, you'll be drawn swimming for 1 frame.

[DarkDragon]

Passage Subscreen Update: [Demo Quest]

 

When you use Tile Warp Type: "Passageway" to warp to another DMap with a different subscreen, the subscreen won't update to the new DMap's subscreen until an item is picked up. This is true for both passive and active subscreens.

 

This demo features an overworld and two dungeons, #1 (blue) using the same subscreen as the overworld and #2 (green) using a different subscreen. Start on the overworld. Enter the first dungeon; ignore the Amulet and stairway. See the subscreen remain the same. Exit the first dungeon to the overworld. See the subscreen remain the same. Enter the second dungeon; ignore the Silver Rupee and stairway. See the subscreen change. Exit the second dungeon to the overworld. See the subscreen change back. Enter the first dungeon; ignore the item and take the passageway to the second dungeon. See the subscreen remain the same (wrong). Now pick up the Silver Rupee; see the subscreen change (correct). Go back through the passageway to the first dungeon. See the subscreen remain the same (wrong). Now pick up the Amulet; see the subscreen change (correct).

 

This may or may not be relevant, but using Farore's Wind after taking the passageway to the new DMap will restart you in the original DMap even though the new DMap has its own "Continue Here" point.

 

(Each DMap has its own unique level number.)

 

This behavior is consistent in 2.50.2 and 2.53.0 B2.

 

Fixed.

 

Solid Secret Water-Sink: [Demo Quest]

 

In rooms with swimmable water on the edges, changing the water tiles to walkable floor tiles through use of a secret trigger will cause Link to sink into the new floor tiles as if they were still water tiles when he leaves the screen walks back in to it. This only occurs if Link has the flippers.

 

This demo features 2 rooms with water pools and twin side-bridges connecting each room. Start at the lower room and take one of the side-bridges to the upper room. Ignore the flippers and step on the floor button. This will raise a center bridge connecting both rooms via secret state carry-over. Walk down the new center bridge to the lower room and back to the upper room. Nothing happens. Now grab the flippers and walk back down and up again. In each direction, Link will sink into the walkable floor tiles, and you'll have to move to the next walkable tile as if you were climbing out of water.

 

This behavior is consistent in 2.50.2 and 2.53.0 B2.

 

Fixed, I think. This one is subtle. There's a 32-frame pause during screen scrolling before the scrolling begins proper. Previously, ZC would try to guess whether the new screen's combo would be water, and animate linking hopping/swimming accordingly. This guess did not take into account secrets on the new screen, or any other dynamic changes to that screen.

 

I've changed it so that Link's animation only changes after the 32-frame pause (but before the screen starts scrolling) when the next combo is known. This change will have a visible effect whenever Link transitions from water to land or vice versa during a scroll transition; I don't *think* it's any worse than the previous behavior but let me know if it causes problems.

[FireSeraphim]

Please try this:

 

In ag.cfg, under [graphics], add this line:

 

gfx_cardw=DXWN

It worked! now I can load zquest in 2.53! you know what this calls for!

Edited by FireSeraphim, 11 August 2017 - 08:55 AM.

[DarkDragon]

This may or may not be relevant, but using Farore's Wind after taking the passageway to the new DMap will restart you in the original DMap even though the new DMap has its own "Continue Here" point.

 

Oh boy. I'm not going making *any* changes to Continue behavior without a separate thread discussing if it's actually a bug, and old-quest ramifications of any change.

[Timelord]

It worked! now I can load zquest in 2.53! you know what this calls for!

 

I had to do some digging on that one. I do not know why overlay mode was being enabled by default for you, but I suspected that it was an improper initial configuration that was wrecking your ability to run the thing. The config should default to DXAC.

 

For reference, these are the valid options for gfx_cardw =

#  DXAC     - DirectX with hardware acceleration
#  DXSO     - DirectX without hardware acceleration
#  DXSA     - DirectX in safe-mode, with all the fancy features disabled
#  DXWN     - DirectX in windowed mode
#  DXOV     - DirectX overlay (fast windowed mode, only works on some cards)
#  GDIB     - GDI mode (slow windowed mode, works on all cards)

You may also try to set these for fullscreen, using: gfx_card = , however, none of these would correct the known fullscreen issues, to the best of my knowledge. 2.60 has hacks/fixes that rectify the majority of them, but 2.53 does not.

 

Note that the w in gfx_cardw = means 'windowed'.

 

I'm not sure if any of these gfx options would translate into ZC drawing faster, but I get 700 fps on 2.53, running 1st.qst, which, although slower than 2.50.2, seems acceptable. We'll see what happens. I'm trying to figure out why alleg44 can't do MIDI on modern Linux kernels, which is not turning out well.

Edited by ZoriaRPG, 12 August 2017 - 03:40 AM.

[DarkDragon]

Sword Spin Loss

 

Fixed. When Link becomes frozen (due to the guy's string in this case) his attack is now also canceled.

[DarkDragon]

Infinite Wallet Not Infinite

 

Fixed some issues related to the infinite wallet:
     - shops no longer play the rupy draining sound when buying with infinite rupies
     - info shops now respect the infinite rupy wallet
     - secret money rooms now display the rupies (not) gained when you hold the infinite wallet

[Lüt]

Beyond all of this, thank you very much for taking the time to do all of this testing for making demo quests, and for writing very detailed documentation on the issues. All of these things combine to make fixing these sorts of problems far, far, easier.

Fantastic bug reports. Do any of these need old-quest compatibility support (I'm most concerned about the item pickup canceling message strings... has this feature been exploited in past quests?)

Thanks guys

 

And you're welcome.

 

I wish I could say "no problem," but man, some of this gets technical and tedious. If this is what you have to go through every time people come across a vague problem, I certainly don't envy you.

 

Regarding the infinite wallet, I only came across the issues by accident. I've been updating a quest where Arrows = Rupees, so to test areas I couldn't skip through, I gave myself a gold arrow with 12 damage and piercing ability, and the infinite wallet so I could spam it endlessly. It's addictive beyond belief, and I dread the day I'll have to play the quest proper again. But there was an info shop near one of my start points, so I went to check that my strings were still set up right, and much to my surprise, I could only buy the first piece of info. Figuring it was because I had killed the two enemies on the way to the shop and picked up their drops, I killed a few more elsewhere and confirmed the finite money source, and that's how it started. I don't foresee ever having any practical use for the item in anything I do, nor do I imagine it suiting nearly every other project I've seen or played, but I suppose there's always somebody out there who could put it to creative use, so, might as well fix it for them.

 

Regarding old-quest compatibility support, I'm not the most well-versed player to answer, but I don't believe the removal of text from item shops accomplishes any functional purpose, and could the item drops becoming un-pick-up-able while buying info ever possibly be a point of exploitation, or anything other than an obvious bug for that matter? I don't really see how you could guide a player toward such a thing. Eddy mentioned he'd experienced the text disappearance thing in some of his shops when I brought the issue up in the PZC Discord server, but I believe he said it was only a minor nuisance and not something he actually wanted.

 

Anyway, the fixes all sound good. Thanks for looking into them. I'll mess around with the water/secret screen transitions more when the next version is out.

 

Now then!

 

You said you wanted to look into scripts compiled in 2.50.2 working in 2.53.0 and vice versa. Well, I started into that, and came across enough things to talk about - and further test - that I'll have to split most of it off into a separate post.

 

For this post, I want to focus on a few things that tie in to Linked Secrets on some level. This has become by far my #1 most used script in the months after ywkls and I sorted it out. It's an alternate flag-based secret system using arrays that can be attached to the current secret system in a multitude of ways, but also function on its own in a multitude of ways. First, I have two topics that I discovered while working with this, only one of which has a component fully dependent on the script.

 

Hammer Pound Differences: [Demo Quest]

 

Two issues here relating to inconsistencies rather than outright bugs.

 

First, when using the hammer on "Pound" combo types, the combo will function properly with any standard hammer weapon, but when that weapon is either charged or super-charged with the Quake or Super Quake technique scrolls, the pounding action fails to activate the "Pound" combo type.

 

Second, when using an FFC triggered by the hammer LWeapon (ID 19), attacking the top half of the FFC triggers it when the hammer pounds the ground, which is standard and consistent with the "Pound" combo type - however, attacking the bottom half of the FFC triggers it when the hammer is raised, rather than when it pounds the ground. It looks... awkward, to say the least.

 

This demo starts you with the 2 hammer technique scrolls and 2 charge rings (and the hammer obviously), and provides 3 hammer-peg rooms. The first uses standard pegs (combo type "Pound"), the second uses the same standard pegs (combo type "Pound") with the Linked Secrets script to make them permanent, and the third uses LWeapon FFCs to trigger separate peg combos that don't use combo type "Pound." 4-way movement is enabled to help accurately align Link with the upper and lower halves of the LWeapon FFC triggers.

 

Use the first room to see the difference between regular hammer attack and charged hammer attacks, use the second room to see that the behavior remains the same with the script applied (probably obvious, but included just for reference since we're discussing the script), and use the third room to see how attacking the top and bottom halves of LWeapon-triggered FFCs produces different trigger timing results.

 

(And no, I have no idea if anybody ever exploited the top-half/bottom-half functionality difference of a hammer-LWeapon-triggered FFC.)

 

As always, this behavior is consistent in 2.50.2 and 2.53.0 B2.

 

Fade-In Differences: [Demo Quest]

 

So at first, it would appear that the fade-in process for Item Cellars, Passageways, and Scrolling Warps is the same.

 

But no.

 

In trying to work around a long-standing inconvenience, I've combined secret tiles, combo cycling and the Linked Secrets script to create a permanent whistle-blown pond in an NES dungeon screen. The problem was this: every time I'd come back up from the Item Cellar or Passageway, the original unchanged tiles would be drawn during the fade-in, then they'd swap back to their proper assigned secret tiles after the fade-in had finished.

 

Desperate to avoid yet another level of hackage, I ran through all the tile warp types hoping to find a way around it, and wouldn't you know... during a Scrolling Warp, the proper assigned secret tiles were drawn during the fade-in, rather than after. So, the solution lies in the Scrolling Warp. See, graphically, it fades-in the same, but renderingly (?), it draws modified combos during the fade rather than after.

 

(Also, it updates the subscreen during the fade transition, which I was going to use as a reference point for the "Passage Subscreen Update" noted previously, before it got fixed.)

 

This demo includes two copy+pasted dungeon segments; the left one using a standard Item Cellar, and the right one using a Scrolling Warp to an item-cellar-like recreation in a separate DMap (walkability has been adjusted to allow for entering the stair warp from any angle). Check the left one to see the delayed rendering; check the right one to see the proper rendering. This behavior is the same with standard or interpolated fading. Also note the bombable northern walls, which is one reason I didn't simply change the screen type to Interior.

 

If you could... and geez I'd hope it could be this easy... if you could copy+paste the fade code from the Scrolling Warp function into the Item Cellar/Passageway function, you could fix the rendering process (and perhaps compare their subscreen updating methods as well). And even if it doesn't end up being the quick fix I'd hope it would be, it would still be great when it comes to working with permanently-changed combos on screens featuring an Item Cellar or Passageway.

 

And yeah, I'll admit, this is a rather self-serving request. I'm passing it off as a consistency issue, which it is, but in the end it's simply saving me having to come up with another level of hacks by duplicating an already-existing rendering method onto the Item Cellar/Passageway warp tile types. Still, even though I'm probably the only one depending on it at the moment, it's possible that this secret system may kick off when people see they can finally have permanent secrets in NES dungeon screens, so I'm sure I wouldn't be the only one it helps in the long run.

 

2.50.2 and 2.53.0 B2, you ask? Indeed, the answer is yes.

 

Compile and Compatibility Issues:

 

OK, here's where things get a little screwy.

 

First, the good news: I loaded the Linked Secrets demo from the database page, which was compiled in ZQ 2.50.2, into ZC 2.53.0 B2, and all the functions of the script showcased in the demo worked perfectly fine. I also loaded other projects using the script in a few other manners (two of which were the tests posted above) into ZC 2.53.0 B2, and they all worked perfectly fine as well.

 

Furthermore, I tested a much larger script compilation for a previous 2.50.2 quest update in 2.53.0 B2 - a compilation which includes enemy spawners, fire trail reductions, permanent block secrets, item pickup messages, heart piece messages, map/compass bundles, an anti-bump global item, no-move-on-fall global, Moosh pits, compass stop on item pickup/enemy death, boss music, Saffith's ghost-based SummonRobe control system, and of course Linked Secrets, and every single application of each script compiled in 2.50.2 worked perfectly fine in 2.53.0 B2.

 

But now, the issues - and before that, the files:

 

Linked Secrets Final Test (2.50.2 Compile) - The complete demo quest as compiled in ZQ 2.50.2, which works in ZC 2.50.2 and 2.53.0 B2.

Linked Secrets Final Test (2.53.0 Corruption) - The corrupted demo after script compilation in ZQ 2.53.0 B2.

Linked Secrets From Scratch (2.53.0 Rebuild) - A brief reconstruction of the first two rooms in the above demo quest, from scratch and compiled in ZQ 2.53.0 B2.

Linked Secrets script - the .z file with the script as featured in the above .qst files.

 

First issue - crashes and corruption. To check that scripts that were compiled in 2.53.0 B2 remained functional and backward compatible, I loaded the LS 2.50.2 Compile into ZQ 2.53.0 B2, imported LinkedSecrets.z into the buffer, hit "Compile!", got a success, and saved the file. Went to ZC 2.53.0 B2, loaded the quest, found myself on a black screen in a map with random glitches and malfunctions on other screens, and ultimately crashed ZC after wandering around a certain amount of screens. This happened 8 or 9 times in a row, and when I was about to denote the precise steps to recreate the corruption in ZQ, it started working. Then broke, then worked again, then broke again. Mostly, recompiling the scripts would just corrupt the file, and though it wouldn't be obvious after the first save, ZQ became incredibly unstable - as in, File -> New would consistently crash it (though on occasion you had to start a new quest twice), along with many other functions. Sometimes it would corrupt the file by recompiling the buffer contents without loading a fresh .z file, though it didn't seem to happen as often. And on rare occasion, ZQ would crash during the compile process. If it did, it was always at Step 2: Preprocessing.

 

Next issue - crashes aside, "successful" compilations of the script in 2.53.0 B2 still broke the script, and not a single function attached to it would work (though the original room secrets using ZQ default flags obviously still worked). This, at least, is recreateable, so you have something concrete to work with here.

 

OK, so here's how you work the files:

 

The "2.50.2 Compile" is essentially the LS demo on the database, slightly tweaked for this example. See how it works identically in ZC 2.50.2 and 2.53.0 B2. Now open it in ZQ 2.53.0 B2, load LinkedSecrets.z into the buffer, and compile. If the file doesn't corrupt when you save it, you now have a broken-scripted demo. Load it and see that nothing beyond the standard ZC secret system works. If you can't recreate the corruption, check the "2.53.0 Corruption" to see what I continuously got. For what it's worth, the corruption isn't random - ZQ spit out that exact same file with those exact same corruptions at least 15 times, so whatever's corrupting the file, it's systematic.

 

Next, load the "2.53.0 Rebuild" in either version of ZC to see that this reconstruction of the first two rooms in the original LS demo doesn't work when built and compiled from scratch in ZQ 2.53.0 B2. Now open it in ZQ 2.50.2, go to "Compile ZScript" and hit the "Compile!" button. Don't edit the buffer, don't load any .z files, just compile exactly what's already in the buffer. BAM! Demo now functions in ZC 2.50.2 and 2.53.0 B2.

 

So, that's that. Like I said, there's a small glut of points relating to the larger script pack that can come later, but for now, hopefully there's enough data to begin some troubleshooting with the 2.53.0 B2 compile process.

[ywkls]

Second, when using an FFC triggered by the hammer LWeapon (ID 19), attacking the top half of the FFC triggers it when the hammer pounds the ground, which is standard and consistent with the "Pound" combo type - however, attacking the bottom half of the FFC triggers it when the hammer is raised, rather than when it pounds the ground. It looks... awkward, to say the least.

 

This may be due to the fact that the script uses the Collision function from stdfunctions, which has been known to be less than 100 percent accurate.

 

On the difference on fade-in, did you have the flag "Run Script at Screen Init" checked? That should make it where that everything is changed the instant you enter the room no matter the method.

 

That being said, do these behaviors occur both in the original script as compiled in 2.50.2 and the newer version of ZC or only one of them?

 

Also, glad to see that you're still getting so much mileage out of that script !

[Timelord]

Compile and Compatibility Issues:
 
OK, here's where things get a little screwy.
 
First, the good news: I loaded the Linked Secrets demo from the database page, which was compiled in ZQ 2.50.2, into ZC 2.53.0 B2, and all the functions of the script showcased in the demo worked perfectly fine. I also loaded other projects using the script in a few other manners (two of which were the tests posted above) into ZC 2.53.0 B2, and they all worked perfectly fine as well.
 
Furthermore, I tested a much larger script compilation for a previous 2.50.2 quest update in 2.53.0 B2 - a compilation which includes enemy spawners, fire trail reductions, permanent block secrets, item pickup messages, heart piece messages, map/compass bundles, an anti-bump global item, no-move-on-fall global, Moosh pits, compass stop on item pickup/enemy death, boss music, Saffith's ghost-based SummonRobe control system, and of course Linked Secrets, and every single application of each script compiled in 2.50.2 worked perfectly fine in 2.53.0 B2.
 
But now, the issues - and before that, the files:
 
Linked Secrets Final Test (2.50.2 Compile) - The complete demo quest as compiled in ZQ 2.50.2, which works in ZC 2.50.2 and 2.53.0 B2.
Linked Secrets Final Test (2.53.0 Corruption) - The corrupted demo after script compilation in ZQ 2.53.0 B2.
Linked Secrets From Scratch (2.53.0 Rebuild) - A brief reconstruction of the first two rooms in the above demo quest, from scratch and compiled in ZQ 2.53.0 B2.
Linked Secrets script - the .z file with the script as featured in the above .qst files.
 
First issue - crashes and corruption. To check that scripts that were compiled in 2.53.0 B2 remained functional and backward compatible, I loaded the LS 2.50.2 Compile into ZQ 2.53.0 B2, imported LinkedSecrets.z into the buffer, hit "Compile!", got a success, and saved the file. Went to ZC 2.53.0 B2, loaded the quest, found myself on a black screen in a map with random glitches and malfunctions on other screens, and ultimately crashed ZC after wandering around a certain amount of screens. This happened 8 or 9 times in a row, and when I was about to denote the precise steps to recreate the corruption in ZQ, it started working. Then broke, then worked again, then broke again. Mostly, recompiling the scripts would just corrupt the file, and though it wouldn't be obvious after the first save, ZQ became incredibly unstable - as in, File -> New would consistently crash it (though on occasion you had to start a new quest twice), along with many other functions. Sometimes it would corrupt the file by recompiling the buffer contents without loading a fresh .z file, though it didn't seem to happen as often. And on rare occasion, ZQ would crash during the compile process. If it did, it was always at Step 2: Preprocessing.
 
Next issue - crashes aside, "successful" compilations of the script in 2.53.0 B2 still broke the script, and not a single function attached to it would work (though the original room secrets using ZQ default flags obviously still worked). This, at least, is recreateable, so you have something concrete to work with here.
 
OK, so here's how you work the files:
 
The "2.50.2 Compile" is essentially the LS demo on the database, slightly tweaked for this example. See how it works identically in ZC 2.50.2 and 2.53.0 B2. Now open it in ZQ 2.53.0 B2, load LinkedSecrets.z into the buffer, and compile. If the file doesn't corrupt when you save it, you now have a broken-scripted demo. Load it and see that nothing beyond the standard ZC secret system works. If you can't recreate the corruption, check the "2.53.0 Corruption" to see what I continuously got. For what it's worth, the corruption isn't random - ZQ spit out that exact same file with those exact same corruptions at least 15 times, so whatever's corrupting the file, it's systematic.
 
Next, load the "2.53.0 Rebuild" in either version of ZC to see that this reconstruction of the first two rooms in the original LS demo doesn't work when built and compiled from scratch in ZQ 2.53.0 B2. Now open it in ZQ 2.50.2, go to "Compile ZScript" and hit the "Compile!" button. Don't edit the buffer, don't load any .z files, just compile exactly what's already in the buffer. BAM! Demo now functions in ZC 2.50.2 and 2.53.0 B2.
 
So, that's that. Like I said, there's a small glut of points relating to the larger script pack that can come later, but for now, hopefully there's enough data to begin some troubleshooting with the 2.53.0 B2 compile process.

There is clearly something wrong with that test file. I cannot find a problem created by that script, though, in my tests. I created a blank quest in 2.53.0, and compiled that script, using both the old and new versions of ZQuest (2.50.2, and 2.53.0) and both appropriate versions of std.zh.

Saving and opening in crossed versions, and recompiling, using that script, did not cause any corruption. Is it possible that your test quest file itself was corrupted at some point, and you simply suspected this script to be the culprit?

I would like to see all of the scripts that you were compiling with this, at one time, to see if any of them are doing things that are simply wrong, bad, and could have memory leaks. This script in fact, does something rather terrible, by declaring a user array of ComboD[176]-- never make a user declaration using an identifier that is already reserved by ZScript internally, it is just a bad idea--  but that s not the cause of any of these issues.

 

I was also neither able to replicate your crashes when saving nor when compiling. Only when I loaded your test file, after compiling, did ZQuest crash. It also crashed when I attempted to load any quest, including a new quest, after loading the test file and compiling.

Edited by ZoriaRPG, 15 August 2017 - 08:26 PM.

[DarkDragon]

Fade-In Differences

 

Perhaps these differences are required for NES compatibility (with lake secrets, etc?)

 

In any case this probably needs a quest rule if changed.