I was going to put this in the other forum post, but I think this needs to be explained more in depth. Since starting runs back in October, I've experienced quite the amount of crashes throughout the months. This is mostly an emulator issue (for Xemu), so I can't speak for original hardware, however the same logic would apply for what I want to suggest regarding crashes.

I think that for any previous and future run, any run that has a crash should be retimed to get rid of that crash. I think it's unfair, and from my previous experience dealing with crashes, a bit demoralizing for your run to end by something you can't control that can happen randomly for no apparent reason. If this clause is allowed, defining how you retime it should be explained as well.

If a crash happens in a full game run then:

• The point where you started the level that you crashed on (the "press start" screen) to the point where you get back to that screen of the same level you were on (at the "press start" screen) should be taken out of the time of the run. Using an example from my 4:57:18 run, from 4:12:31 to 4:13:56 should be taken out of the run and retimed. There's 2 other crashes in the run, so those would have to be accounted for as well.

• During that segment of the run, I checked to see if the crash got rid of my paintjob progress. It did save my progress and I'm pretty sure that as long as you quit the race and the level select screen is loaded, your progress in the game saved. But let's say it didn't. I think how it should be retimed is that the player would do the previous level again (the one before the level that it crashed on), and from the start point of the previously played level (at the "press start" screen) to the point where they replay that level (at the "press start" screen), should be taken out as well. Hopefully that made sense.

• If the crash happens on the level select screen: I feel as if this has happened to me before once, but it's worth to note just in case. I think it should be retimed simply from the screen the crash happened on, to when the player gets back on to that same screen. This one might get complicated because of how the car selection section works (if it resets what car you would start on), so it's worth discussing further.

• The last thing I want to touch on is if the crash happens on a run with the DC easter egg activated. I think it should be treated the same as the first point I made, where the time where you get back to the "press start" screen wouldn't count against you, but as well as the time to get the DC easter egg reactivated. To add on for future reference, for when I do runs using the DC easter egg, I plan to reset the emulator (or the xbox if original hardware runs) at certain points to get rid of the easter egg so I can drive at normal speeds for certain levels. In my opinion resetting the xbox/emulator shouldn't be treated as a crash since the player is intentionally doing it, and as such should be timed differently (normally). (I only say differently because I would like the xbox/emulator leaderboards to be combined in favor for load times removed/IGT timer, but that's a discussion for another day :) )

I don't see Xemu getting fixed anytime soon, so I think this is a good middle ground to help current and future players enjoy running the game without the dread and annoyance of a run ending to a crash. If this clause is allowed, I will go out of my way to look for any of my previous runs that have crashes and retime them appropriately. I think the only other run that wasn't mine was from AndroidFanatic's All Required Paris Missions run just to note. Give any thoughts if you have some!

I'm on board with this, crashes are so frustrating to deal with, and I wonder if I will crash a lot more in a Max%, since my specs are like just enough to run MM3 (CPU always at or close to 100% during gameplay), but I dunno, this probably evens things between EMU and original, although, eventually, EMU will come out on top when MM3 can be run with no crashes. In a not so distant future I hope, but since Xemu isn't quite developed at something like PCSX2, it may take some time.

I ran MM3 on my old pc back in October, it's honestly the same if not worse on my newer better PC lol (at least in terms of amount of crashes not lag)

From my experience, crashing is an EMU thing (at least I've never seen it crash on real hardware). I'm always for running on original hardware and having EMU as an option being a nice to have (since running on console can sometimes be costly or less convenient). For a different game I mod (Skylanders Swap Force in this case) we retime the crash from the moment the game freezes or the console crashes (this is because the game on real hardware is known for crashing from time to time) and then the moment you get back into the game after the menu. Though on that game, the menu is only used to select a savefile. But a crash always loses you time since you have to restart the level after a crash.

So I agree with it being annoying. I could remove the crashing time, but in this case I would do it from the moment the game crashes till the moment you load back into your savefile. This makes it pretty manageable for me to retime instead of having to do a lot of research when the “real run” restarts. And it should be noted in the run description when the crash happens, since I'm not fully rewatching a 7 hour speedrun to check for crashes.

Let me know if that is an okay compromise or if you have any other ideas. (you can btw always ping me on Discord if you have any direct questions)

I think this is a fair compromise for the current status of MM3 runs on emulator, and yeah I imagine defining when the real run starts seems to be a lot more complicated due to where it can crash. I'd just hope in the near future xemu fixes the crash issue altogether. I'll resubmit my pbs for any crashes once the change gets made. Thanks for your input!