You are correct in principle Lothar, unfortunately the previous version of the HPW mod had a different folder name and so was left in tact in the JSGME display, which makes it rather confusing for users of the mod. Here is an example of the JSGME display:
This is a perfect example of the
problems that can result from using version numbers in mod names, as HPW's FM mod
used to do. Now you've mangled yourself into having three different incompatible versions of HPW's FM mod on your system and you have no idea how it's actually working or which is actually active in game.
Had you just installed the HPW 4.0 .exe installer or the .7z according to instructions, OFFice would simply ignore the 3.0 and used the 4.0 update automatically. In general, OFFice just won't itself activate old legacy mods with version numbers in their name, and will activate the newer supported-and-tested version-free folders on top. In short, had you followed instructions and left well-enough alone, it all would've worked automatically and transparently. I'll explain what's wrong with your setup below.
I'm sorry it confused you, but this is a hangover from the bad old days of OFF mods, and why still so many old-timers are afraid of using mods at all. One goal with OFFramp taking over JSGME is most users should never even ever use the clunky and unhelpful JSGME themselves and thus never even have a chance to get confused then mess up their install in the first place. Everything "just works" out of the box. Trying to "fix" what ain't broke only causes problems.
I recognize it is imperative that all moder's consistently use the same folder/file naming conventions if OFFice is to work but this is not the case as many legacy mods exist on many of our systems. Note that many users have legacy versions of mods previously downloaded outside of OFFice and these will not go away unless purposely removed. Also consider that if a mod does not work or turns out to have undesirable effects, a client needs a way to fall back to the previous version should they wish to do so and this can only be done if there is a way to visually identify the version of the mod in use and which previous version is needed. The client has two choices as I see it, keep the various downloaded mods on their hard drive in folders that identify the versions, or start another download of the previus mod if it is still available on the server.
The problem is the vast majority of those "legacy mods" just don't work.
Period. For example, HPW's FM mod prior to 3.1--that is ones with the version number in the name--have a bug that completely prevents OFF's Order of Battle dynamic campaign engine from assigning the modded planes to AI squadrons. If you'll dig around the forums you'll find lots of old complaints from people about empty skies in the campaign. Wasn't until this summer that Creaghorn and I figured this out testing OFFice, then HPW reworked his mod to work properly in Campaign mode.
Also, because of confusion about where JSGME should be installed, most of the other "legacy mods" used the wrong folder structure so they never worked for many people to begin with. For example, folks reporting campaign aircraft worked fine with "HPW FM and EW Campaign Mod 2.2" and earlier had such "luck" only because the mod's folder structure was wrong for the correct location of JSGME so wasn't actually overwriting the correct files--wasn't truly "active" despite what JSGME said! Depending on where you installed JSGME--and most people had been putting it in the wrong place--some mods worked, some didn't, and most didn't work together. It wasn't until HPW corrected the file structure of his FM for 3.0 that many people were actually using it for the first time even though they had older versions installed and presumably "active" in the JSGME window.
This is why Creaghorn didn't run into the "empty skies" bug and get me on the problem until HPW's FM 3.0, and why I was able to track the problem to the FM. If OFF's most experienced modders can't even tell which mods are properly installed and active on their systems using JSGME alone, it's no surprise when users like you steer into the quicksand.
So: using JSGME "legacy mods" released prior to this past summer that haven't been refactored for the proper file structure is only liable to make a mess of your system. The versions of older mods included with OFFice are refactored and tested to work without issue. This is one of the major reasons for OlPaint01's bundles last summer and now the full OFFice package. This is why I've built the
NSIS installer system for OFF JSGME mods, and built a
special version of JSGME just for OFF (JSGME_2.6.0_OFF.exe) which is itself bundled with OFFice.
In short: you have no idea what a massive mess I've been trying to clean up, and what a little mess you've made of your own system trying to outsmart all this work of mine.
Transparencey has it's advantages but that usually comes at a cost as well. Again consider that the criteria you set out makes sense and is essential for OFFice to work propertly, but it doesn't address the legacy mods that are out there and in use by many who do not yet use OFFice, or who may never want to live with the imposed OFFice mods, or may wish to include others of their choice. Whether people use OFFice or not they may elect or not elect to remove legacy mods. That is of course their choice. All I wish to say is that It would be desirable for people to easily identify in the JSGME screen which version of the mods they are running without having to go and look at a script file somewhere. This would be time and resource efficient and eliminate having to do additinal downloads for fallback.
Maybe it would be nice to easily identify mod version numbers from the JSGME screen, but JSGME has not been designed with this in mind. It's just a crude file-copy tool, and not an actual mod
manager. Metadata such as version number should not be hardcoded into data filenames, period, especially metadata that can change. Bad practice an any context. Proper mod managers provide other ways to manage such metadata.
Another problem with mod folders with version numbers in the file names is every time an update is released, it won't work in OFFice until someone (me!) updates the script to test for and order and handle the different versions. Which becomes a big giant mess, especially with the dependencies
between mods that are so integral to the OFFice system. The complexity of such scripting grows
exponentially with each new version that must be supported. Thinking about trying to wrangle just makes me want to chuck the whole endeavor and go back to balsa wood gliders.
For us OCD-types like me and you who like to see the version of all the mods installed, easiest thing to do is for modders to put the version number in the documentation file that installs alongside the mod. HPW's HTML readme that comes in his manual .7z installer already does this, and I'll give him a new installer .exe that outputs "HPW FM and EW Mod 4.0.0.rtf" into the mods folder instead of the generic "HPW FM and EW Mod.rtf". One look at that, and it's readily obvious what's installed without having to actually open the readme. And is it that hard to just look at the readme file? And the filenames of the installer .exe or .zip or .7z itself also indicate which version you're installing.
OFF modders could come together on a standard metadata file that could also include the version number in the title for easily visual inspection. For example, inside the versionless "HPW FM and EW Campaign Mod" folder you might see a version.4.0.0.txt file containing metadata. If the version numbers are in a standardized format, it'd be possible to parse out with software as well. Ideally JSGME would show this data when you click on the folder, but of course with development dead that won't ever be possible. But there's no reason OFFramp couldn't use such data to display and help sort out versions.
But really this is complete overkill. If you just use OFFice, you get the latest, fully tested and supported version of virtually every OFF JSGME mod, updated to the latest version automatically when you update OFFice/OFFbase, with no worries about any of it.
I for one use OFFice but I select and use the mods of my choice and not those specifically imposed by OFFice at the exclusion of others I want to run. It is an extra step for me to enforce this, but it works for me and that of course is my choice. Just want to express my views and I thank you for your response and analysis. It is always welcome.
But it
doesn't work for you!!! Let me try to explain what's going on with your JSGME screenshot. And keep in mind from the discussion above that JSGME is clunky, primitive, and untrustworthy--just because it says a mod is "Activated" doesn't mean it's working at all, let alone how the mod designed intended.
So: the old broken 3.0 lingered on your system, but it's absolutely harmless if you're using OFFice. If you manually activate it in JSGME yourself, OFFramp will activate the number-free but functional "HPW FM and EW Campaign Mod" on top. If you activate the "HPW FM and EW Campaign Mod 4.0" you created yourself, OFFice will
also activate the version-free "HPW FM and EW Campaign Mod" it recognizes
on top.
Since you didn't properly install the 4.0.0 update over the old version-free folder by not using the auto installer and going against the explicit installation instructions in the manual .7z archive, your "HPW FM and EW Campaign Mod" is still the 3.1.1 which came with OFFice 0.9.8. So even though you have a
copy of HPW's 4.0 installed, and you think you're activating "HPW FM and EW Campaign Mod 4.0", what you actually get in game is the older 3.1.1. You're not getting HPW's latest changes, and you don't even know it.
But really, what's the point? I simply don't understand this desire to use different versions of mods. There's a reason the update's been released--the old version is broken! That's true with the vast vast majority of OFF JSGME mods. The former practice of posting different versions of mods as different downloads with different JSGME mod folder names only generates confusion and incompatibilities. For example, there are dozens of versions of HPW's FM mod in the CA downloads section, and almost all of them completely break the campaign, that is if you can even get them to activate properly with a copy of JSGME installed in the
wrong folder. Same thing with dozens of versions of his DM, and you might think version 2.5 is newer/better than version 1.3.1 but you'd be wrong (version numbers themselves can be unreliable!).
Imagine if Windows let you "choose" which service pack to activate. It'd be chaos for software developers, who now can count on or advise their customers to install at least some version. Does Steam let you choose which version of patch to apply to games, or does it just install the latest version? Once you subscribe to a Skyrim mod with the Steam Workshops, you get the latest version with no options to choose older, broken versions. All this is
by design! If the differences are so great that a choice between two makes sense, then don't be
'New Coke': give it a different name completely and treat it as a separate product (you can choose between XP and Vista, but should be running the latest service pack of either).
The reason I added update notification to OFFbase is because most of the bug reports I'd get from people were problems I'd already fixed but people hadn't bothered to update their older versions. I'd have to be out of my mind to try to support older broken versions continually.
My advice: stay the hell out of JSGME unless you're a modder who knows what they're doing, and you probably don't even if you think you do. OFFice 0.9.8 doesn't even install a shortcut for JSGME, though 0.9.9 will so users can deactivate mods manually if they decided to stop using OFFbase. Maybe now I'll change my mind though and try to hide JSGME completely.
And for OFF modders: use the same version-free folder name for all versions of your JSGME mods. If I see one more version number in a JSGME mod folder,
I quit.
/endrant