Raw Memory Card Path handling unification and consistency fixes. #10587
Conversation
AdmiralCurtiss
force-pushed
the
memcard-path-unify
branch
2 times, most recently
from
4b4dc48
to
9cc96c3
Compare
AdmiralCurtiss
force-pushed
the
memcard-path-unify
branch
from
9cc96c3
to
8faf23d
Compare
AdmiralCurtiss
force-pushed
the
memcard-path-unify
branch
from
8faf23d
to
8ec9f7c
Compare
|
Someone review/test this please! |
|
This is definitely a good change, sometimes it's hard to know which Memory Card a game is using when not using GCI folders, which is why I usually recommend people use GCI folders when possible. I've had to deal with a lot of support requests where users literally do not know where their memory card that actually has their savefiles is. |
…ROMPath() to new config system namespace.
…se forward slashes on Windows.
AdmiralCurtiss
force-pushed
the
memcard-path-unify
branch
from
8ec9f7c
to
4fd18cf
Compare
|
Works for me, tested and made sure my old AGP memory cards work, it would not let me use illegally named memory cards either. |
|
This broke mid-emulation memcard swaps. |
| const std::string old_eu_path = Config::GetMemcardPath(slot, DiscIO::Region::PAL); | ||
| if (eu_path != old_eu_path) | ||
| { | ||
| // ChangeDevice unplugs the device for 1 second, which means that games should notice that | ||
| // the path has changed and thus the memory card contents have changed | ||
| ExpansionInterface::ChangeDevice(slot, ExpansionInterface::EXIDeviceType::MemoryCard); | ||
| } |
There was a problem hiding this comment.
This whole part seems... unfinished? Why is it only checking PAL? Explains swapping being broken, as I'm using USA memcards, unless I'm misunderstanding something here. Also if I'm not mistaken, this GetMemcardPath is being called too late, as you set the memcard path just above.
There was a problem hiding this comment.
Why is it only checking PAL?
FWIW, I asked that question above and they put a comment, it's likely the same reason:
// The EU path is compared here, but it doesn't actually matter which one we compare since they
// follow a known pattern, so if the EU path matches the other match too and vice-versa.
There was a problem hiding this comment.
Ah, I see. It was in a comment a bit above this block of code so I missed it. Seems I was right on the second point though.
I've been aware for quite some time now that our handling of raw memory card paths is quite confusing and inconsistent. This should unify that into something sensible, hopefully breaking as few existing configurations as possible.
For details read the linked issue report, but in summary: Previously the code would behave sensibly if the path in the INI ended in
.{region}.raw, and misbehave in various ways if it didn't. In particular, if the configured path contained no region specifier, the behavior depended on whether the file existed or not, which effectively picks a different file on the first run compared to subsequent ones. Changing the path in the GUI did not verify whether the path contained a region specifier, which could easily get you into a confusing situation.Now the code will always pick a path containing a region specifier, regardless of how it's set in the INI or whether the file exists. Changing the path in the GUI now tells you to rename the card if it does not contain a region specifier.
(This is a slightly rewritten and partial #10379, which got massively stalled by people not agreeing about the form of GUI changes. As such, this contains no GUI changes except for a possible new error message.)