Switching to the New Module Library

woody8297 · June 25, 2025, 11:35am

Richard,
I’m glad I could answer your question. Pure luck since I didn’t know what you meant.
I added “Vassal version 3.7.15” to the end of the ReadMe text so others will know.
Frank

uckelman · June 25, 2025, 11:41am

The immediate reason is that nothing fills in the requires field when modules are uploaded at present. The reason for that is more complex. In general, it’s not possible to determine programmatically what versions of Vassal a module will run with. We can extract what version of Vassal a module was written with, but that’s not the same thing. The old wiki demonstrated that we also can’t rely on module designers to report this accurately, or even understand what they’re being asked. The Compatibility field in the files table on module pages in the old wiki was frequently incorrect, empty, or filled with something not referring to a version of Vassal. During the conversion from the wiki, we tried to repair as many of these as possible, but it’s likely imperfect.

Rather than have this field fill with garbage, I’ve left it blank on new uploads until we determine what should be done.

woody8297 · June 25, 2025, 11:44am

Joel,
I added “Vassal version 3.7.15” to the end of the ReadMe text. If there was a place to enter that, I missed it.

Please remove the Project entry titled “Waterloo_Tournament_Edition” because it is a duplicate of “Waterloo_AH_Tournament” and I wasn’t able to delete it myself. I flagged it for removal but I see it’s still there. I understand you’re busy so, sorry for the extra work.

Thanks
Frank

cholmcc · June 25, 2025, 12:48pm

Presumably, uploaders will be able to retroactively specify the minimum compatible Vassal version, once that is implemented in the front- and back-end.

In the mean time, I’ve added a suggestion to How to upload modules to the Game Library to specify the minimum required Vassal version (as well as what currently isn’t possible).

I think the best compromise is the dual approach I suggested above.

An uploader or owner may specify the minimum compatible Vassal release, preferably chosen from a drop-down menu, so that uploaders or owners cannot give bogus information.
If the uploader does not specify anything, then the Vassal release used to make the module, rounded down to the least patch release will be used.

What I mean by rounded down to the least patch release if for example, if a module was made with Vassal release 3.7.15, then the least patch release will be 3.7.0. I think that’s a reasonable assumption, because patch releases should not introduce incompatible changes, according to semantic versioning.

Ideally, and owner of a project should be able to edit the minimum required Vassal release, even after upload.

One could consider also adding a maximum compatible Vassal release, since sometimes modules contains custom code, developed against older Vassal releases, that is not compatible with newer Vassal releases. However, I think that’s a complication that will not be generally useful, so maybe not worth the effort.

Likewise, one could consider adding a minimum (and possibly also maximum) required module release for saves, logs, and extensions, which could be set in the same way as the module requirements are set (either by choice, or automatically from the meta data in the file - e.g., a .vsav made with _modul_e release 1.2.3 has a compatibility range of 1.2.0 to 2.0.0 because incompatible changes to the module should increment the major release number). Clearly, it is a complication, but could be useful in more cases.

Yours,
Christian

rattle · June 25, 2025, 6:28pm

Just informing that I can no more successfully upload any files.
Project: 2548 - Race! Formula 90: 2nd Edition

I tried to log off and log in again with no result.

PS: great job on the upload progress bar

uckelman · June 25, 2025, 8:46pm

It is now possible to delete empty packages.

jrwatts · June 25, 2025, 9:39pm

What if my module relies on a bug fix introduced in 3.7.15 to operate properly? Saying it’s “compatible with 3.7.0” in that case would be very misleading. Personally, I think anything that encourages users to update to the latest version of VASSAL is a good idea, so if the module was created in 3.7.15, it should say it requires 3.7.15, not 3.7.0.

Vorchek · June 25, 2025, 10:26pm

Deleting an entirely empty package definitely works.

cholmcc · June 26, 2025, 5:17am

That is why you, as a project owner, should be able to override the default by choosing a patch release from a drop down menu. The drop down would contain all currently known releases and patch releases.

