Module 'Library' - Sponsor's Onus

Site Feedback
1

I believe that to delete a file from the module library is not the prerogative of the Vassal people, it is the prerogative of those who (supposedly) manage that particular vassal module webpage.

This inability to personally delete obsolete files just leads to server file bloat. Someone pays for the amount of storage disk memory used. Keep that to the minimum - and not have to go through Joel or whomever, to get a or many files deleted.

I think you guys have gone overboard with the retention of obsolete/superseded versions. Every vassal game module and its extensions need only to store/display the current version(s). Anything prior to these version(s) is a waste of storage space. Your server storage space. That has got to cost you something. As time goes on, so does the amount of disk space grows and ipso facto the cost.

While there is always a need for version management and, perhaps, historical retention of previous versions, please remember that the module owners (at least I do) keep most, if not all, of the previous versions. For Vassal to do so is a waste of resources and server capacity. Caveat Venditor applies here. It’s not up to Vassal to ‘police’ what can or cannot be added/removed. Vassal need only confirm validity.

You overly complicate a cloud storage system. Google drive allows you to upload a new version and also delete the old one and also rename the new version. If you want to keep the older version - for version control - then fine. But that is a user/owner responsibility, not anyone else’s.

So. I really believe that you need to rethink the whole system of how vassal modules are stored on your server. The ‘owners manage’ and you provide the storage medium and some control over what can be uploaded. Deletion is never an issue.

PS How much time is spent is micromanaging the way the vassal module website is run?

2

The storage cost is small enough that I haven’t been able to justify taking the time to remove files which can’t be downloaded because nothing links to them. That is the first step I would take were I concerned about storage costs.

Very little, on the order of single-digit number of minutes per week.

3

I spent this evening doing some cleanup:

  • Compressing the errorLogs stored with bug reports reduced them from 716MB to 45MB.
  • Removing thumbnail images not referenced in the old wiki archive reduced that by 4.7GB.
  • Removing other files from the old wiki not referenced anywhere reduced our storage usage by 96GB.

This will save us around $2 per month.

1 Like
4

Thanks Joel.

5

And just how many requests do you get to delete per day/month?

I ask as a friend says it takes several days (like 4/5) to get a file deleted. Thus you may spend little time doing this as everyone does not ask because of the time delay.

Also, does your statement re the expenses incurred mean that you do not care how much this costs? Considering Vassal is supposed to rely on donations to continue, I would have thought that minimising costs to operate would be a sort of an imperative. Otherwise, why do people pay Vassal money? Perhaps we may need to rethink our contributions to Vassal. Although I do admit I do not currently donate to Vassal.

At days end, would it not simpler to actually allow module page OWNERs to do what they need to do to manage their ‘own’ vassal module page?

Why do you ‘need’ to have complete oversight and management of what the ‘owners’ do with their stuff on their vassal module webpage? I see that as totally unnecessary.

I come back to micromanagement.

6

One or two per month.

No, and that’s a strange conclusion to draw from what I said.

We appreciate people’s donations, and those donations go toward our monthly hosting bill. Our major monthly expense is compute, not storage. Reducing our storage bill to zero would have negligible impact on our monthly costs.

The storage cleanup I did last night took about three hours to achieve something that will save us around $2 per month. If I had been doing that solely for the cost savings, I would consider it to have been a misuse of my time and I hope you would as well.

No, it would not be simpler. What you’re suggesting would involve writing and testing a significant amount of code. Simpler is what we have now, because it already exists.

The module library is intended to be archival. Once a version of a module is released, people may be depending on it. They may have saved games and logs that use it. If project owners can delete released files, that makes those files unavailable for people who were depending on them.

You might keep old versions of your releases. Not everyone does. What happens if your drive fails? Do you have backups? What if your backups are bad? What if someone wants an old version from you, but you’re busy, your email address is no longer current, you’re no longer interested in working on the module, you don’t feel like replying, you’re on vacation, or you’ve died?

You may think these things don’t happen frequently, but with more than three thousand modules, I can assure you they happen quite a bit—I have personal experience of every one of them from the past twenty years. Keeping only some files also doesn’t work. You cannot infallibly predict which versions of which files people will want. In order to ensure that files are available when someone wants them, you can’t be selective—you must keep everything.

If files people depend on can disappear, then you do not have a safe, reliable ecosystem. This is something that’s widely recognized, and we’re far from the only software repository that is archival. Package repositories such as crates.io also do not permit file deletion save for exceptional circumstances, for exactly the reason I just gave.

I hope this adequately explains my position.

7

Not that I’m advocating it but …

One could imagine a system where one only keeps the latest patch release of module, because patch releases are meant to be compatible.

Reminder: The Game Library now enforces the use of three-part release numbers: major.minor.patch - often known as semantic versions. If one subscribes to the paradigm of semantic versioning, then a change in the major number signifies a change that is incompatible with previous version. That may be too much to ask of Vassal modules, so a change in the minor number could be taken to mean an incompatible change - incompatibility in Vassal modules is very easy to introduce - just add, remove, or change a piece trait - and boom, the new module may not be compatible with older modules.

That is, if you have the module Module with current release 1.2.1, and you make a small - compatible - change, you would get 1.2.2. When uploading that to the Game Library, it will overwrite 1.2.1 (which would be gone for good). The Game Library will therefore not have anything that relates to the patch version - only the major and minor version:

  • Module
    • 1.2
      • Module-1.2.2.vmod
    • 1.1
      • Module-1.1.20.vmod

(Edit: corrected minor version - wait it was correct, changed back)

Of course, that would require that module developers are disciplined in their release numbering, and adhere to a common standard - something which is blatantly not the case. And that, in and off it self, is a good reason to keep everything to ensure availability of compatible modules.

