GUI -> Savestate panel ~ does not show savestate screenshots for .uss files associated with HDD/whdload usage [cosmetic?]

[giantclambake]

My guess would be this function is (has always been) intrinsically .adf centric (where all this works fine now). Opening up savestate usage as discussed, means this should probably be fixed....

• Currently, savestates created for HDD/whdload scenarios, do not have their associated screenshots displayed in the Savestates panel, nor is the Name: of the load savestate file is displayed.

Note: This seems purely cosmetic ~ even if the screenshot/name isn't displayed, doing amiberry somename.uss to direct load, and hitting F12 -> Savestates --> Save (to the correct slot), does in fact work as expected (overwrites existing .uss file)...you just can't see anything (so you have to know the correct slot# ;)

Expected: HDD/whdload related .uss usage should display associated screenshots like floppy image associated .uss files do.

Can this be fixed?

TIA

[midwan]

That's news to me.
I've been testing with WHDLoad (.lha) titles while fixing the naming issue we discussed before, and it's been working as expected for me.

Maybe there's something else that triggers the problem for you?

[giantclambake]

I was testing with RC2 ~ let me recheck master

[giantclambake]

Seems easy and consistent to reproduce here (RC2 & master) ...ergo, must be procedural or such...

Test conditions;
-Savestates path -- savestate_dir=/home/gcb/Desktop
-Using cmdline for examples, but know direct-loading using mime-types is analogous, giving the same results

Test 1:

• amiberry SysInfo.adf //direct-load the .adf file, emulation starts, wait for Sysinfo to load it's UI
• Hit F12 -> Savestates panel....

• leave Slot 0 selected --> click on Save State ...

• Quit amiberry

Follow on with direct launching the resultant SysInfo.uss file...

• amiberry ~/Desktop/SysInfo.uss //direct-loads the savestate file as expected
• Hit F12 --> Savestates panel

Observations: the screenshot associated with the (currently loaded) .uss file is displayed. along with date/time stamp. I would consider this to be working as expected...

Note: If this were a game .adf instead, I can play through the game, and at any time F12 --> Savestates panel, and overwrite/update the .uss file, and the date/time stamp and screenshot is updated accordingly.

Test 2:

• amiberry MontyPythonsFlyingCircus_v1.3_0273.lha //direct-load the .lha file, emulation starts, wait for game to load it's main menu
• Hit F12 -> Savestates panel....

• leave Slot 0 selected --> click on Save State ...

• Quit amiberry

Follow on with direct launching the resultant MontyPythonsFlyingCircus_v1.3_0273.uss file...

• amiberry ~/Desktop/MontyPythonsFlyingCircus_v1.3_0273.uss //direct-loads the savestate file as expected
• Hit F12 --> Savestates panel

Observations: the screenshot associated with the (currently loaded) .uss file is NOT displayed, however, the date/time stamp is displayed, and is correct (date/time of .uss file creation) ...however, this is a misnomer of sorts.

Note: without the screenshot being there, if I 'blindly' save the current state into 'Slot 0', it will overwrite/update the ~/Desktop/MontyPythonsFlyingCircus_v1.3_0273.uss file as expected.

• Quit amiberry

Test 3:

....found another wrinkle & test case doing this ....go back to Test 1 ....

• amiberry ~/Desktop/SysInfo.uss //direct-loads the savestate file as expected
• Hit F12 --> Savestates panel...

...if I click on another Slot #, that does not contain an associated .uss file, I see this...

...noting the text ... No save state found: <name>[-<slot>].uss

• Quit amiberry

Follow on, by doing the same procedure wrt Test 2 ....

• amiberry ~/Desktop/MontyPythonsFlyingCircus_v1.3_0273.uss //direct-loads the savestate file as expected
• Hit F12 --> Savestates panel

...if I click on another Slot #, that does not contain an associated .uss file, the same date/time stamp is always displayed (regardless of slot selected), and the telltale text 'No save state found: <name>[-<slot>].uss' is not shown.

Test 4:

Is pretty much a duplication of Test 2, except using HDD based save states (instead of whdload.lha files) ~ the same issues are evident, including that detailed in Test 3.

It occurred to me, that the whdload/whdbooter process, is more HDD operations than not, and the one thing both these scenarios share, is they don't boot from a floppy image inserted into DF0: ... =) It gives me the impression something simply isn't entertaining HDD/whdload save states here.... however save states wrt .adf work flawlessly as per Test 1.

HTH

[midwan]

Found and fixed.
There were a few errors in how things were handled, when using the command line. It worked from the GUI, which is why I missed it before.