People may have valid reasons why the do not want to update to the latest Vassal release, which is why I think it is wise to give the least required release number as requirement. That is also how all Linux distros does it, and for good reasons.

Yours,
Christian

cholmcc · June 26, 2025, 7:44am

The list of current releases can be found from the GitHub API end point

https://api.github.com/repos/vassalengine/vassal/releases

However, GitHub end-points are rate limited, which means it is not suitable for frequent requests. Another option is to get them from

https://github.com/vassalengine/vassal/releases

and parse the HTML, but that’s a little slow.

To generate the drop-down in the Game Library front-end, it would probably be best to have a table in the back-end.

The current list of releases (ordered by date) is

3.7.16
3.7.15
3.7.14
3.7.13
3.7.12
3.7.11
3.7.10
3.7.9
3.7.8
3.7.7
3.7.6
3.7.5
3.7.4
3.7.3
3.7.2
3.7.1
3.7.0
3.7.0-beta5
3.7.0-beta4
3.7.0-beta3
3.6.19
3.6.18
3.6.17
3.6.16
3.7.0-beta2
3.6.15
3.7.0-beta1
3.6.14
3.6.13
3.6.12
3.6.11
3.6.10
3.6.9
3.6.8
3.6.7
3.6.6
3.6.5
3.6.4
3.6.3
3.6.2
3.6.1
3.6.0
3.6.0-beta7
3.6.0-beta6
3.6.0-beta5
3.6.0-beta4
3.6.0-beta3
3.6.0-beta2
3.6.0-beta1
3.5.8
3.5.7
3.5.6
3.5.5
3.5.4
3.5.3
3.5.2
3.5.1
3.5.0
3.4.13
3.5.0-beta3
3.5.0-beta2
3.4.12
3.4.11
3.5.0-beta1
3.4.10
3.4.9
3.4.8
3.4.7
3.4.6
3.4.5
3.4.4
3.4.3
3.4.2
3.4.1
3.4.0
3.4.0-beta1
3.3.3-beta1
3.3.2
3.3.1
3.3.0
3.3.0-beta4
3.3.0-beta3
3.3.0-beta2
3.3.0-beta1
3.2.17

Older releases - not available from GitHub but in the release archive - are

3.2.16
3.2.15
3.2.14
3.2.13
3.2.12
3.2.11
3.2.10
3.2.9
3.2.8
3.2.7
3.2.6
3.2.5
3.2.4
3.2.3
3.2.2
3.2.1
3.2.0
3.2.0-beta4
3.2.0-beta3
3.2.0-beta2
3.2.0-beta1
3.1.20
3.1.19
3.1.18
3.1.17
3.1.16
3.1.15
3.1.14
3.1.13
3.1.12
3.1.11
3.1.10
3.1.9
3.1.8
3.1.7
3.1.6
3.1.5
3.1.4
3.1.3
3.1.2
3.1.1
3.1.0
3.1.0-beta8
3.1.0-beta7
3.1.0-beta6
3.1.0-beta5
3.1.0-beta4
3.1.0-beta3
3.1.0-beta2
3.1.0-beta1
3.0.17
2.9.9
2.8
2.7
2.6.4
2.5.2
2.4.2
2.3.2
2.2.2
2.1.1
2.0.5

Yours,
Christian

jrwatts · June 26, 2025, 8:44am

And what is the very first thing that the devs will ask if you report a bug?: “Are you using the latest version?”

The VASSAL devs are volunteers and don’t have time to deal with bugs in old versions.

steenkh · June 26, 2025, 8:54am

My 502 problem with uploading has disappeared. My module is now uploaded.

rattle · June 26, 2025, 2:53pm

Mine still persists…

uckelman · June 26, 2025, 3:33pm

I need more information about the module you’re trying to upload. How large is it?

cholmcc · June 26, 2025, 4:04pm

That is actually not my experience - including when we talk about general software. Often, developers are more interested in if you are using a stable release than using bleeding edge.

In the context of Vassal, bugs in modules are typically not triggered by mistakes or problems in the Vassal core, but some bug in the module it self. Sure, sometimes bugs show up in Vassal core, and then it may be relevant to try a different release of Vassal.

