PUAE ignores saves location set in the cfg

Libretro Cores
#1

I try to keep my saves folder clean and organized. So i have set save location for all cores. Most of them obey the set location, some however, like PUAE, ignore it.

I have set this in the cfg: "savefile_directory = “G:\RetroArch\saves\Commodore Amiga - CD32”

But it puts the save files in “G:\RetroArch\saves” regardless. It doesn’t even make a subfolder to keep it’s own saves. It just fills the main folder with saves from each game. This is a recent behavior, it used to work before.

How can i fix this?

#2

Works just fine here. Core uses the frontend dir it receives, and can’t do anything about it. Nothing has been changed in a long time, and the core can’t and won’t override it anyway.

Also you need to be way more specific with “recent” and “before”, and log tends to reveal things.

#3

I set my path like this in the PUAE.cfg. "savefile_directory = “G:\RetroArch\saves\Commodore Amiga - CD32”

I had this cfg since PUAE was released. And it worked fine, all saves were inside that folder. I don’t know when it broke but now it stores the save files in the “G:\RetroArch\saves” root folder, ignoring the “Amiga - CD32” entirely. I didn’t update RetroArch itself (i’m still in 1.15.0). I only update the cores once a month and at some point i got this behavior, sorry i don’t know when because i only now noticed the clutter in the saves folder.

Dunno why it doesn’t work for me anymore.

#4

I can only make that happen by setting the value as a path that does not exist. Log will then say:

[WARN] [Config]: 'savefile_directory' is not a directory, ignoring..

So which one is it, Commodore Amiga - CD32 or Amiga - CD32?

#5

It’s “Commodore Amiga - CD32`”, i meant to say it’s ignoring that folder.

I double checked the filename and it’s correct in the cfg, no spelling errors. I also know it’s correct because if i enable the “Sort saves into folder by core name” in the Saving options, the core creates a “PUAE” subfolder inside “Commodore Amiga - CD32”, which means it can see it. But it still won’t save any files in it, it still saves them in the root saves folder.

I thought maybe it’s because there are spaces in the filename, so i changed the folder name to simply “Amiga” and also changed it in the cfg. Still doesn’t work.

#6

I also get no error regarding this in my log. In fact i get this:

[INFO] [Overrides]: Redirecting save file to “G:\RetroArch\saves\Commodore Amiga - CD32\Banshee (Europe).srm”.

Notice the .srm at the end. And then, i also get this:

[libretro INFO] NVRAM: ‘G:\RetroArch\saves\Banshee (Europe).nvr’

That’s .nvr. So it’s the nvram, not a save file? But isn’t that supposed to work as a save file? Does PUAE even generate a .srm file at all? I don’t see it anywhere despite what the log says.

Edit: At https://docs.libretro.com/library/puae/ it says this:

Frontend’s Save directory

  • ‘content-name’.nvr (CD32/CDTV NVRAM)
  • BootHD / puae_libretro.hdf (Optional global boot hard drive image directory/file)
  • WHDLoad / WHDLoad.hdf (WHDLoad helper image directory/file)
  • WHDSaves / WHDSaves.hdf (WHDLoad save image directory/file)

So all these files and subfolders, including the NVRAM, are meant to be saved in the same folder. And in my case they all end up in the default “saves” root directory, regardless how i set it.

#7

Ok, I was able to reproduce it by moving the same config line to the override cfg instead of appendconfig cfg. The core never gets the value set in there, even though overrides and appendconfigs use the same parsing pipe, so this is a frontend problem…

And no, the core does not use srm saves nor the save API at all. That is just the generic frontend notification.

1 Like
#8

Is there anything i can do? How do you use the appendconfig, i never figured that out or i never needed them. I always just used the cfgs and overrides.

#9

I guess all you can do is wait until I fix it. Appendconfig is for CLI usage only.

#10

Thanks. Will this count as a RA or core update?

#11

RA, since the core never gets the proper path when setting the environment, like I said. This core can’t be the only one suffering from this, so doing band-aids for every core is no good.

Looks like I got it sorted now with a simple and harmless appearing change.

#12

In my case that’s the only core that gives me this trouble. The other cores save in the folders i set in the cfg. I don’t use all RA cores that exist though so maybe there are more that i don’t know of.

#13

Then it must mean that the other cores do not get those paths in retro_set_environment() - which seems like the most logical place because the paths are environment variables - but instead later in retro_load_game().

The documents do not explicitly state one way or the other, but it makes more sense to me that they are available already at that moment, since those values are not supposed to change according to core options.

#14

The change is merged, so please try the next nightly.

1 Like
#15

Thanks for the fix. It works.