Patch VC Crash 2 - #2619
Conversation
…ion was met. Fix US version's load-in progress display.
|
Super cool and super impressive! |
|
I'm not sure additional messaging for posting it is entirely necessary. People tend to post screenshots when something they don't expect happens and ask about it anyway. |
|
Do we have stats on how many people don't post when something unexpected happens? 🧐 |
|
People who don't post in the Discord in the first place which will ignore the message anyway. Nothing lost. |
|
Yeah i think it makes sense to hook up this message to the debug flag |
|
I disagree with that. We need the message at least initially so that we can see when the issue reoccurs to see how often it actually happens, especially if it hasn't always caused crashes. We also want to see if it occurs and causes a different crash or if a different crash happens and this is entirely unrelated. |
|
But not at the cost of confusing casuals and having this spun up to people who's first thought would not be to run to our bug reports channels. Stuff like that should at the very least not belong into a full release, i am okay with having it in dev though. |
|
Yeah, that sounds like a fine compromise to me. |
First: Found a function call during rom loading that contained a progress value! It did nothing, so hooked that to get a nicer percentage display. So that should fix the load-in progress value during start-up and resume from home menu.
Now for the other crash.
This is such a rare crash that it's wild two people got it so close together recently. It's identifiable by the SRR0:80040738 and DAR:00000040 present on both the N64 registers and Wii GP registers pages.
MMR had this same crash almost three years ago, but back then I figured it was a side-effect of the unpatched cpuExecuteCall bug, and without the more extensive decompile work done on the WiiVC to reference, gave up trying to track it down.
The error this is fixing: https://github.com/zeldaret/oot-vc/blob/9c1853710bcf6b598b0710022fdb87b9a8e99e2c/src/emulator/cpu.c#L12847-L12850
if the values
startandendfit right between a restore node'snAddress0andnAddress1, the restore node won't get nulled when it should, leading to its data becoming stale and possibly leading to a crash in a later call of the function treeCleanNodes.There's no need to check where
endis, ifstartis greater thannAddress0, and equal or less thannAddress1, then root->restore should be nulled.I've hooked up a screen print function on the patched crash condition, to see if this possibly occurs more often than it does crash. Hope to only see this in another three years!
(...I hope there isn't any other causes to this crash...)
Testing
Played US version for a bit on Wii to check stability, seems fine. Forced the error message to see that it displays on correctly on wii too. JP version was booted into game and seems okay.