Bugfix for AlwaysOnFixes.cpp as well as a fallback to prevent crashes when attempting to display an textId 0

[HighTierHumann]

In the VB_CHANGE_AIMING_CAMERA block within AlwaysOnFixes.cpp, the code simply checks if link is holding opposite-age equipment before overwriting the camera mode. In normal circumstances this is fine, but you are no longer able to peek through walls with the camera while holding said equipment, as CAMERA_MODE_FIRST_PERSON is overwritten with one of the aiming modes. I added a guard that checks if the current mode is CAMERA_MODE_FIRST_PERSON before attempting to overwrite it.

Additionally, magic arrows were previously not accounted for, and Hookshot/Longshot never had camera fixes as Child outside of Lakeside Laboratory, even if Scaled Equipment was enabled.

There is also a bug that seems to be related to AssignableTunicsAndBoots.cpp that very often triggers when turning in Ruto's Letter, which somehow overwrites King Zora's textbox and causes textId to be 0 which crashes. This isn't exclusive to just this interaction, but it seems to most commonly apply there; see the attached log file for a crash I was able to reproduce by turning in Ruto's Letter until it happened on 9.2.3 stable.

The temporary fix provided in the pull request simply falls back to a random Navi text, 0x140, preventing the crash. In the case of turning in Ruto's Letter, the player need only trade it in again to move King Zora; the bottle isn't lost when the fallback occurs.
Ship of Harkinian.log

Build Artifacts

• soh-windows.zip
• soh-mac.zip
• soh-linux.zip

[djevangelia]

Hmm... have you been able to replicate the id 0 textbox in develop? There is a textId 0x0 check further down (line 2742 here) that has been added since release. (Console behavior is to show textId 0x1 for 0x0)

That AssignableTunicsAndBoots can give textbox id 0 and in other circumstances too seems bad, how exactly do you replicate it? Enable "Assignable Tunics etc" and give KZ the Letter as child?

[djevangelia]

I think it should be possible to move the GameInteractor_Should(VB_CHANGE_AIMING_CAMERA, true, &this->heldItemAction, &camMode) hook up into the if (this->unk_6AD == 2) block (2 is Bow/Slingshot/Hookshot aiming camera flag), after the Boomerang check.
Then it should only overwrite aiming cameras and not the unarmed first person, so the check inside the hook wouldn't be needed. Magic arrows addition good fix.

[HighTierHumann]

Ah, ok I didn't spot that check; that should resolve the issue. The way I replicated the crash was equipping Ruto's Letter to D-Pad and turning it into KZ over and over until it finally did crash. Don't know if it being on D-Pad actually matters, but it did eventually crash after ~30 attempts. Crash log is the same as 2 others I've looked at that were caused organically.

I didn't look too deeply into the player code, but it makes sense to move the hook into that block and avoid the guard altogether.

[djevangelia]

KZ has a vanilla bug in first OoT versions that can make him have textbox 0 on showing trade items, if you talk to him exactly when getting out of range (I have described it in more detail here and link there).
I looked at the SoH code now assuming it would be fixed because SoH usually uses newest available version - but actually it's really easy to trigger this if you have Early Eyeball Frog on, do you have it?

The reason why the assignable hook shows up is because it is hooking the call to run player's current action function which is the core of player behavior (run, talk, attack etc), but it seems innocent.

[HighTierHumann]

That's probably the culprit yea. I do have early eyeball frog on.

[HighTierHumann]

Can confirm this is indeed fixed on the nightly. Receiving the same Pocket Egg text when the crash would otherwise occur.

[djevangelia]

I'll fix the KZ textbox bug, as I've worked with it previously 😺