I don’t know whether it is due to changes made in my module or to Vassal itself, but my save game and log files are now over 15 MB uncompressed and over 700 KB when compressed. It’s not really a problem, as such, but why are these files so huge, and does anyone have any general advice on how to avoid them getting bigger? I remember over a year ago save game and log files for the same module came in under 300 KB, so if there is anything that can be done without compromising on module functions I’d like to know about it.
I don’t know whether it is due to changes made in my module or to Vassal
itself, but my save game and log files are now over 15 MB uncompressed
and over 700 KB when compressed. It’s not really a problem, as such, but
why are these files so huge, and does anyone have any general advice on
how to avoid them getting bigger? I remember over a year ago save game
and log files for the same module came in under 300 KB, so if there is
anything that can be done without compromising on module functions I’d
like to know about it.
We’ve changed nothing in how the data in saved games and logs are stored
in quite a long time. (I don’t recall when we’ve ever made such a change,
in fact, so that would put it at least 8 years ago.) If you’re getting
larger saves, it’s due to some change in your module.
700KB is tiny. It’s so small as not to be worth thinking about, given
the amount of storage devices have these days. You’re wasting your time
by trying to do anything about it.
The reason saves and logs have such a high compression ratio is that our
storage format contains a huge amount of redundancy. Most of that will
be gone in VASSAL 4. We’re not in a position to do anything about it in
VASSAL 3.2.
700KB is tiny. It’s so small as not to be worth thinking about, given
the amount of storage devices have these days. You’re wasting your time
by trying to do anything about it.
That’s like, your opinion man. (sorry, out of place Big Lebowski reference).
Thanks for the reply, and it’s good to know that there’s nothing going on on the Vassal side of things.
When you are emailing logs and saves every day, and an archive of all game turns for one game alone clocks in at a hundred to several hundred logs and saves it’s not a trivial amount to store. If anyone has any clue as to what module changes cause significant changes to save file size I’d like to hear about it.
Save/log sizes go up in accordance with the number of pieces you have on the map and the number of traits associated with those pieces. So if you have a lot of At-Start Stacks, and all the items in those stacks have lots of traits or reference Prototypes with lots of traits, file sizes increase. When Joel mentioned the redundancy above, that even extends to the names and descriptions of the traits. Descriptions are really useful when editing a complex module just for the sake of your own memory, but the longer they are and the more of them there are, it increases size.
Those are my experiences, but the most complex module I’ve built only has enough items to make saves/logs around 120KB in size, so your module must have a LOT more pieces.
Thanks! I’m guessing it’s less the number of pieces than it is the fact that just about every one of them references some very complex prototypes. I’ll try shortening some of the descriptions on the more heavily referenced prototypes and see if that makes any difference, but since they only use about 12 characters on average I can’t see it making much difference. You’ve certainly given me something to think about though, so thanks again!
700KB is tiny. It’s so small as not to be worth thinking about, given
the amount of storage devices have these days. You’re wasting your time
by trying to do anything about it.
That’s like, your opinion man. (sorry, out of place Big Lebowski
reference).
Let me tell you something, pendejo…
500 saves at 700KB each is only 341MB. That’s hardly anything. If you’re
having trouble storing that amount of data, I’ll mail you a 2GB flash
drive I’m not using. Seriously.
Anyhow, VASSAL 4 saves and logs will be much, much smaller, as a side-
effect of a better log and save format. (My estimate is that they’ll be
about two orders of magnitude smaller for the same data, based on some
testing I did with gzip.)
