Proposal: games do not write files to the installation folder anymore.

[Crimson Wizard]

Problem

Since Windows Vista a program requires administrative rights to write into "C:/Program Files" folder. This means that if an AGS game was installed there, it won't be able to create or change any files in its directory. This refers to:
* configuration file,
* saved games,
* custom files written by game script.

In the previous versions of AGS this issue was partially fixed by letting games to save into special folders ("Saved Games" and "AppData" folders). If a correct subfolder name is provided by game developer, then saved games are written in "Saved Games / GameFolder" automatically.

However, three problematic cases remain.

1) Configuration file is still located in the game directory. If inside "Program Files", WinSetup utility cannot write to that file without admin rights.
Also, if we make game itself modify configuration file at any point (for example, if you can change these options from script), the game won't be able to do so without admin rights too.

2) Script may create custom files in game directory.

3) It is still allowed to create saved games in game directory (if you do not provide save folder name).


Expectations

The game should write files without issues regardless of where it is installed, in accordance to contemporary conventions.

I would like to find and implement a solution for upcoming 3.3.5 release.


Preliminary proposition

1. Game / WinSetup writes all files in special folders ("Saved Games" or "AppData", etc).

2. When game reads a save file or custom data file, it first check corresponding "special" folder; only if file is missing it may also check paths related to game installation dir. This will make it compatible with games that do not have a "proper" installer (distributed in archive), and also backwards compatible.

3. When game reads configuration, it first reads the config file found in installation directory, then reads the one in "special folder". This way the newer file in "special" location overrides the "default" config file in the installation dir (if there is any).

4. The file paths supplied by script are remapped when required. For instance, if script does not tell to write file either in "Saved Games" or "AppData", then the path is still converted to "AppData".
In order to avoid file name conflicts, some prefix / subfolder may be added in that case too.

5. The "Save folder" string option in General Settings may actually become obsolete; the subfolder name for game files inside "special" folders may be equal to game's title. Or we may leave it, and use game title as default, if game developer did not provide subfolder name.



Complications

This proposal, if implemented, may lead to number of complications, or rather inconveniences.

1. Similar to saved games, if game saves some data depicting user progress in a custom file, it should be searched in a special folder when user wants to move saves to another computer.
2. When editing config file by hand, user should find it in a special folder as well. Ofcourse, this refers primarily to options that may be changed by game itself (in the future), due the overriding rule mentioned above.

Possible solution: when compiling/packaging game add shorcut files leading to corresponding special folders (saved games and app data).

3. The file location conventions may differ on different platforms (although ports are already more strict with savedgames than Windows version).

[Monsieur OUXX]

I'm all in favor of moving everything out of Program Files.

Regarding the "complications": They're the same for every game nowadays. And indeed, I think adding a shortcut to the folder would be a great idea (let's start for Windows, usually Linux people know where to find their stuff).

I have one demand though: make sure that folders manipulation in the script leaves no room for headaches and humans mistakes. For example: When you're never sure of the name of that special folder (was it C:\AppData? C:\Users? whatever). Another example: Beginners mistakes, like trying to hard-code the whole path in their script (like "C:\Users...") and then the game is on a foreign system and the path is actually "C:\Utilisateurs...", you know, that kind of mistakes.

[Sslaxx]

I have one demand though: make sure that folders manipulation in the script leaves no room for headaches and humans mistakes. For example: When you're never sure of the name of that special folder (was it C:\AppData? C:\Users? whatever). Another example: Beginners mistakes, like trying to hard-code the whole path in their script (like "C:\Users...") and then the game is on a foreign system and the path is actually "C:\Utilisateurs...", you know, that kind of mistakes.

That should be up to the engine; scripting should have no ability to set locations to save files.

[Monsieur OUXX]

That should be up to the engine; scripting should have no ability to set locations to save files.

Well I'd rather be safe than sorry

[Cassiebsg]

Can I put up a pledge to let me choose where I want my save files? I hate windows stupid default/dictator folder structure. Can never find them!
I just want my files along with the game files... eventually something like ... \GameFolderName\SaveGames\ ... pretty please?
Maybe a setting/path that can be set up in winsetup?

