Having made the effort of rebuilding the index page for the Europa series, changing the links will mean rework.
I was thinking I didn’t need to follow this thread anymore, so others maybe in that place too.
So, be sure to tell anyone else who has category pages to manage.
In case I miss the final decision, please, message me if I need to schedule rework.
Daniel
All projects with numeric ids have been renamed, in most cases to match the names of their pages from the old wiki.
Links to module pages in the old wiki now redirect to the new module library. (In cases where pages have been split, the old URLs redirect to a search page displaying results for the name of the old module page.)
Links in project pages to other project pages have been updated to reflect the new project names. If you had such links, you might want to verify for yourself that they were converted correctly, but there should be none you need to manually convert.
If you find that any of the above are not the case, please let me know so I can fix it.
The backup of the wiki, https://vassalengine.org/wiki_old/wiki/Category:Modules, only works for the 1st page of any search criteria; if you click on the “(next page)” link, or any individual letter to jump to that letter, you get:
Not Found
The requested URL was not found on this server.
as the link goes to https://vassalengine.org/w/index.php.
I really like the new look. One thing that would be nice is a second set of forward/back navigation buttons at the top of the screen. That way you wouldn’t have to scroll to the bottom of the page if you were trying to browse through the list. (ie. looking for games starting in ‘So…’ after clicking on ‘S’.) Keep up the good work and thanks for all your efforts!
I currently do not own copies of these games, but I am very well familiar with them , as I have owned all of them, or played extensively enough to spot flaws.
Afrika Korps
I’ve played a few times, and I’m willing to take ownership so that it isn’t neglected. It’s been about 45 years, BUT AK is simple enough that any problems should be obvious.
I have just uploaded a new module version and my feedback is that it was an easy and hassle free experience.
Well done everyone, especially uckelman for all his hard work.
Just a couple of questions on extensions though.
When did we move from .vmdx to .vext for filenames as I seem to have completely missed that one? (.vmdx won’t upload).
The version checking for extensions does not seem to recognise the “Allow loading with any module” flag and prevented upload.
This wasn’t an issue as I quickly fixed things but I thought I would flag them for your info.
I had the "Allow loading with any module” flag set in the extension so it can be loaded with any version of the main module (and it does). However, the site upload code must check the main module version embedded in the extension because it refused to load the extension into the Release area with a module mismatch message. This was probably because the embedded reference was older than the main module version it was uploaded with (or the site area Release Number).
This is valid if the extension is tied to a specific main module version but shouldn’t apply when the any module flag is set.
I fixed the issue by simply editing the extension to the latest main module version.
I’ve deployed a fix to the library frontend just now which should solve rejection of seemingly valid package names. (Package names which had characters in them which needed to be percent-encoded to appear in URLs had not been so encoded. They are now.)
I’ve deployed a change to the library frontend which ensures that the full page title appears in the outgoing HTML instead of being fetched by JavaScript on the client side. This means that things like link boxes, such as