QuickRestoreState allows but a single SaveState?

[SunChild]

Well, following my previous bug report from a week ago, I dare come here again to bug Toni once more (I'm actually surprised no one ever mentioned this issue — indeed someone prolly did), to report another bug, this time about the Quick Restore State assignable function.


All is in the title, but I'll explicit a bit anyways (I'll have to be quite verbose about it too, as it isn't so easy to explain through text only):


Using Quick Restore State, it seems impossible to use more than a single SaveState file (as in: changing the currently selected StateFile in the GUI to another one, and expecting it to be the one used by the Quick Restore function. That function will revert back to the previous state selected)

It will even keep this behaviour after quitting and launching the emulator again, remembering what was the previous SaveState from former sessions.
At first I believed this was due to the order of the "StatefileMRUList" section in "winuae.ini". But, even though the order of that section isn't updated when selecting a new state file, from what I could gather through testing, the current selected SaveState in "Misc" tab is indeed updated (since winuae.ini itself is) when quitting WinUAE.
So why the next session could still use an older (seemingly erased when winuae.ini is updated) state order list for the Quick Restore, and still ignore the selected state, is completely puzzling to me...


Let me take a practical example: say I have 2 savestates, "State.uss" and "State_1.uss", and that when launching WinUAE, StatefileMRUList has them ordered as Image01=State_1.uss and Image02=State.uss.
I put the correct floppy in df0:, select (or actually load) State_1.uss as current SaveState in the Misc tab, then start the emulator. I will then get State_1.uss restored alright.

YET, for some reason unknown to me, as soon as I use my "quick restore state" assigned function key, the restored state will be State.uss even though it was placed only in 2nd place in the list at launch, and even though I just specifically selected State_1.uss as current State in the Misc. tab!


And sure enough, even though that selected state is still displayed as "State#1" in the GUI menu Misc tab, as soon as I quit the program StatefileMRUList in .ini file will be updated with "State.uss" in 1st position in the list!


I couldn't for the life of me find any other config file in my WinUAE directory and subs (and no WinUAE-related file or dir in my User dir, thank god!) from which the emulator would grab this erroneous setting that "State.uss" is the file to be used by Quick Restore state, completely ignoring the actual currently selected state in the GUI.
Would that come straight from the registry? (although I wasn't aware WinUAE did write anything in it — then again, I could never find where the preset list in the Filter section was stored either).




Hopefully I could explain the issue clearly enough...

I'm at the end of my rope with this anyway. If Toni or anyone else has the resource and knowledge to shed some light on this, I'd be real grateful.

[Toni Wilen]

StatefileMRUList does not affect statefile loading, saving or key shortcuts in any way. It is simply a list of last used statefiles that GUI statefile select menu shows.

[SunChild]

Thx Toni, that's indeed what I concluded through testing.

In any case (this might be useful for diagnose purposes?) I found a workaround to the above described incorrect behaviour of Quick Restore/Save shortcuts: unless I'm mistaken, it seems the file used by these keyboard shortcuts will always point to the LAST __SAVED__ state (as in VIA THE GUI, NOT saved via the Quick Save shortcut!), no matter what other state you may select (in the popup list) or load in the GUI afterwards.

So if you want to switch the savestate you're using to another at any point, you must first SAVE it again via the GUI. THEN and only then can you use it with Quick Save and Restore shortcuts... (ie. Merely loading another one will restore that one alright, but won't point the Quick shortcuts to it! They will still continue to Restore and Save to the last saved state file)

I believe what's missing here and would fix the shortcuts issue, is that LOADING any state file in the GUI (or merely SELECTING one in the GUI list, for that matter) should (these actions don't, at the moment) update the state file to which Quick Save/Restore key shortcuts point — currently only the SAVE option of the GUI does seem to update this.