A common module editing task is bulk renaming or deletion of images. To that end, editors frequently unzip modules to access their contents and then re-zip them when finished. It’s important to understand the organization of files inside a module in order to re-zip it correctly and avoid the dreaded error message that VASSAL cannot open your module because it is not a recognized file.
Pictured below is a folder with:
- An original, unmodified module file
- A copy of the module file with its extension modified to .zip
- A newly-created folder into which the contents of the ZIP archive have been extracted
This image comes from MacOS, which by default creates a new folder when you uncompress a ZIP archive and extracts the contents into that folder. The buildfile.xml is circled to note its required location–at the root of the ZIP archive. Imagine you’re all done with your image renaming/removal tasks and are ready to re-zip the files and test your modified module. The temptation is quite strong to compress the folder that was created with all your module’s files in it–but this is not correct. If you do what is pictured below, you will have erroneously introduced a new folder at the root level of the ZIP archive, resulting in the buildfile being in the wrong place. VASSAL will not detect it where it expects to, and give the error message about the file not being recognized if you try and open it.
Instead, you must multi-select all the files and folders that make up your module’s contents. At a minimum, this will be the buildfile and an images folder, but could include other files like predefined setups, documentation, etc.
Windows users have an easier method to do this task, which is to avoid relying on the built-in ZIP archive handling of the operating system and use a good quality archiving tool like 7-Zip. You can open a module directly with no need to ever do any file extension modification.
