Savestates not working

[AmigaCD32]

When I try to use the save state function its greyed out.

Anyway I can get this to work?

Thanks

[Jason H]

Originally Posted by AmigaCD32

When I try to use the save state function its greyed out.

Anyway I can get this to work?

Thanks

Are you loading a WHDLoad game? Save States don't work with WHDLoad games as they are actually Hard Drive images. Only ADF/IPF floppy images use this function.

[AMIGASYSTEM]

@Jason H
No, Save States also works with WHDLoad games!


@AmigaCD32
Save State is activated after you start something

[Jason H]

Originally Posted by AMIGASYSTEM

@Jason H
No, Save States also works with WHDLoad games!

@AmigaCD32
Save State is activated after you start something

Save States are NOT set up for WHDLoad images by default (I just checked my own set-up to confirm).

You can however force this fuction by adding the following lines to the configuration file;

unsafe_save_states = 1
relative_temp_feature = 1

[Fenris]

I'm trying the settings that Jason_H has suggested, but after a while I still get the "VBR detected" error...
Is there any workaround to this?
Basically save states work up to a certain point, then it stops working at all and gt the error above, same result with two different games.

[Jason H]

unsafe_save_states - so I guess it's not something that is supported and has known issues?

Maybe you can use the ipf/adf files?

[FrodeSolheim]

There is a reason the option is called unsafe_save_states.

The save states are not safe to use in all circumstances. One particular reason is that the disk (hard or floppy) contents are not stored within the savestate. So, if data is stored back to the disk, the disk storage might get out of sync with the savestate, causing inconsistencies and data corruption. This could also happen for floppy-based games btw.

If the game saves data that it later depends on being able to load back again, the game can suffer from issues when using savestates if you "jump back and forth in time" to before and after saving such data. If the game only saves data such as highscore data, it probably won't cause dangerous inconsistencies. So exactly how unsafe it is depends on how the game uses disk storage, and also on how savestates are used.

The only reliable solution to this is to make sure that the save states also contain complete information about data that has been changed on disk (floppy or hard). Maybe in the future (The most simple - but inefficient - implementation of this could simply make a full copy of the disks and store alongside the savestate)

[Fenris]

I understand, however that's a pity.
A working "save-state" feature would be a huge QoL improvement imho, and would probably provide a more "modern" way to experience many of those Amiga games that do not have an in-game save feature, or where such feature is lacking...

Would be a great plus in the future.

[AMIGASYSTEM]

Originally Posted by Jason H

Save States are NOT set up for WHDLoad images by default (I just checked my own set-up to confirm).

You can however force this fuction by adding the following lines to the configuration file;

unsafe_save_states = 1
relative_temp_feature = 1

No, with WinUAE it works perfectly Save State with games WHLoad without the need of any parameter!

[FrodeSolheim]

I don't think there should be any difference in compatibility compared with WinUAE (but I'm of course interested in proofs or strong indications of otherwise).

Note, the option unsafe_save_states does not do anything other than unlocking the GUI for allowing saving/loading state for HD-based configs.

The option relative_temp_feature is required if you use the Launcher's ability to (for example) automatically assemble a WHDLoad hard drive based on config from the online game database and indexed .lha archives. In this case, the automatically generated hard drive gets a new temp path each time you run the game, and relative_temp_feature just instructs the launcher to do this in a way that FS-UAE sees the same paths every time. Otherwise, savestates would definitively not work in these cases.

(It you use static directory hard drives like you would in WinUAE, relative_temp_feature option is not needed)