For one of my worlds, I was lazy and simply used exampscript.jvs as my world file, instead of making a new file. When upgrading to the latest MUSHclient however, the script was overwritten with the "new" exampscript.jvs, killing all the work I had done in the script. Unfortunately, I didn't have a backup.
Could you perhaps add checksums to the exampscript.*'s on future versions, and when updating, if it doesn't match the previous versions' checksums, you know it has been edited and it should prompt a replace confirmation?
Simplest way to do this would be to make the installer let you customize what it lets you install... Oh wait... IT DOES!!!
While I sympathize with your loss I feel the need to point out that using Typical or Custom with 'all' items selected to install the client automatically 'assumes' you have a clue and that you want to replace those files. The option is available to choose custom install and deselect the example files.
There may be ways to have the installer check anyway, but they rely on 'system awareness', which means the system registry would need to know about the files and have a way to show they changed, or extra and maybe even outdated and redundant info stored in the installer. In the case of the registry... Gammon is trying to get rid of the need for that, since it limits where and how you can use the client. It isn't practical for the installer to check and/or second guess the person installing it. The typical install could be set to 'not' install the examples, but that is not generally the expected or wanted result. In most cases such things are excluded in typical installs only if they take up very large amounts of disk space.
You goofed. It is as simple as that. Which reminds me... Better make a backup of the new changes in mine soon. :p
Well it wouldn't be hard to recognise whether or not an exampscript is one that was distributed with a previous version of MUSHclient or not. If it's been changed, pop up a message letting the user know that it's going to overwrite a non-standard MUSHclient file.
As far as "goofing" goes, I didn't really think about it at the time, I figured some sort of implementation of this would have been in place.
People are going to use exampscript's, because it's the default script file, so having a mechanism that establishes whether a previous exampscript has been modified or not isn't at all unreasonable, and people shouldn't have to resort to doing "Custom" installs to bypass it.
Well the problem come down to 'how' do you tell if it isn't. The methods are:
1. Have the system keep track of it (requires the installer to reboot and uses system registry, so bad idea).
2. Have the installer actually know the contents of the file. This is really not something you wan it to do, since it is bad form.
3. Use a calculated check-sum. Unrealiable in that it is 'possible' for it to still produce a checksum that is the same as previous versions of the files and the odds increase a lot as more and more 'different' sample files need to be kept track of.
4. Date and time of creation. Bad idea, since the last time you updated the file could easilly be the same day and even by pure chance time that some new version is made. Then this istall may not eat it, but the next one may.
The 'only' method that works well is to imbed a version number in files that may be replaced and have the installer check the version number against the new install. This 'only' works for binaries, since not deleting the version info from the file is basically the same as not changing the name, it will still see it as the same file.
I suppose 5. Check file size woud also work, but then you could delete a chunk of the example code and then accidentally add back in the exact same number of characters you removed.
There is really no practical means to verify the state of a text document with any real precision, let alone automatically detect if they are changed. The best bet would be for Gammon to make new installs have 'install examples' off by default, but for files that are as small as they are, there is not a lot of point in most peoples cases for doing that.
Why wouldn't checksums work? MD5, for example, uses a 128bit hash, or 340,282,366,920,938,463,463,374,607,431,768,211,456 (three hundred and forty undecillion) possible combinations. It's relatively safe to assume collisions won't happen too often. :P