Cleanup and fix Dampe's race both prizes regression - #6999
Conversation
|
Good with better fix 👍 |
I'm sorry. You'd already put in a fix by the time I even saw that there was an issue, and it wasn't until later that I realized what I'd done wrong. I thought your fix would be good enough, but then it just sat there untouched for long enough that I decided to fix it my way. I was waiting for someone else to reply to your question about the treasure flag.
That function call was added way back in #416 (author: @Kenix3). That's all I know. I have no idea how much has changed since then or if it still has a purpose. |
There was a problem hiding this comment.
It's all good!!
I've tested this fix on vanilla and randomizer with native treasure flag with/without Hookshot/flag set and it seems to work well. The custom flag maybe was required for earlier randomizer handling (can't find any targeted GetTreasure check for it).
Might want to clarify in the tooltip that it rewards the "within one minute" second reward only if you reach the goal within a minute, otherwise you get the junk reward.
| if (IS_RANDO) { | ||
| Flags_SetTreasure(gPlayState, 0x1E); | ||
| } |
There was a problem hiding this comment.
| if (IS_RANDO) { | |
| Flags_SetTreasure(gPlayState, 0x1E); | |
| } |
| this->hookshotSlotFull = | ||
| (INV_CONTENT(ITEM_HOOKSHOT) != ITEM_NONE && !IS_RANDO) || (IS_RANDO && Flags_GetTreasure(gPlayState, 0x1E)); |
There was a problem hiding this comment.
this->hookshotSlotFull = !IS_RANDO ? (INV_CONTENT(ITEM_HOOKSHOT) != ITEM_NONE) : Flags_GetTreasure(gPlayState, 0);
There was a problem hiding this comment.
How do we know this isn't why the Flags_SetTreasure call is there?
There was a problem hiding this comment.
It probably was originally, but because the temp Flags_SetTempClear(play, 4) is the only thing directly seen in the code, it wasn't clear that this leads to EnBox spawning, that when opened will set permanent Flags_SetTreasure for its treasure flag 0x0. So I think it was trying to add a permanent flag that in hindsight isn't necessary.
[z_actor.c:684] [info] Switch Flag Set - 0x34
[z_message_PAL.c:2686] [info] Display Text - textId: 0x502f
[z_message_PAL.c:2686] [info] Display Text - textId: 0x502d
[z_actor.c:752] [info] Treasure Flag Set - 0x1e
[z_actor.c:771] [info] Clear Flag Set - 0x4
[z_actor.c:752] [info] Treasure Flag Set - 0
[hook_handlers.cpp:391] [info] Queuing RC: 180
[hook_handlers.cpp:428] [info] Queuing Item mod 0 item 3 from RC 180
[hook_handlers.cpp:464] [info] Attempting to give Item mod 0 item 3 from RC 180
[z_message_PAL.c:2686] [info] Display Text - textId: 0x31
[z_parameter.c:1862] [info] Item Give - item: 0x3
[hook_handlers.cpp:481] [info] Item received mod 0 item 3 from RC 180
[SaveManager.cpp:1220] [info] Save File Finish - fileNum: 1
| player->actor.world.pos.z) != 0) || | ||
| (Math3D_PointInSquare2D(1580.0f, 2090.0f, -3030.0f, -2500.0f, player->actor.world.pos.x, | ||
| player->actor.world.pos.z) != 0)) { | ||
| speed = (this->hookshotSlotFull) ? player->actor.speedXZ * 1.4f : player->actor.speedXZ * 1.2f; |
There was a problem hiding this comment.
I saw in z_bg_relay_objects.c that there is an if (INV_CONTENT(ITEM_HOOKSHOT) != ITEM_NONE) check for timer length. As this->hookshotSlotFull also adjusts Dampe speed, should timer check also be changed to depend on treasure flag if randomizer?
|
Can I get a nudge on this? This should be merged as soon as possible, but I feel like this issue of the treasure flag needs to be resolved first. |
3 participants
As reported on Discord:
I did a stupid when making that option by separating it into two hooks that were supposed to cover both rando and the option itself. The problem was that both hooks required the Hookshot slot check to be false, but then set to true, meaning that whichever hook ran first would override the other one. I've fixed this by uniting the two hooks into one. I also did a bit of syntax cleanup and renaming.
Hopefully someday I'll learn not to make that mistake again.
Build Artifacts