Note, most modules do not have a whole lot of releases, so for most projects it’s not really an issue. If one want’s to save storage, it is likely more efficient to cut down on the size of individual modules by using reasonably sized graphics.

Even without such a scheme, perhaps a system that would allow project owners to flag files for deletion could be an idea. Then, at a time of maintainer’s choosing, those files could be deleted - just to ease the process a bit.

Yours,
Christian

1 Like
8

My main concern is about scenarios, not necessarily modules or extensions.

If I have a bug in the 2.1.1 version of the module, I can fix that, upload 2.1.2 and put out a release note saying the bug is fixed in 2.1.2.

I can do the same for an extension. In fact that’s easier because I don’t have to update the whole module, just one piece of it.

The WiF CE module now has 48 scenarios (game start files) and with the number of different scenarios and campaigs that the base game included plus user contributed ones that’s likely to continue to grow. That’s a lot of scenarios and running tools → Refresh Counters on each one as the module goes to a new version takes some time. I can’t spend the time manually scrutinising each scenario as it goes out the door. So occasionally I find a bug in one. However each scenario is specific to one particular version of the module. So if I find a bug in one I have to wait for the next release of the module to upload a fixed version of that scenario, because I can’t re-upload the broken one with a fixed version. I can put a note out on the game discord or FB groups and say “don’t use scenario 403 for version 2.1.1 of the module, it’s broken, wait for 2.1.2 for a fix” but that gets kind of tedious.

If it were possible to re-upload a broken copy of a file with a fixed copy of the same version of the file that would alleviate the tedium.

9

What you can’t do is re-upload a file in the same release with the same name. A simple way to distinguish different versions of a scenario would be to give them distinct names.

10

Yes, we’ve tried that. 120-global-war.vsav; 120-global-war-subs-fixed.vsav; 120-global-war-another-attempt-at-fixing-subs.vsav; 120-global-war-fixed-subs-but-broke-something-else.vsav. And everyone still downloads the original and wonders why the subs aren’t fixed.

11

Have you considered putting a version number of the setup in the filename of the setup?

12

So where does Onís fit into this discussion?

13

FWIW, I assumed he meant “onus”, arguing that file deletion should be the module developer’s responsibility.

14

I assumed so too, but then I remembered this post, and now I’m not so certain :smiley: Just goes to show we can all make mistakes.

The saves could be named

  • 120-global-war-1.0.0.vsav
  • 120-global-war-1.1.0.vsav
  • …

In that way, it is more obvious, to me at least, that 120-global-war-1.1.0.vsav (120-global-war-subs-fixed.vsav) is newer than 120-global-war-1.0.0.vsav, and that I should be using the former.

Then you may also have a matrix of which save works with which module version

Save Version Module Version Notes
120-global-war 1.0.0 2.1.4 All maps
1.1.0 2.1.4 Fix problem with subs
…

(yes, tables are supported in the README section of a project).

You can even make the name an internal link to elsewhere in the README section of the project page.

World in Flames Official CE ++ is a beast - sort of reminds me of this recent article in the NYT. I don’t think those guys have anything on anyone trying out World in Flames :smiley:

Yours,
Christian

1 Like
15

Well, he is talking about World in Flames, which is a monster, so Japanese demons might be applicable! :stuck_out_tongue:

16

Surely no-one would be so gauche as to pluralise Japanese nouns.

17

Yes to you. Not to everyone else. They just pick the first one from the list. You’re assuming a level of technical competence that many users don’t have.

Only the games saved with version 2.1.4 work with version 2.1.4. Any prior save will need Refresh Counters run on it. So we always do a Refresh Counters on all saves from previous versions each time we release a new module version. Hence we need to re-release every saved game each time we release a new module version. So it’s not really relevant, all games under the 2.1.4 tag are for the 2.1.4 module version without exception.

No, CfNA is significantly more complex than WiF, just based on page counts for the rules. It’s just that WiF is a whole world strategic game and has a lot of different scenarios for parts of the war.

18

Et tu brutus. Note, retitled to Onus.

19

I think perhaps you have too llittle fate in your fellow gamers - a good fraction, I think, will understand it as I do. After all, playing World in Flames Official CE ++ would seem to warrent some systematic thinking :smiley:

Saves (.vsav) should be compatible between module versions if the piece traits have not been changed. What is written in the .vsav is the state of pieces - i.e., the unrolled trait parameters and states.

So if you adopt a release number policy on the modules that will reflect when incompatible changes are made, then you may carry .vsavs between releases, and there’s no need to run the refresh.

I’ve adopted the policy that I increment the minor version number of a module if I make incompatible changes to the module (i.e., change one or more traits of one or more pieces - possibly indirectly via prototypes). If I only make small bug-fixes that does not create an incompatibility, I increment the patch number.

For example, starting from release 1.0.0.

  • Assume I make a minor change - say change a parameter on a board that has no effect on any piece trait - I change the release number to 1.0.1
  • Next, assume I add a trait to one or more pieces - then I change the release number to 1.1.0
  • If I change a default value in a trait, which is typically part of a state, then that may no create an incompatibility, and I therefore only increment the patch version, resulting in 1.1.1.

That also means that the Saves package only needs to track the major.minor version of the module. That will both cut down the number of saves that are uploaded, as well as the maintance the saves.

Of course, it would still make sense to version the individual saves in case there’s changes to the saves.

Yours,
Christian

20

That’s the problem – in nearly every release of the module traits do change. Even if it’s a minor change, e.g. in the current module version there is a mis-spelling of a deck name in one of the traits. That means we’re going to have to correct that mis-spelling, and because each counter contains a full unpacking of the counter template in the counters repository the only way to correct that mis-spelling across all counters on the map is to run Refresh Counters.

That means that the saved game version is almost always tied to a module version.