File size too big, but not as a zip file

Hi, the size of my module has suddenly balooned to 360 Mb and I can’t upload the latest version. I tried changing it to a zip file, extracting the contents, and deleting some unused picture files (most were very small in size). After recompression and renaming back to a vmod file It’s now only 8 Mb but I can’t open it in vassal. How can I reduce the file size? Do I have to start a new module and copy and paste the contents from the old module?

Look in the Editor under Tools > Remove Unused Images. Save a backup copy of your module first.

1 Like

Thanks, that’s a terrific tool, there were a lot of useless files, but it’s still 349 MB, any other suggestions? Strange that there could be such a difference between a zip file and the vmod file.


A VMOD file is a ZIP archive. ZIP archives can be just that -a collection of files with no compression - the files in the archive are stored as is, back to back. Optionally the archive can be compressed. I guess that when you manually archive your content, you use compression, while VASSAL does not - hence the different file sizes. I believe VASSAL does not handle compressed ZIP archives, or at least only in a limited way (there are some ZIP implementations that use proprietary compression algorithms). This could be the reason why VASSAL does not load your manually saved module.

You could use my Python module from

to open your module and clean it up.

300+ MB sounds awfully big. I guess your graphics are at a very high resolution. Perhaps you could reduce that? One way to reduce the file size would be to use vector graphics (SVG) but it seems like Java’s handling of that is very slow.



We need to see the module to advise further. Where can we get it?

It does. ZIP archives written by Vassal are compressed.

“Suddenly ballooned” seems to imply you knew it to be much smaller previously–what is the file size you were accustomed to or expecting? What operating system are you using? Typically when users get into a mess uncompressing a module, doing stuff, and then recompressing and being left with something that VASSAL won’t open, that’s an indicator you’ve recompressed the wrong things. For Mac users, this is the frequent misunderstanding that they need to recompress the whole folder created when the ZIP was extracted, rather than its contents.

Ok, I wasnt sure, which is also why I said that some ZIP implementations uses proprietary algorithms, which could explain why op had trouble opening the handcrafted ZIP.

the vast majority of the files are the counters, which are only 4 or 6 Kb each. I don’t think reducing the 75 dpi resolution will do a lot of good. Thanks, I’ll try that python module.

You likely have something strange going on, but we can’t diagnose it from a description. We need to see the module if we’re going to provide further advice.

BTW, dpi is totally irrelevant. Nothing in Vassal uses dpi.

Recompressing the archive is unlikely to help. Image files, which are the bulk of most well-formed modules, are already compressed.

The previous version was about 200 Mb. I’m using Windows 10’s built-in compression and I did recompress the whole folder, I’ll try compressing the contents.

OK i;ll have the latest version on my google drive in a few hours - my connection isn’t particularly fast.

Here’s the link to the module: Belter base module.vmod - Google Drive

Your module is only 32MB. The remaining 300+Mb is made up by a folder named Help that contains a folder named ‘Rules’ that was loaded as an HTML file. Just open the module with 7zip or Windows and delete the Help folder.



This is why I always ask to see the module when people are having problems—things which are hard to troubleshoot from a description are often trivial to spot with the module in hand.


If you want to include the rules in the module, then perhaps consider to make it into a PDF. Also, you should not compress the individual files - files will be compressed by the top archive.

The culprit seems to be the file help/Rules:Belter module.vmod which is just shy of 210MB. It does not really make sense to put a module inside another module, especially not in the manual. The next largest file is help/Rules:Belter base module.vmod which is almost 43MB, followed by a sound file at almost 25MB. You also have a lot of graphics files that take up quite a lot of space. Presumably, these are already in the module as boards, counters, tables, and what not.

It seems like your `help/Rules’ folder is mainly a dumping ground for all sorts of stuff *you even have copy of the VASSAL designers guide in there). Perhaps it would be better if you kept that out of the module proper. If you want to make it available for others, set up a web-site or something (for example at GitHub/Lab/…) where you store those things.


Thanks again, guys, that looks hopeful. Yeah, I tried deleting the files before, but the module wouldn’t open after that. I couldn’t delete anything while the folder was compressed, After decompression, deleting, and recompressing, the module wouldn’t open. So the key is not to compress the whole folder? There are hundreds of files to compress individually. I’ll read those helpful suggestions again but I’m not sure how to proceed with recompression. Is it because I’m using Windows 10 to make the zip file and not WinZip? I tried a pdf file and it wouldn’t work as part of the Help menu.

Edit: OK, I did the decompress, delete, and recompress process again, and this time did not compress the entire folder, just the entire folder’s contents, and it works. Thanks a lot for your help on this, guys!

1 Like


Just to be clear

  • Uncompress and unpack the .vmod file

    unzip Foo.vmod 
  • Remove whatever files you do not need

     rm Foo/Bar/Baz.bla
  • Pack and compress the whole directory

    zip Foo

The above is how I’d do it on Linux, but I think something similar is available in MicroSh*t Power[less]Shell.

To add a PDF as a help file, use the Add PDF Help File by right clicking the [Help Menu] in the editor.