hrydgard / ppsspp

A PSP emulator for Android, Windows, Mac and Linux, written in C++. Want to contribute? Join us on Discord at https://discord.gg/5NJB6dD or just send pull requests / issues. For discussion use the forums at forums.ppsspp.org.
https://www.ppsspp.org
Other
11.02k stars 2.15k forks source link

Savedata iteration order doesn't match the real PSP? #16939

Closed hrydgard closed 1 month ago

hrydgard commented 1 year ago

NABN00B on Discord:

After booting GTA LCS/VCS, the save file with the lowest slot number is loaded, on PSP the save file with the most recent date - does that happen in other games as well?

Sergey confirms that the order is different.

Should be looked into.

unknownbrackets commented 1 year ago

Hm, this is probably a setting then? What I recall happening on a PSP is that the latest save is highlighted by default (see SceUtilitySavedataFocus) but that it's sorted in 0, 1, 2, 3 order - at least in the games I played. You could even have gaps. Maybe GTA sends a different flag?

Also, this says "loaded" - is it really the "iteration order" or is there some issue with one of the focus methods (maybe SCE_UTILITY_SAVEDATA_FOCUS_FIRSTDATA should be by date rather than order, etc.)?

-[Unknown]

NABN00B commented 1 year ago

Hm, this is probably a setting then? What I recall happening on a PSP is that the latest save is highlighted by default (see SceUtilitySavedataFocus) but that it's sorted in 0, 1, 2, 3 order - at least in the games I played. You could even have gaps. Maybe GTA sends a different flag?

Also, this says "loaded" - is it really the "iteration order" or is there some issue with one of the focus methods (maybe SCE_UTILITY_SAVEDATA_FOCUS_FIRSTDATA should be by date rather than order, etc.)?

-[Unknown]

There are two different things here:

Domiiniik commented 1 year ago

Bump, this is actually a really annoying problem in GTA, in hopes it can be fixed up for 1.16..

ThirteenAG commented 11 months ago

I'm not sure how to debug this properly, but I tried to follow where the code goes wrong and managed to make a workaround for gtavcs: https://github.com/hrydgard/ppsspp/compare/master...ThirteenAG:ppsspp:master

What's going on is: Startup: 1) call to SavedataParam::SetPspParam with param->mode == SCE_UTILITY_SAVEDATA_TYPE_AUTOLOAD && param->focus == SCE_UTILITY_SAVEDATA_FOCUS_LATEST. param->saveNameList is not nullptr. 2) call to SavedataParam::SetPspParam with param->mode == SCE_UTILITY_SAVEDATA_TYPE_AUTOLOAD && param->focus == SCE_UTILITY_SAVEDATA_FOCUS_LATEST. At this point, ppsspp can't construct a list of available saves, so it defaults to slot 0 here.

Ingame: 1) Only one call to SavedataParam::SetPspParam with param->mode == SCE_UTILITY_SAVEDATA_TYPE_LISTLOAD && param->focus == SCE_UTILITY_SAVEDATA_FOCUS_LATEST. param->saveNameList is not nullptr. The key difference here, UI is gonna show up, which doesn't happen on startup and ppsspp handles these calls in PSPSaveDialog::ExecuteNotVisibleIOAction. Could be related to the underlying issue.

So, to workaround: 1) On startup, on first call of SetPspParam, I cached param->saveNameList, then inserted cached value during second call. 2) In order to get latest save path, I had to comment case SCE_UTILITY_SAVEDATA_TYPE_AUTOLOAD: in two functions: PSPSaveDialog::GetSelectedSaveDirName() SavedataParam::WouldHaveMultiSaveName(const SceUtilitySavedataParam *param)

Hope this helps to get to the root of the problem somehow.

Parik27 commented 1 month ago

The VCS bug is not related to the savedata iteration. The game does its own by calling sceIoGetstat on directories in "ms0:PSP/SAVEDATA" and picking up the one with the lowest m_time. On Linux at least, this always seems to return year=1900, month=1, day=0, so the game ends up picking the first one it finds in the directory.

I don't know how @ThirteenAG 's workaround works, but the game does not set saveNameList on autoloads, only the saveName.

hrydgard commented 1 month ago

Oh, that's good information!

I'll look into the mtime issue, we should not be returning 1900..

ThirteenAG commented 1 month ago

We've been looking at the wrong thing, good to see this finally figured out.