autosave saves as gamename.state.auto but autoload loads as gamename.state.
Is this correct or am I missing something?
Thank you.
No, autoload tries to load from .state.auto. Tested just now and it works fine.
Tested again and you are right, still outcome is the same, failed autoload:
edit: and before you tell me, YES, they natively support savestates, tested with 1944 and vhunt2.
Well, it definitely looks like it’s working from RetroArch’s side. Buggy core? It might not like savestates right after game load perhaps.
The feature having a meaningful use on systems without built-in save are the systems the feature is not compatible with. You never fix cores?
If the bugs are on our side, we try our best to fix things, but you can’t seriously think we have the resources to fix all emulation bugs in all cores ourselves. Sometimes we fix emulation bugs of course.
Savestates being broken for some FBA subsystems is not new. I’ve had lots of issues where savestates would work within a game session, but loading the savestate a bootup later, and it’s broken. Not sure what’s going on there. If savestates work across sessions and it’s only autosaving that’s broken, that could be a bug on our side.
Well, that’s why I report here, if you are already aware of the bug, then that’s fine, I’m done.
For me is always suprising to see how developers get all annoyed when a bug is reported, it’s all like, “worked here, it’s your issue”, instead of taking a positive approach and listen so things can get better.
It’s not any subsystem we are talking here, it’s CPSII savestates something IMHO critical, but it’s up to you guys if you want to fix it or not, or fixeable in that case.
Well, I’m not really that annoyed. I assumed the bug was actually savestate autoload doing the wrong thing, but it turned out to be something totally different. Had I not seen that FBA core was used in the log, I would not make any connection to FBA core savestates, etc …
These kinds of issues are not easily fixable and it’s always annoying to get bug-reports on something you know is hard to fix. It’s also annoying to get bug-reports whose causes likely originate from other codebases. That’s not a frustration towards users for being annoying, but more of a frustration knowing that some code is broken and is likely going to stay broken for a while.
Maister is exactly right about this.
I also once asked the FBA devs themselves for help with the savestate issue for the FBA libretro core but never received any help.
Another strong reason to fix this is to save the service changes, without savestates this is impossible. I would probably want to tune up difficulty, or even enable demo sound for attract mode. I also always wanted to keep scores so I have something to play against (yes, forever alone I know lol). I comment this now because it just came to mind while testing a few things.
Looks like savestates are working now but autosavestates and autoloadstates are not (fba core). Easy fix?