New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Keep memory card header and use it to reinitialize GCI folders on mismatch. (Fix savestate with GCI folders) #8879
Keep memory card header and use it to reinitialize GCI folders on mismatch. (Fix savestate with GCI folders) #8879
Conversation
|
Oh, and as an extra note, #7396 may or may not be required as well for some games. Hard to say, but couldn't hurt. |
|
This fixes almost every game that complains about the memory card being different on loading savestates. The Pokemon Games probably require individual patches if we want to solve them. |
|
This isn't compatible with save states made in the previous version, right? |
|
That's generally how things work. Savestates are meant to be temporary and the actual saves made more permanent. This will make it much easier to keep using memory cards though, which is good. |
d353afb
to
998d9c6
Compare
|
That sucks, since I'm using a save state instead of saves due to this very issue. Wouldn't there be any way to convert a save state to the next version? |
|
The data required to fix your problem is literally not in your (old version) savestate, or at least not at a known location. You'd have to manually find the memory card serial ID in your savestate's game RAM. |
998d9c6
to
40d6b96
Compare
|
And how would I do that? |
|
Exactly how to do that is not something I believe anyone here has any significant experience with. All I can say is that you have to reverse engineer the game a bit. If you want to ask about how to do it, please do so on the forums instead of here, since it's not relevant to the development of this pull request. (Not that I think people there know much about it either.) |
…e the relevant values instead.
40d6b96
to
c759fbe
Compare
…f data for consistent initialization.
…XI_Channel and pass it down to the memory card device.
…rd, reinizialize it with the header from the savestate to let a game still recognize it as the same card.
c759fbe
to
476c959
Compare
Note: The first two commits are also found in #8880. It doesn't really matter which gets merged first.
This is a safer but more complex implementation of #8476. Instead of hardcoding a card ID, we store the memory card header data in EXI_Channel and ensure the same game session (including savestates) always sees the same card header. This is necessary because some (apparently many!) games check this and will refuse to save to the memory card if they believe the card is a different card they initially loaded from.
Whenever we create a new GCI folder memory card, we pass along the header data to the device, which ensures that eg. switching from GCI folder to No Memory Card back to GCI folder while the game is running still results in the same header. Additionally, when loading a savestate, we compare the card header in the savestate to the card header of the current session and will reinitialize all GCI folder cards with the header from the savestate on mismatch.
It does feel a bit silly to store the card header data in EXI_Channel, but it seems to be the best place for it.
Oh, and I'm not 100% sure how many of my security precautions here are actually necessary, but I figured it's better to be safe when it comes to save files.