Question about changing hotkeys for savestates

[synce]

Is it possible to reconfigure hotkeys by now? I often disable the framelimiter (F4) and sometimes hit F3 by mistake, losing all my unsaved progress. I'd like to make Shift+F1 the ss load keys

[Squall Leonhart]

use turbo instead of completely disabling the cap?

[synce]

The thing is my turbo is about 120%, a speed I like to play some games at... When I hit F4 it can go up to 500%, which is great for fast forwarding. So I take it I can't change the keys around?

[avih]

You can keep turbo at 120%, and set slowmo to 500%. Kinda backwards, but it'll work.

And no, for now, you can't reconfigure the hot keys without compiling pcsx2 yourself.

[miseru99]

Avih says "for now" and then like day later implements it - r4917.^_^ Thanks for that.

On a side note, I messed around to implement "save key per slot" myself, I thought it would be useless, through after thinking a bit, it's easier to find cheats for me with it. Usefullness of it still is small, guess it could rise, if I made it for completely new/additional 10 saves slots which doen't seem to be much of work to change into;P, through personally I preffer to abuse memcards instead of savestates. Anyway made a patch for adventurous* people:

  !save-key-per-slot.7z (Size: 1,13 KB / Downloads: 268)

Note: it also is usable for r4917 custom config with:

Code:

from:
numeric_loadBackup0=
numeric_load0=
numeric_save0=
till
numeric_loadBackup9=
numeric_load9=
numeric_save9=

but as r4917 states, "normal keys" doesn't work for now, soo it cannot be set for 1-0 keys. It's set for numlock 0-9 to save, with ctrl to load and with alt to loadbackup by default.
Edit: as of r4918 it's possible to use normal keys too^_^.

*adventurous - who can compile pcsx2 themselves;].

[nosisab Ken Keleh]

Something that could turn out useful is letting the actual savestate system untouched but implementing a cycling slot system which should be seen as temporary. That should grant a fairly secure protection against unpredictable sstate corruption providing at least one working near save point without the annoyance of selecting slots by hand for this purpose alone (the already implemented backup system helps but may be not enough).
Besides, it allow for the actual sstate system being freed to store important events which may not have memcard points around and/or as end game session save.

Sugestion: Make the name timestamped to easily locating the last save but keep an index to control the cycling.

[miseru99]

You mean automatically cycle to next save while pressing save and based on different slots than existing ones? Soo dividing a savestates for those keept for stability of current gameplay and those keept for choosen moments?

I finished Disgaea lately using new builds and dunno if I'm just lucky, or it's soo simple game that savestates are too small to generate corruption, but as saving pretty much every turn I had no corrupted save through whole play, soo maybe that last svn change to rename file instead of copying it helped with stability. Anyway it would probably be better to find why they corrupt in the first place and fixing that instead of adding another way to secure it. I wonder if there are particular games that tends to corrupt saves more than the others, maybe it's also dependant of the save size, or with pressed buttons. I remember finding cheats in one game in the past, but while it was a fighting game I often saved during actual moves, and I noticed saves were corrupting alot while I was saving with key or few pressed, while fairy never while I wasn't pressing any button. I think I had similar in my first game replayed on pcsx2 - FFX, whenever I saved while running/having keys pressed it felt like having increased chance to corrupt, through maybe it's just me and my observation is false, soo wonder if anyone else noticed similar dependency. I lately try to whenever possible save without pressing any other keys while using savestates and they don't really corrupt soo much for me even while I abuse them while seeking cheats.

Something like "last save" hotkey(ie. ctrl+f3 by default) could be usefull, as the main point for savestates is that we use them to not have a need to playing through to next savepoint when we feel like not playing anymore for the time. I simply save the game in 0 slot when leaving to not forget which was the last one, couse after some time I need to cycle them to find out which was last otherwise.:3

Adding a "save as"/"load from" to the gui could be nice step somewhere in the future too, guess it even was discussed already somewhere around, but it's just one of those fun killing things of consoles, that you can notice a big fight or dialogue incoming when you walk into another fairy empty area with savepoint visible from every side, soo it's not like there are lots of moments we can't save normally:X.

[avih]

Something that could turn out useful is letting the actual savestate system untouched but implementing a cycling slot system which should be seen as temporary.
...

You could easily create such a system by yourself: Use some macro application (Autoit, etc), and configure it such that when you press a specific key ("next-slot-save"), it generates: F2 [short-pause] F1, which will auto skip to the next slot before the save state. F3 will normally load from current slot, which is the last saved one.

...
Anyway it would probably be better to find why they corrupt in the first place and fixing that instead of adding another way to secure it.
...

Yup, blind workarounds are not usually a good solution or path. However, after some code review and actual tests that I did, I couldn't get it to corrupt, other than when doing a power-off soon after the save was created.

To fix an issue, and unless there's an obvious visible bug, it can really help to be able to reproduce it first.

It seems Squall Leonhart can somehow reproduce it, but I couldn't follow his exact footsteps, and he seemed reluctant to provide more details which would help me see what he sees... so.. it stands as it is for now, as I don't know where else to look.

As for the rename instead of copy, it only reduces the chance for corruption of the backup file, not the actual savestate.

[synce]

Appreciate the new compile, +rep

[linkRed]

I got a question in subject. Is it possible to implement the possibility to set a hotkey for swapping the pads?
I'm talking about this option.