Only way I can do it is by converting to a zip exporting it, then removing the old files from the root directory and then copying it back to a zip and renaming to a vmod file.
I think these old pre-sets are causing a bug when you run the refresh predefined setups some of them do not get refreshed and I think it is because there are duplicates in the vmod and that is causing them to be refreshed instead of the active ones. It is either that or only the first preset gets refreshed and others are not.
As a starting point, if you are a Windows user, there is no need to resort to all this gimmickry of changing file extensions to access the ZIP archive contents and then renaming again when finished. Use 7-zip! Open your modules with it and add/remove contents to your heart’s content, without any need to rename your module file.
Accessing the ZIP archive contents and removing stale .vsav files representing older predefined setups is a foolproof way to get rid of them.
If you are going to rely on entirely in-Editor tools and features, you can overwrite existing predefined setups if the filename of one you load in precisely matches the filename of an existing one inside the module–and I do mean precisely: letter for letter, case sensitivity matters, etc. Just as with image files, when you load in a file as a predefined setup and the filename is an exact for a file already inside, the existing one will be overwritten.
If you load in a predefined setup that’s meant to improve or iterate on an existing setup but with a brand new filename, it will be loaded in and all others will be left untouched–i.e., you will have more setup files inside the module than you started with. The system is not going to save you from yourself. I see a lot of modules like this that have many outdated predefined setups left inside them. I don’t think this is a good habit to get into.
Well there were to many times in the past that the same image that was changed but had the same name did not update in the model when assigned so I am biased about using the same name. I’m old school IT I’m ok jumping hoops for a known working process.
I was hoping that at some point the great fantastic Vassal tool would add a removal tool for removing unused vsavs to keep modules from growing sizes. I appreciate all the hard work that everyone puts into this!
This is nonsense. If you want to use overly-elaborate procedures because you don’t know better, fair enough–but for lurkers and readers out there, there’s no mystery about what VASSAL does with files you load in. It’s known and predictable.
You can of course also do this on any modern platform - not just Windows. On Linux, the utility FileRoller lets you edit Zip files live. That is, you simply make your changes directly in the Zip file, and the archive is automatically updated. I believe Emacs allows that too (“Emacs is the only modern operating system that isn’t multi-threaded”). The Debian and RedHat packages sets up the file types of Vassal, so that one has the option to open them as if they were Zip archives.
OK, on Mac you probably need to get a third-party application if you want to have graphical user interface. But at least Mac has a reasonable command line.
You can also use the command line utility zip available on all platforms. To update a file - say foo in the Zip archive Foo.zip, simply do
$ zip -u Foo.zip foo
And of course, as a proper tool, zip doesn’t really care about the file name of the archive, so you can do this on a Vassal module too
$ zip -u -d MyFantasticModule.vmod images/my_fantastic_image.png
In fact, there’s noting magical ( pun intended) about the ending of a file name. Microsoft has somehow convinced many that there is. The ending (or “extension”) is simply an arbitrary collection of characters that let people identify files, but the operating system couldn’t give a rats arse about the file ending. A Zip archive can be named something like foo.bar.baz.gnus.gnat and still be a valid Zip archive. A PNG image could likewise be named Archive.zip but it would not make it into a Zip archive. Hackers used to exploit this by naming a piece of code some inconspicuous - say .jpg - and when the victim double-clicked the file it would execute malicious code, because Windows would simply run start on the file.
Proper operating systems uses something called file magic to discover what kind of file it is dealing with. This typically involves looking at the first few bytes of a file and comparing that against some standardised database. For example, the four first bytes of a PNG file are 0x89, 'P', 'N', 'G', while the two first bytes of a Zip archive are 'P', 'K'. This file magic then maps to mime-types, and applications can declare that they can handle a given mime type.
File magic cannot be changed by users, but file names can - which is why it is a really bad idea to rely on file name “extensions” - but the good people over in Redmond are not know for they thoughtfulness.
A Zip archive may not contain files with the same full name. E.g., a Zip archive may not contain two files named images/unit.png, but it can contain the files foo and misc/foo.
BTW, Zip archives doesn’t really contain directories or folders. A Zip archive contains a number of binary blobs of files which are labelled with a string of characters. If that string contains a slash / (not a “forward-slash” - it’s just a slash) then tools often present that to users as if the file is in a sub-directory, but that’s a convention - not a standard or necessity.
Again, the zip utility comes to the rescue. If you want to remove the file old_crappy_scenario.vsav from the module ReallyBloatedModule.vmod, you can do
$ zip -d ReallyBloatedModule.vmod old_crappy_scenario.vsav