[Crimson Wizard]

Can I put up a pledge to let me choose where I want my save files? I hate windows stupid default/dictator folder structure. Can never find them!
I just want my files along with the game files... eventually something like ... \GameFolderName\SaveGames\ ... pretty please?
Maybe a setting/path that can be set up in winsetup?

I was considering this option as well.
But what if there was is a link-file (shorcut) to the savegame folder?

[Cassiebsg]

That might work for finding them easy if they "far away in another galaxy", but still rather have the option to choose where to put them.
Though, when I delete a game I expect it to be gone, not living "offsprings" all over my C drive... Or if I want to save/backup some save games, not having to go all looking for them.
Guess I'm just used to organize stuff the DOS way, not M$ way...

[selmiak]

maybe add yet another option to the winsetup.exe? Save savegames to windefault or 'install'-directory. And let the programmer chose one default value for the winsetup. Or make a poll and chose one. I like to save to the folder where the game is. I'm sorting stuff like cassie does, when I want to delete a game I want to delete everything. And this is easier when all files are in one place. Actually I always wondered why AGS does it this way and not the save to installdirectory way.

[Crimson Wizard]

Actually I always wondered why AGS does it this way and not the save to installdirectory way.

Thats how all modern applications do. And not only on Windows.
I do not know why some people think its "M$ way". Linux does that too, it has executable and user files separated from the very beginning. To name another disadvantage of not doing so: not being able to completely divide the program usage between several people on a shared PC.
In fact, keeping all files in the installation folder - it is (was) "M$ way". Now Windows comes to convention that other OSes use.

[qptain Nemo]

I think the default should be $XDG_DATA_HOME and %AppData% with user (but not the game scripter) being able to override it with an arbitrary directory in the setup program if they desire.

Having said that, what I'm currently doing in my engine is, I'm having it discern between two installation styles: a "proper install" and an "archive dump". If no system-wide modifications have been made and all files are in one directory as would happen if you just extract stuff from an archive then it puts all the state files there as well, but if there are signs of a completed installation process (basically it'll mostly be just some special file or two in $XDG_DATA_HOME / %AppData%), then saves go to those proper system-specific directories for user data. I'll most likely add the option for the user to specify custom save path as well at some point.

[Crimson Wizard]

I think I made a mistake with the way I implemented the backward compatible workaround in the 3.3.5 release.
Currently I am planning a patch to this version and I want to try to correct this situation also.


My original idea was this:
1. Writing file in the install directory for the newly created game is forbidden, and simply returns error. The new games will have a certain internal "flag" set to distinguish them from "old" ones.
2. For backwards compatibility, when old game wants to write file in the install dir, no error is raised, but the filepath is silently remapped to %APPDATADIR%.
3. Because of the p.2, when old game opens file for reading in the install dir, it first checks %APPDATADIR%, because it may contain the file previously written with remapped command.


When the 3.3.5 beta was released, this change caused some confusion, and I decided to let new games have this silent filepath remap as well (with only warning printed to the log if the game is built in Debug mode). The reasoning behind this was that minor release should be fully backwards-compatible and not force users to fix their scripts.


However, I somehow forgot the possibility that the game may have a "read-only" file in the installation directory and writeable file (in APPDATADIR) having same name.
The p.3 in the list above makes it impossible to force the game to read the file in the installation dir, after the game saved "rewritable" file with same name to APPDATADIR (assuming these are supposed to be different files).


Now, I need to somehow find a solution that would deal with such cases for both old and new games, and won't cause unexpected behavior if the user upgraded his or her project from, say, 3.3.0 to 3.3.5.

[Crimson Wizard]

I am thinking about adding new tag, something like $INSTALLDIR$ that would explicitly tell AGS to open file in and only in installation directory. The writing operation will, of course, fail.

This tag is something that old games did not have, so it won't break backwards-compatibility; and also will align with the possible future introduction of "file repository" objects, that could be used instead of path tags.