Quote Originally Posted by DarkDragon View Post
I don't see anything wrong with this (other than that you should use a std::string or other dynamic buffer, *not* a hard-coded buffer that will crash ZC when someone happens to place it nested deep in the file system), but what's the need for changing the save name?

True, on the srd::string point, for dynamic allocation. I was not going to allow it to be in another path though. Just a filename in the same path as ZC, so nesting it/buying it is not something that should be a problem, as it would always need to be relative to the ZC binary.

As to why: Users frequently request that ZLaunch or whatever can use multiple save files. The way that the other launcher that Matthew made worked, was that it renamed save files and moved them around on the filesystem, which I think is a horrible idea. Apart from allowing a programme to muck about with filesystem data, this would need multiple implementations for each OS. I would much rather allow a user to choose a save file in the launcher, than to give the launcher the ability to manipulate files (other than its config file), if for no better reason than that copying the file and moving it around, could lead to damage, which would not occur by choosing a named save file (as this is read-only, not r/w/e).

Further, moving files around, might not work on some OSes these days, based on user permissions. This again, makes multiple files, and selecting their names, a better choice.

Last, for standalone projects, being able to name the save file to 'gamename.sav' would probably be useful, although this is a minority case of impact. For example, if someone wanted to make a custom adventure game, and hide the engine, then they ,ight want to rename the savename. I was planning to do something similar for the assets, which will come into play for module systems, later; so that stuff such as zelda.dat is specified from the config file, rather than hardcoded; making it easier to change out the datafiles for us, too.