Can not save if load a savestate which saved before the savedata.

[daniel229]

A few games affected,Monster Hunter series,Patapon series.
Make a savestate

Make a savedata

Load the savestate previous make

Unable to save

[LunaMoo]

That's a game protection(kind of pointless through:P), it just stores hash of previously made save in memory and compares it to the save before allowing to overwrite existing save.

Some of the games which do this, allow saving when you delete your current save, dunno about patapon, but MH does not, so it has to be hacked(already did via cw cheat on the forum). I don't think you can do anything emulator side to universally avoid this issue.

[daniel229]

Delete the save folder,it's not saving.but it allow saving when delete SECURE.BIN.

[unknownbrackets]

The only way I can think of to do this is by including the savedata in the savestate and overwriting it when you load state (or otherwise pretending and committing it on write, which would be complicated), I think. I would not like this, personally...

-[Unknown]

[LunaMoo]

@daniel229 If you're interested in solving this via hacks as I mentioned already existing on the forums for some MH games, I just made one for Patapon 3 as well, it's pretty easy since this game doesn't even generate any hash, it just counts numbers of times saved and compares that.

I have UCUS-98751 version so the address will likely be different on your version, but you should be able to find it easily by searching for integer value which increases by 1 every successful save(ie using Cheat Engine for example), then set a breakpoint at the address(using ppsspp disassembly) to check what reads it when you try to save. It should break at something looking like this:

then just look a bit down in same function until you see something like:

You could probably also just try to find same function via ppsspp disassembly as the addresses often does not differ much between different versions of the game.
And that highlighted address is the one you want to change for cheat, this is how it would look for my version done via cw cheat:
_S UCUS-98751
_G Patapon 3
_C0 Allow saving over newer save
_L 0x20223C44 0x1000000B

it changes "beq s0,s2,0x08A23C74" to "beq zero,zero,0x08A23C74"(or "b 0x08A23C74" as it shows in disassembly:3) which makes it always branch like the save was correct, it does not check it for any important reason anyway, probably it was done to stop people from saving over their different saves when swapping memory sticks, certainly they did not made it predicting savestate abuse in emulators:].

Hacks like that must be done per game, but in the end activating simple cw cheat is not a big deal comparing to including saves within a savestate. I prefer them as it's now, keept separately.

[daniel229]

@LunaMoo Thanks for your tutorial,Is the address need to be converted,It does not break anything.

[daniel229]

Got it.
1.the Cheat Engine setting like this

2.search 0 between 3000 (or whatever value that is large enough)
then scan type set to increased value by 1 then would get these addresses

PPSSPP address = the address in the list 0xZZZZZZZZ - 0x03020000
then break the PPSSPP address in disassembly,would get something like @LunaMoo posted.

_S UCAS-40318
_G Patapon 3
_C0 Allow saving over newer save
_L 0x20223814 0x1000000B

[LunaMoo]

@daniel229 Oh sorry yeah I did not write what to do with CE itself, the way to actually calculate the address without doing anything extra would be checking ppsspp log when you run first game after starting ppsspp, as one of the first things it'll show where psp memory was allocated, it'll look alike:

 MemMap.cpp:338 I[MM]: Memory system initialized. RAM at 000000000BC80000 (mirror at 0 @ 0000000088810000, uncached @ 00000000C8810000)

(different for you ofc)
Now from that we can see that psp ram starts at 0x0BC80000, game does not load at the start of the ram through, because 8mb is reserved for kernel, so to that address, we have to add 0x800000:
0x0BC80000 + 0x800000 = 0x0C480000 that would be where game loads to memory, now find the address in CE again, for example let's say it was 0x0D123450, to get psp address, you have to decrease it by what we got earlier: 0x0D123450 - 0x0C480000 = 0x00CA3450 and then increase the result of it it by 0x08800000 because that's how it is on psp, so in the end 0x00CA3450 + 0x08800000 = 0x094A3450 now that address would show the place in ppsspp disassembly.

But it's not the only way, so yeah, glad you figured it out.:3

Happy new year!^_^

[daniel229]

Thanks for your explain,that make much clear about the ram address and psp address and happy new year.

[unknownbrackets]

Another option might be to check when loading a state if the savedata has been modified since the savestate was made (maybe with a contained timestamp or...), and prompt the user to let them know this problem may occur due to the way games are programmed. That may be the best option.

-[Unknown]

[sum2012]

edit:read again the post,I don't think need my information.
edit2:Add Patapon 3 bad save https://drive.google.com/file/d/0B3OaSdeV0L8kVVNKWXR3TEhIek0/view?usp=sharing

