Project

General

Profile

Actions

Emulator Issues #11849

closed

Paper Mario TTYD: can't save after 100 trials pit

Added by v1993 over 4 years ago. Updated over 3 years ago.

Status:
Fixed
Priority:
Normal
Assignee:
-
% Done:

0%

Operating system:
N/A
Issue type:
Bug
Milestone:
Regression:
No
Relates to usability:
No
Relates to performance:
No
Easy:
No
Relates to maintainability:
No
Regression start:
Fixed in:
5.0-12202

Description

Game Name?

Paper Mario TTYD (Europe version)

Game ID? (right click the game in the game list, Properties, Info tab)

G8MP01

MD5 Hash? (right click the game in the game list, Properties, Verify tab, Verify Integrity button)

81321e8256205e3cfb71257e6ba2970f

What's the problem? Describe what went wrong.

After exiting pit of 100 trials at some point saving does not work. Not sure if emulator crash in the middle is related.

What steps will reproduce the problem?

Can't say if this is a minimal guide as checking is randomized and pretty tedious overall, but here is how it happened to me:

  1. Enter Pit of 100 trials
  2. Make savestate every 10 levels, never die or load them
  3. Encounter crash with Dark Wizzerd which fors turned invisible and then cloned itself (sounds like a separate bug)
  4. Start emulator again, load last savestate
  5. Continue going down for some time, make more savestates
  6. Leave using pipe at some point, go to TTYD
  7. Try to save using saveblock there and get an error that sd card is different

Is the issue present in the latest development version? For future reference, please also write down the version number of the latest development version.

Yes, checked on 5.0-10866, built locally.

Is the issue present in the latest stable version?

Can't say, would require a lot of playing.

If the issue isn't present in the latest stable version, which is the first broken version? (You can find the first broken version by bisecting. Windows users can use the tool https://forums.dolphin-emu.org/Thread-green-notice-development-thread-unofficial-dolphin-bisection-tool-for-finding-broken-builds and anyone who is building Dolphin on their own can use git bisect.)

Again, can't say for sure.

If your issue is a graphical issue, please attach screenshots and record a three frame fifolog of the issue if possible. Screenshots showing what it is supposed to look like from either console or older builds of Dolphin will help too. For more information on how to use the fifoplayer, please check here: https://wiki.dolphin-emu.org/index.php?title=FifoPlayer

It's not a graphical issue.

What are your PC specifications? (CPU, GPU, Operating System, more)

XUbuntu 19.04
Nvidia GeForce GTX 960, proprietary driver 430.40
16GB ram (+ 8GB ZRam)

Is there anything else that can help developers narrow down the issue? (e.g. logs, screenshots,
configuration files, savefiles, savestates)

I've copied save file (01-G8MP-mariost_save_file.gci) before entering pit (after last save before it) and used diff to compare it with one I can't save to. They appear to be identical, so no changes were made to it.
Not sure if it matters much, but I've pulled off Flavio glitch.

.gci file is attached, savestate can be found at https://mega.nz/#!wdEW2C6Z!pN9mmHYhAB61Zx-he1rqI1OilJwXPiDxsAOC0R_pWn0.


Files

01-G8MP-mariost_save_file.gci (136 KB) 01-G8MP-mariost_save_file.gci Latest save v1993, 09/08/2019 03:21 PM
Actions #1

Updated by JMC4789 over 4 years ago

  • Status changed from New to Questionable

I think what you did was load a savestate before the game initialized the memory card the second time, causing it break.

Tons of games have this behavior where they don't like if you load savestates in certain ways. It's just part of the risk with using savestates on something with removable media.

Actions #2

Updated by JosJuice over 4 years ago

Yeah, that must be the reason why it broke. But I'm curious why you're getting the issue even though the GCI file before entering the pit is identical to the one you can't save to... Is there something in the GCI folder code that makes it so that the contents of the virtual memory card aren't necessarily identical even if the GCI files are?

Actions #3

Updated by v1993 over 4 years ago

JMC4789 wrote:

I think what you did was load a savestate before the game initialized the memory card the second time, causing it break.

So up to which point I shouldn't load savestate? Am I getting right that there is some kind of SD card state which is not loaded when savestate does?

P.S.: I'm pretty sick of doing Pit over and over again (5 times total or so for now, still the same problem).

Actions #4

Updated by AdmiralCurtiss over 4 years ago

JosJuice wrote:

Is there something in the GCI folder code that makes it so that the contents of the virtual memory card aren't necessarily identical even if the GCI files are?

The memory card header serial is derived from the timestamp when it's formatted. We could maybe change that to a fixed value for folder cards, but not without rigorous testing to ensure this doesn't have the chance to corrupt data when a card is misidentified as identical when it's not...

Actions #5

Updated by JMC4789 over 4 years ago

It'd be worth testing to see if it helped. Lots of games do this. The easiest one I know of is Mario Tennis.

Actions #6

Updated by JosJuice over 3 years ago

  • Status changed from Questionable to Fixed
  • Fixed in set to 5.0-12202

Closing for the same reason as issue 11962.

Actions

Also available in: Atom PDF