Where to store program data if running from a CD?

[alpine9000]

An upcoming project stores it's program data in the folder where the program is executed (if possible).

But if the program is executed from a CDROM, then obviously this is not possible.

Where would the best place be to save this data ? Or should it not save any data if the program has not been installed to a HD ?

[AMIGASYSTEM]

If you have a floppy drive you could save the data on a floppy, or if you have a Hard Disk you could save the data directly on HD. Years ago there was also a device that allowed to write or delete data from a CD-Rom but this was only virtual, in fact the data was written on the Hard Disk.

[alpine9000]

I was more talking about what folder on the file system to use.

[meynaf]

You can try ENVARC: (create your dir here if you have several files to write).

Or put a config file there or in ENV: which will tell where the files go.

[alpine9000]

Originally Posted by meynaf

You can try ENVARC: (create your dir here if you have several files to write).

Or put a config file there or in ENV: which will tell where the files go.

ENVARC: works well as a fallback, but doesn't seem to exist in KS1.3?

I got a requester asking for ENVARC: when I tried to write to it.

[meynaf]

Originally Posted by alpine9000

ENVARC: works well as a fallback, but doesn't seem to exist in KS1.3?

I got a requester asking for ENVARC: when I tried to write to it.

1.3 probably does not have this.

But... Do people really mount a CD-ROM on 1.3 ?

[alpine9000]

Originally Posted by meynaf

1.3 probably does not have this.

But... Do people really mount a CD-ROM on 1.3 ?

Who knows what crazy stuff people do in emulation :-)

It’s not a big deal, just like to know which configurations won’t work.

[thomas]

ENVARC: is a bad idea.

Firstly it only works if it has been set up during the boot process.

Secondly it is copied to RAM during boot, so it eats up memory.

Thirdly it only works if you have a Save/Use/Cancel concept similar to that of the preferences. You read the settings from ENV: and write them to either ENV: or both ENV: and ENVARC: depending on whether the user clicked on Use or Save.

IMHO S: is a good place for text-based settings files.

SYS:Prefs/Presets is another good location, but you have to create these directories if they don't exist.

Actually you should ask the user and store the result in an ENV/ENVARC variable. If ENV or ENVARC don't exist, use S: as default.

[alpine9000]

Originally Posted by thomas

ENVARC: is a bad idea.

Firstly it only works if it has been set up during the boot process.

Secondly it is copied to RAM during boot, so it eats up memory.

Thirdly it only works if you have a Save/Use/Cancel concept similar to that of the preferences. You read the settings from ENV: and write them to either ENV: or both ENV: and ENVARC: depending on whether the user clicked on Use or Save.

IMHO S: is a good place for text-based settings files.

SYS:Prefs/Presets is another good location, but you have to create these directories if they don't exist.

Actually you should ask the user and store the result in an ENV/ENVARC variable. If ENV or ENVARC don't exist, use S: as default.

It’s not text based data, it’s binary.

You make a good point re wasting ram.

[meynaf]

Originally Posted by thomas

ENVARC: is a bad idea.

All places are a bad idea, but one has to be found.

Originally Posted by thomas

Firstly it only works if it has been set up during the boot process.

If you have a CDROM installed then you probably have booted something that has setup ENVARC:...

Originally Posted by thomas

Secondly it is copied to RAM during boot, so it eats up memory.

Fully or just ENVARC:sys ?
Does the copy process also duplicates all subdirs in here ?

Originally Posted by thomas

Thirdly it only works if you have a Save/Use/Cancel concept similar to that of the preferences. You read the settings from ENV: and write them to either ENV: or both ENV: and ENVARC: depending on whether the user clicked on Use or Save.

Why wouldn't it work ? ENVARC: is an assign like all others.

Originally Posted by thomas

IMHO S: is a good place for text-based settings files.

This, too, is a bad idea. S: is for storing scripts, not settings. It has been abused too many times already.

Originally Posted by thomas

SYS:Prefs/Presets is another good location, but you have to create these directories if they don't exist.

Even worse, Presets are for default settings of system prefs, not for user data.

Originally Posted by thomas

Actually you should ask the user and store the result in an ENV/ENVARC variable. If ENV or ENVARC don't exist, use S: as default.

Opening a requester to ask the user is indeed the only "clean" solution.

Originally Posted by alpine9000

It’s not text based data, it’s binary.

Saved game ?

Perhaps you could remove the ability to run from CD directly and make a limited install only containing the main exe. This way you always have a dir you can count on.

[alpine9000]

Originally Posted by meynaf

Saved game ?

Perhaps you could remove the ability to run from CD directly and make a limited install only containing the main exe. This way you always have a dir you can count on.

Yes, game progress and hiscore data. It's only 180 bytes, but that would be 180 bytes of ram the user will possibly never get back if I used ENVARC, even after the game is long forgotten.

This problem might be a bit theoretical. The most common case of an Amiga with a CDROM (CD32) is handled using nonvolatile.library and saving to NVRAM. I wonder how many CD equipped Amigas are actually out there being used for newly released games. I am guessing not many.

[volvo_0ne]

Nonvolatile: ?

[idrougge]

Originally Posted by thomas

IMHO S: is a good place for text-based settings files.

IMHO it is not. S: is for scripts. It's even part of the path.

[jPV]

How about a SYS:Prefs/YourGame/ directory? It seems some programs/system components use that kind of solution nowadays...

Or SYS:Storage/YourGame/ even though Storage has traditionally been for disabled Devs: stuff, but anyway I've seen that kind of solution already too.

Maybe I'd prefer the Prefs one, because your data is kind of prefs stuff for a game

[Cobe]

Originally Posted by alpine9000

Yes, game progress and hiscore data. It's only 180 bytes, but that would be 180 bytes of ram the user will possibly never get back if I used ENVARC, even after the game is long forgotten.

This problem might be a bit theoretical. The most common case of an Amiga with a CDROM (CD32) is handled using nonvolatile.library and saving to NVRAM. I wonder how many CD equipped Amigas are actually out there being used for newly released games. I am guessing not many.

If you're gonna save to cd32's nvram already, you could just instruct hd users to install nonvolatile.lib and set the folder wherever they want, or you could make a script for them to set that up. It could be good practice for all the future releases too.