[HeiroMarc]

Could you guys create a video for this? I'm little bit confused...

[LunaMoo]

There's nothing a video would help in here. The problem is simple, some games have features that doesn't allow the user to write a new savedata over savedata they don't recognize as previously made one.
If you jump into past by loading savestate made before last normal save or if you replace your memstick with another one the game feature works and stops you from being able to overwrite the unknown data.

All you can do after it already happens is restart emulation and reload the game from actual savedata remembering to never jump back in time with savestates again this will fix everything by itself.

If such exist you could also use a cwcheat hack like few shared on the forums or the patapon ones above which intentionally break this game feature to allow saving over unrecognized savedata. Sometimes just deleting existing savedata can also work, but unfortunately those features can be weird and some games will never allow you to save from in-game unless they recognize previously made savedata or notice that existing savedata is actually corrupted.

[unknownbrackets]

There's now a warning shown when you (probably) get into this situation. You can also use "undo last load" to revert the load state and regain the ability to save when you see the warning.

If people can confirm that this warning shows and undo works to regain saving in games, that'd be really useful.

If anyone sees the warning in a really normal use case that'd be interesting too.

-[Unknown]

[inukaze]

@daniel229 If you're interested in solving this via hacks as I mentioned already existing on the forums for some MH games, I just made one for Patapon 3 as well, it's pretty easy since this game doesn't even generate any hash, it just counts numbers of times saved and compares that.

I have UCUS-98751 version so the address will likely be different on your version, but you should be able to find it easily by searching for integer value which increases by 1 every successful save(ie using Cheat Engine for example), then set a breakpoint at the address(using ppsspp disassembly) to check what reads it when you try to save. It should break at something looking like this: then just look a bit down in same function until you see something like: You could probably also just try to find same function via ppsspp disassembly as the addresses often does not differ much between different versions of the game. And that highlighted address is the one you want to change for cheat, this is how it would look for my version done via cw cheat: _S UCUS-98751 _G Patapon 3 _C0 Allow saving over newer save _L 0x20223C44 0x1000000B

it changes "beq s0,s2,0x08A23C74" to "beq zero,zero,0x08A23C74"(or "b 0x08A23C74" as it shows in disassembly:3) which makes it always branch like the save was correct, it does not check it for any important reason anyway, probably it was done to stop people from saving over their different saves when swapping memory sticks, certainly they did not made it predicting savestate abuse in emulators:].

Hacks like that must be done per game, but in the end activating simple cw cheat is not a big deal comparing to including saves within a savestate. I prefer them as it's now, keept separately.

Hi there, you can help me with "Monster Hunter Freedom Unite" (EUR) [ULES01213_1.01], i am using PPSSPP 1.10.3 (because the superior versions i can't play with friends because can connect but nobodys appears on the lobby except me) .

Well my point is on some point i load state, and i am try to save the game normally, but show me the message the "Memory Stick is not inserted", i want to use the memory hacks to force the overwrite of savegame because i had a lot of hours played from that (near 300 hours of gameplay from the error).

But i don't understand the screenshot and how i should write the code on the PPSSPP emulator for make this ?
You had some mini-tutorial how make this hack for overwrite the battery save game ?

[LunaMoo]

https://github.com/LunaMoo/PPSSPP_workarounds

[inukaze]

https://github.com/LunaMoo/PPSSPP_workarounds

Thank you very much for the link

[unknownbrackets]

It seems like people still hit this sometimes, despite the warning added in #14434. That either means people are ignoring it, disabling it, or there's a bug and they're not seeing it.

Is anyone able to confirm that they always see this message when they get themselves into this situation? I'm considering if we want to add something in the header so we can show more obtrusive UI for this (maybe we could have a flag per game where we know the game doesn't care to hide the UI, though, especially for games that autosave.)

Would that help?

-[Unknown]

[unknownbrackets]

Thinking about #16444, I wonder if a component of this is the file modification time of files when you use save states or fast forward.

Currently, if you start a game on 2022-12-15, and then play for 4 hours and create a save state, any savedata you create will also be marked 2022-12-15.

But then if you later load that save state on 2022-12-16, time within emulation will correctly still be 2022-12-15. But if you update savedata, the modification time will be 2022-12-16 (the future, scary.)

It can go the opposite way using fast-forward, where recently created savedata could be stuck well in the past. If you fast-forwarded on a desktop for an hour, you could easily be at 2024-01-01 within emulated time, but new savedata would still be created with a modification time in 2022.

Maybe discrepancies in savedata time vs "current time" are causing games to reject savedata sometimes.

-[Unknown]