[REL] JoneSoft Generic Mod Enabler (JSGME) v2.6.0 now available!

[JScones]

Just report one of my posts...that'll get moderator attention pretty quickly, LOL!

[raymond6751]

[quote] Changes:
- Fixed: now correctly disables mods that have [ as the first character in the mod name
- Added: new enhanced game file compare feature
- Changed: snapshot/compare feature now based on MD5 sums, not date stamps
[unquote]

While I applaud upgrades to the software, I am unsure of why I need it. What is about to go wrong, as in what has needed a fix?

The above quote indicates a new feature but not what makes it of value.

As already mentioned, if you are involved in play, what about this makes it an immediate concern?

[JScones]

- Fixed: now correctly disables mods that have [ as the first character in the mod name

In earlier versions, mods with names starting with [, for example "[My Mod] Name of mod", would not be disabled correctly by JSGME. Presumably a problem affecting only very few people, for I was only alerted to it earlier this year, seven years after initial release. But, a problem it was, so it needed to be fixed (even though the workaround was very simple).

If you don't have mods starting with [, then you won't notice any difference.

However, as the enabling/disabling code has been changed, I decided that it would be prudent to ask all users to disable ALL mods before installing v2.6 in order to minimise the potential for problems.

- Added: new enhanced game file compare feature
- Changed: snapshot/compare feature now based on MD5 sums, not date stamps

Not critical, just some improvements to the file compare feature for those who use it. The comparison is now presented in a dialog box where users can scroll through or sort for easier analysis.

Using MD5 sums to compare files now means more accuracy over the previous time stamp only method, which was only ever meant to be temporary...it just took me a few years to update it to something more robust.

Besides the above, one or two people have stated that v2.5 has a problem with removing new folders that neither v2.4 or v2.6 has. I haven't been able to replicate the problem on my XP or Win7 installs, so this may be limited to certain system configurations (IIRC the users were running XP SP3). As no-one has reported this problem with v2.6, I strongly encourage all users to upgrade as soon as practical...but there will be no issue if people prefer to wait until they finish their current career or whatever.

[Highbury]

Although I never ran into issues with the previous versions (and I use JSGME for EVERY game I mod so much as a texture in), I do really appreciate the new version. For me the drag-and-drop feature, as well as the auto refresh of the mods list are pure gold.

Thank you for the continued development!

[skwasjer]

With many free apps I'm like, **** it, it's so ****ty I'll just build it myself. No such thing with JSGME.

[JScones]

Thanks guys.

Originally Posted by skwasjer

With many free apps I'm like, **** it, it's so ****ty I'll just build it myself.

Hehe, I'm exactly the same. And in a way, that's how JSGME started. I found the mod manager that came with Panzer Elite to be inadequate, so I decided to build my own that could be used not just for PE, but for Flying Corps Gold and EAW; two other games that I was heavily playing at the time.

In fact, my JSGME test environment still consists of FCG mods from 12 years ago!

[Venatore]

Originally Posted by JScones

In fact, my JSGME test environment still consists of FCG mods from 12 years ago!

Never forget the old games

[JScones]

Originally Posted by Highbury

For me the drag-and-drop feature, as well as the auto refresh of the mods list are pure gold.

It's part of a deliberate attempt to more tightly integrate JSGME with the Windows Shell to make it all a bit more seamless for the user (after all, JSGME deals with files and folders). Just have to make sure I don't go too far and alienate XP users or slow down performance (for a short while I tested using Shell file operations to copy/move the files around and was amazed at the performance hit. Operations that would ordinarily take 1 second to complete were taking 45...suffice to say I reverted back to my raw core calls and ditched the Shell calls, hence why you don't get warnings when files can't be copied (because they are open or whatever)).

Originally Posted by Venatore

Never forget the old games

Wow, I think it was that exact ad that prompted me to buy one around the same time.

[tonschk]

Thank you JScones, great work!

[raymond6751]

I apologize for an earlier post that may have offended. The Jonesoft enabler is a very valuable tool.

I was asking, without intending injury or rebuke, what the new 'features' meant and why the old version should be replaced.

I have never had a problem with the enabler and wondered if there was a potential one that I hadn't encountered (yet).

In other words, should I drop what I'm doing immediately for a change, or can it wait until my present patrol is done?

Again, apologies for the tone I used earlier.

[Anachronous]

I use this tool almost every day for a whole bunch of games. I couldn't do without it.

There is one feature that I feel it needs. Reading mods from zip/7z archives. So we can save space and keep things a little more tidy. Just prepare a JSGME ready zip with the proper folder structure, then drop it in the MODS folder, and it's ready to go.

[Abd_von_Mumit]

Today I installed this mod:
http://www.subsim.com/radioroom/showthread.php?t=174841
Now I tried to uninstall it to unlock an earlier mod on the list, but I can't. It gave me some error messages I've never seen before:



I clicked "Yes", and continued unsintalling, but soon I got another error message:



Now it seems I can't uninstall this mod, as it's locked with no way to unlock it. I tried installing the mod that generated the first error message, in hope that after uninstalling it the locked mod would unlock, but it didn't work.


The mod that causes troubles was made by modders from Russia. My theory is the errors are caused by some encoding issues - maybe there were some Cyrillic characters left in the mod folders' names or something like that.

Please help. And thank you.

EDIT: Vista Home 64 bit PL.


EDIT2:
My suspicion was correct - a Cyrillic character left by author in folder name caused the issue (the character looks exactly the same as Latin x, but has a different UTF-8 code number). I checked it by putting the folder name into my browser window. After I pressed Enter, the original name:
IO_Fix_MaskMap_for_TDW_4.3.0_1920х1080
was changed by my browser to
IO_Fix_MaskMap_for_TDW_4.3.0_1920%D1%851080

After I changed the original х to Latin x, and pasted
IO_Fix_MaskMap_for_TDW_4.3.0_1920x1080
into my browser window, the browser interpreted it as
IO_Fix_MaskMap_for_TDW_4.3.0_1920x1080

[JScones]

Correct - see http://www.subsim.com/radioroom/showthread.php?t=173248 for my warning on this very issue.

Modders need to remember to stick to the first 128 characters if they want to ensure full compatibility with all potential users...and more importantly the game itself. As the above link shows, using extended characters with SH3, for example, will in certain circumstances break it, regardless of whether JSGME is used or not.

In your case it might just be the mod folder name with an extended character, which will only break JSGME (because the mod folder itself isn't copied to the game), but if one of the mod files has a similar problem, it could potentially CTD your game, because your game may not be able to "see" the file with the extended character.

I'm in the process of making JSGME fully UTF-8 compliant; at the moment the interface is, but the config files are not. That's an easy fix, however, it still won't compensate for file names that deviate from the standards.

[Abd_von_Mumit]

Thank you for prompt and informative response.

Ended up reinstalling SH5.

[Abd_von_Mumit]

TDW, author of IRAI mod (http://www.subsim.com/radioroom/showthread.php?t=171973), nests modlets in his mod folder, so that after installation of main mod the modlets are added to JSGME repository and can be installed. This crashes JSGME "Load mod profile" option though.

The idea however is a very good one. If it didn't "crash" JSGME it would be very useful for both modders and end users to ensure internal dependencies between parts of one mod are not broken. IRAI is a good example - one can't install a modlet, that needs the main mod to be activated, unless main mod is activated. Uninstallation of main mod hides modlets. Charm. This could be even nested deeper.


For this to fully work JSGME would have to "remember" that a mod is a child/parent of another mod, which doesn't seem to be a hard requirement in my non-programmer eyes. JSGME would also have to recognize MODS folder inside a parent, treat all its sub-folders as child-mods, and install them into user's MODS folder also when user's MODS is named in other way.

Why this would be useful:
- more secure inner-mod dependancies,
- more consistent way of providing documentation (it would be enough to have one documentation folder in the parent mod folder, modlets documentation folders would be optional),
- much more user friendly (especially in case of mega-mods).



Ideas of even further development:
A mod I'm making right now comes in 5 "flavours" - user picks ONE flavour only, as two or more won't work together. These flavours are just sub-folders of the main folder after unzipping. This has currently a few cons:
- users can't just copy whole the unzipped folder to JSGME - it won't work. They need to manually pick one "flavour" (sub-folder) and copy it to JSGME.
- I have to either put documentation into each sub-folder, which is producing redundant kilobytes, or put just one documentation into the main folder, thus stripping the "flavours" of the useful JSGME right-click context menu fast access to documentation.
- there is no mechanism preventing users from installing more than 1 flavour in the same time.

What's more, the mod will have options - they can be applied to some flavours, and can't be applied to other flavours. This is again a dependancy issue. These options also come as sub-folders, just like flavours. What may go wrong:
- users can install option on top of wrong flavours,
- users can install options without installing any flavour,
- options are not documented unless with redundant files.

This would work smooth if I could put a config.jsgme file into every sub-folder, which would say:

requires "other_subfolder_name_A"
requires "other_subfolder_name_B"

These would trigger visibility of these mods (subfolders) in left JSGME window, after installing whole the mod as it comes out from a ZIP file. Initially only those subfolders would be visible that don't have any "requires" record. This also would save space on documentation.


Can you imagine that? No more:

Your mod doesn't work for me!

Because instead of installing it like
A
B
C
D
you should install it like
C
D
A
B

AvM