Most Linux (kernel and user-land) developers and packagers are also volunteers, so I wouldn’t necessarily take that as argument.

My proposal would simply default to the start of a minor release series - e.g., 3.7.0, because patch releases are not meant to introduce new features. And if you know that your module need a specific patch release, due to a specific bug fix, then of course you should be able to stipulate that. And I guess you will not go an retroactively “fix” your modules to depend on the latest and greatest version of Vassal every time a new release is made - that would seem to be a waste of time.

Yours,
Christian

uckelman · June 26, 2025, 4:08pm

If I’m going to put effort into extracting the Vassal version used from modules, I’m not sure why we should permit upload of modules for versions of Vassal which aren’t supported at the time of upload. Presently, that’s 3.7.15 only.

cholmcc · June 26, 2025, 6:57pm

You essentially already have it in line 54 of module.rs

fn versions_in_moduledata(md: &str) -> Result<(String, String), Error> {
    // extract <version> from moduledata
    let package = sxd_document::parser::parse(md)?;
    let document = package.as_document();
    let value = sxd_xpath::evaluate_xpath(&document, "/data/version")?;
    let require = sxd_xpath::evaluate_xpath(&document,"/data/vassalversion")?;
    Ok((value.string(),require.string()))
}

fn check_version_impl<P: AsRef<Path>>(path: P) -> Result<(Version,Version), Error> {
    let md = dump_file(path, "moduledata")?;
    let (mod_ver, req_ver) = versions_in_moduledata(&md)?;
    let mod_v = mod_ver.parse::<Version>()?;
    let req_v = req_ver.parse::<Version>()?;
    Ok((mod_v,req_v))
}

Why would you not permit that? I do not see the rational for such a requirement.

In effect, it would force users to upgrade their Vassal installation to the latest installation when ever they download a new module. That seems a little odd to do so - especially if the module does not actually require a newer version of Vassal.

On top of that, there’s no guaranty that a newer release of Vassal does not contain new bugs or errors, and so it may be quite counter-productive to update. Plenty of posts in this forum has shown that.

If a module is known to work with - say 3.6.10 - then it would be false to say that it requires the latest release, and it would be dishonest to claim so, for no good reason as far as I can tell.
On the other hand, there can be very valid reasons why some user is not inclined to the most bleeding edge release of Vassal. Why should they be given the impression that a module cannot be used with their installation if in fact it can?

In any case, I hope you will project owners specify the required Vassal version, as they are best positioned to judge that.

Yours,
Christian

Popestar · June 26, 2025, 8:07pm

I haven’t been around these parts in a very long time - not since I created and uploaded Last Night on Earth, to be exact. But there is one module that I have that I decided today to see if it had any new updates to it since I downloaded it all those years ago. The game/module in question here is NFL Strategy. Imagine my surprise when I clicked on it that:

I’m not listed as one of the players of the game, even though I distinctly remember updating that.
I’m not listed as the person who last updated this module to version 1.6
There is nowhere to click on the existing modules/versions to download them

So I decided to check on Last Night on Earth, just to see if maybe I did something wrong with NFL Strategy. When I go to LNOE, I am listed as the owner, the last updater, and I can see where to download the module if I somehow lose it.

Is this a known issue? Is this something where not all links were migrated to the new library? Am I simply losing my mind?

JoelCFC25 · June 26, 2025, 8:19pm

One possibility is that on the old LNOE page, your username is also linked to an email address. On the old NFL Strategy page, your username is there but not linked to an email address.

Maybe the process by which project owners were determined didn’t go to the lengths of comparing places where a user’s identity was more detailed to other pages where it wasn’t. Also, though I can’t recall for sure how owner(s) were determined when more than one name was present as with the NFL game, but it might not have helped that you were only listed as a contributor, since all the other folks in the “Developer” column got scooped up and made co-owners.

It should be easy to get yourself added as an owner though–send a private message to @uckelman.

Popestar · June 26, 2025, 8:53pm

That makes sense about ownership and/or updates. But why are no links available to download?