With the new library of game modules structured as projects (rather than just games), has anyone advised how best to upload and present vsav and vlog files that players may want for a particular game module?
In particular, I’m thinking about
Vsav and Vlogs that are specific to a particular version on the project, which likely will become out of date.
Vsav and Vlogs that might be valid to be opened with the modules in more than one project.
Use of the same module implemented for the same published game by different players who may have different interpretations of the state of the game at a particular time (usually the game start).
There has been some discussions about it in past threads, but no consensus has been reached. Joel seems to think that it is a matter of choice by the project maintainer(s) how to do it best for a given module. What I offer below should be understood as my take on it.
Note that projects are divided into packages. What they contain is again up to the project owners. For example, a project could have a single package - say Module which contains a number of versions of the module in question. Other projects will have multiple packages reflecting different implementations or features of a module. Yet other packages will make separate packages for the module (.vmod), logs (.vlog), saves (.vsav), and extensions (.vmdx), as well as any ancillary data.
If saves (.vsav), logs (.vlog), and extensions (.vmdx) are tied to a specific version of a module (.vmod) I would off-hand store them in the same package as the module.
By specific I mean that a save (.vsav) will only work with with one version (or release) of the module. That is, for module A-1.2.3.vmod you have save a-1.2.3.vsav which work together, but a-1.2.3.vsav will not work with A-1.2.4.vmod.
Do you mean project or release?
Suppose there’s two implementations (projects) of game G: A and B. A save made with implementation (project) A is very unlikely to work with implementation (project) B. That is because A and B are very likely to have somewhat different piece traits, maps, boards, and so on.
However, if you have implementation A with releases A-1.2.3 and A-1.2.4 and a save made with A-1.2.3 - say a-1.2.vsav also works with A-1.2.4, then it could make sense to make another package in project A - say Scenarios - where you store such saves. The saves will be versioned, but that versioning is independent of the module versioning. You should of course note in the project README how to pair up saves, logs, etc. with the module releases.
If, and I find that unlikely, you do have saves, logs, extensions, etc, that are compatible with different projects (implementations of a game), then those should definitely be put in a separate package - perhaps even a separate project. However, I find that situation very unlikely, and in the rare cases that it exists, extremely fragile.
It sounds like, but correct me if I’m wrong, that you are taking about a situation where you have implementation (project) A and different saves, logs, extensions, etc. of the same thing. For example, one user foo has made the scenario A-intro-foo.vsav and another has user bar has made A-intro-bar.vsav and your question is how to represent that in the library.
One avenue is to make separate packages for the foo and bar scenarios. Another option is to make one package - say Scenarios where all saves, irrespective of author, are kept. In the latter case, the README section should explain what is what. In both cases, you can add foo and bar as co-owners of the project so they can maintain their scenarios.
In short, it really depends on the project and the ancillary data you have. The only hard’n’fast recommendation I would give is to make sure you document what is what in the project README.
Not that I disagree, and I only want to make a bit of nuance.
If module developers and scenario writers take Semantic Versioning seriously, then the versioning of modules (and by extension scenarios - .vmod) should follow a particular procedure.
Suppose we have a module with a version number Major.Minor.Patch version number X.Y.Z.
The Major version X should be incremented and Minor and Patch (Y and Z) set to zero (0) if, for example,
any game piece or prototype trait is added, removed, or their order changed, as this creates an incompatibility with older saves.
any board’s image, size, or grid, is changed, as this creates an incompatibility with older saves.
any other change that is major in one way or another
The Minor version Y should be incremented and Patch (Z) set to zero (0) if, for example
any game piece or prototype trait’s initial state is changed.
any board or similar image is updated which does not change any size, placement, or similar.
any other change that is deemed minor for example adding another scenario
The Patch version Z should be incremented if, for example
Spelling mistakes are correct
Bug fixes that does not involve changing any trait
and other such minor details.
If this procedure is more or less followed, then the versioning of scenarios, logs, etc. should only track the Major (and possibly Minor) version number. That is, if save a-3.0.0 is made with module A-3.1.0 then that should be good for all A-3.y.z version of the module. If, however, module A is changed in an incompatible way - and the Major version therefore incremented to A-4.0.0, then a user should not expect save a-3.0.0 to work with that updated module.
However, not many modules, including some by myself, adhere to this procedure. Rather, many module developers - in so far as there’s a coherent strategy - seem to reserve the Major version update to when the module is almost entirely re-written, and increments in Minor signals an incompatible change. I think that strategy is sound, but I would encourage developers (including myself) to adopt some clearly defined strategy and also document the strategy on the project README section.
The upload requirements got into disagreement between the frontend and backend the last time I updated them, which is why you weren’t able to upload the vsav files.
Please try again now. Once you’ve done that, let me know and I’ll remove the ZIP files for you.
For the last scenario
Scenario - Xtras - Lightning War
It was by someone else, so please can you get it out of the zip file and place it back in as the vsav so it looks like his?
If that is not possible, leave it for the moment, let me know and I’ll ask him to fix it.
Please, remove the unnecessary zip files.
I also mistakenly uploaded the Spanish civil war vsav in the main module space, so please delete that too, from.
Europa Current Map Modules
We really need a delete option to tidy up when a mistake has been made or maybe an undo button to correct a mistaken upload. I say we need, but maybe it is “you need” as this must be a burden on your time.
Loved the full explanation of the http/1 and /2 story.
I’ve removed these. Please check that I’ve done what you expected. I didn’t follow what you were asking me to do with “Scenario - Xtras - Lightning War”.
It doesn’t happen often that anyone contacts us about deleting files. I’ve created an issue for it, but it may be a long time before I get to it.
Maybe an to reverse an upload in the the wrong place would meet the need and be easier to program? The balance is between programming time and your effort to reverse our careless errors. If you’re happy correcting those errors, then programming can be a very low priority.
