SUGGESTION: File Managing

[Chrille]

I miss the ability to manage files from within AGS, such as creating & deleting folders and renaming, copying & deleting files. Would it be hard to write a module or to implement this directly into AGS?

[Calin Leafshade]

file manipulation is deliberately limited in AGS for security reasons but its possible that more things could be added that werent security risks.

A plugin could add the extra features tho.

[Chrille]

Ah, hadn't considered the security risks. Perhaps it could be limited to dealing with files in the .exe directory or its sub-folders?

[Calin Leafshade]

being able to create folders within the exe directory is still problematic because later versions of windows dont allow programs to alter Program Files (which some games are installed to).

It would be possible to create folders in the save game folder though which is guaranteed to be safe and writeable

[Chrille]

Ah, right. Yeah that'd be best I guess.

[monkey0506]

AGS has the ability to create folders in the save game directory.

And the save game directory may not be "guaranteed safe" with older versions of AGS (we don't have the source, obviously, so we can't tell), but the latest version of the engine certainly does verify that write access is available before changing the save directory.

So you could do:

Code: ags

Game.SetSaveGameDirectory("ANY_VALID_PATH"); // includes $MYDOCS$ and relative (to the Compiled folder) paths

From there you could change the save directory back as needed. This should also support the $APPDATADIR$, unless I'm just misreading the source of the Game.SetSaveGameDirectory function.

You can't create absolute paths, but anything relative to the Compiled folder, My Documents (or equivalent), or Application Data directory (varies by OS, guaranteed writable) should work fine.

A File.Copy function could be emulated, although slow for large files:

Code: ags

void noloopcheck FileCopy(String fileToCopy, String copyTo)
{
  if ((String.IsNullOrEmpty(fileToCopy)) || (String.IsNullOrEmpty(copyTo))) AbortGame("FileCopy error: Filename cannot be null! Game cannot continue.");
  File *in = File.Open(fileToCopy, eFileRead);
  File *out = File.Open(copyTo, eFileWrite);
  if ((in == null) || (in.Error)) AbortGame("FileCopy error: Error opening file '%s'. Game cannot continue.", fileToCopy);
  if ((out == null) || (out.Error)) AbortGame("FileCopy error: Error opening file '%s'. Game cannot continue.", copyTo);
  char c;
  while (!in.EOF)
  {
    c = in.ReadRawChar();
    out.WriteRawChar(c);
  }
  in.Close();
  out.Close();
}

File.Delete already exists. As for File.Rename, you could copy the file to the new location, and delete the original. But that's very slow for a rename operation.

[Chrille]

I can't believe I missed that File.Delete function and the fact that you can create folders using the SetSaveGameDirectory function means that I already have what I need. Thanks a bunch!

EDIT: Actually, it seems you can't save all files in the created save game dir, like for example Sprite.SaveToFile ("$MYDOCS$/MyGame/sprite.bmp");. Meaning I'd have to save the in the gamedir subdirectory, which would cause problems in recent versions of Windows. Boo :/

[monkey0506]

I wasn't sure that I believed, you, but I was looking over the source just now and I don't see that the $MYDOCS$, $SAVEGAMEDIR$ or $APPDATADIR$ tags are being utilized by DynamicSprite.SaveToFile. I was of the impression that it automatically saved to the save folder. Looking at the source though, it actually looks as though DynamicSprite.SaveToFile allows you to specify absolute paths. That's...strange, given the other file functions...but without having actually tested it, something like:

Code: ags

sprite.SaveToFile("D:\AGS\screenshot.bmp");

Should actually work. Unless you're running under the debugger and then it would probably fail.

[RickJ]

Code: ags

Game.SetSaveGameDirectory("ANY_VALID_PATH"); // includes $MYDOCS$ and relative (to the Compiled folder) paths[/quote]
In light of the above and the ability to make custom plugins and the ability to modify the runtime, the argument to "restrict file operations for security reasons" no longer seems to makes sense.  Why no just do away with it?