I understand all the reasons given to justify the change to projects instead of the previous structure, but I’m sorry, it’s very difficult to configure our pages satisfactorily.
ok, another question, which is not necessarily related to this topic.
I have already changed my profile picture, but it does not appear on my project pages. Is there anything I can do to update this myself? It is not a priority.
Sorry, but that is actually covered in the above cited page, for example:
Note: At the time of writing it is not possible to delete or rename packages from your project, and you must ask an administrator to do that for you. You should therefore be cautious when entering your package name to avoid needless interventions.
The same thing also goes for tags (the above is implemented as tags in the new scheme):
Note : At the time of writing it is not possible to add tags or other meta-information to the game header.
When features gets added to the Game Library, the page will be updated with the relevant information (note, the page is marked as a Wiki, and anyone can edit it).
Here is an example of what I am referring to using Afrika Korp:
There are 2 Different Packages Using the SAME Package Version uploaded 7 days ago. Neither contain a Vassal Configuration Reference, while the Older Packages uploaded 2 and 3 years ago contain Vassal Configuration References for V>= 3.6.0; this seems to be common amongst Newly uploaded packages to the NEW Module Pages. It Would be Fair to Assume thet the Newly uploaded Package was Configured for the Latest Vassal Version,but I Have NO PROOF of that. I Do not know if these are just old packages configured with OLD Vassal Configurations and just rebranded with NEW Module Versions or if the NEW Module Versions have been completely Reconfigured. It Would be nice to know what Vassal Configuration is Required for the Module.
Clarification: When I Inquire about Vassal Configuration, I am referring to Vassal Compatibility. My Question is about Vassal Compatibility for New Modules Uploaded to the New Module Library.
Rb,
I’m not sure what you’re asking for but if it’s the Vassal version I used when I created the 3.0 module, it is 3.7.15. I believe that is the current version as of this moment.
I’m sorry but I don’t have the computer literacy to know what you mean if that’s not it.
Frank
Currently, neither the front-end nor backend (see line 214 of handlers.rs) handles the requires (compatibility) field of file entries (rows). That means no requires is assigned to new uploads. Older uploads ported from the Wiki-based library typically do have the requires field.
There seem to be a discussion about where the requires information (a string, typically of the form >= 3.7.0) should come from
The back-end can set it automatically from the VassalVersion of the uploaded .vmod, .vsav, .vlog, or .vext
The uploader can set it when uploadeding a file.
or, a combination of the two: If the uploader provides a requires string, preferably chosen from a drop-down menu of Vassal release numbers, then that will be used, otherwise, the backend will set it from VassalVersion of the uploaded .vmod, .vsav, .vlog, or .vext.
Concretely for Afrika Korps, release 2.1.1 (both Colourful and Ol’School) require Vassal >= 3.6.0 - same as the previous releases.
Frank,
Thank You for answering my question. I was just curious as to why the New Module Page did not Display this like it did with the Older Versions under the previous system.
Richard
Christian,
Thank you for giving this issue your attention. My Concern is focused on WHY the NEW Module Pages do not disclose this. As Time goes forward and Years from now when Vassal Releases have Advanced, I think it is Important to know what Vassal Release Version these Modules and Modules Uploaded in the Future are Configured for; that is to say What is their Compatibility or What Vassal Verion is Required. Therefore my issue is simply WHY the New Module Pages are Not Displaying this. I have noted that some Uploaders have Disclosed this in the Comments about their Module on the NEW Pages, while Most Do Not.
Richard
