Just fyi - I've been a bit quiet lately because work keeps promoting me, LOL, so I now get to spend about 90% of my time away from my office and in meetings (indeed, I might drop-in and say "Hi" sometime next year Neal when I'm in your neck of the woods, assuming that's OK with you).

Anyway, my absence doesn't mean that I've dropped support for JSGME though, it just means that there won't be any updates in the immediate future.

Fortunately it doesn't seem that there are any showstoppers with v2.0.1, so you should all be safe in the meantime. ;)

JScones, I have thought of a feature that may take a few steps out of each test cycle during development of mods.

It would be a feature not directly usable from JSGME itself, but by 3rd party tools. Basically, I am envisioning some sort of API that S3D could use to activate a temporary mod (upon save). Say a modder works in S3D, opens a new file, and saves it to the MOD folder of JSGME. Then, he could press a button inside S3D, which will spawn the correct instance of JSGME (or use an already opened instance), and (re)activate (or deactivate if active) the mod in one go.

This requires a method of communication to verify if a specific mod is activated (to indicate state), if a running instance is linked to the correct path (of MODS-folder), and the ability to send a couple of commands (activate/deactivate/reactive?). Obviously, I could just parse your config files to get some of this info, but I'd still have no way of activating mods...

Could be very interesting... Thoughts?

Smart idea - and certainly do-able.

It wouldn't be hard to modify JSGME to accept a few command line parameters, such as one for "force" activating mods, one for "force" deactivating mods, one for toggling a mod's state (meh, might be used I guess), and one for running in silent mode. As only one instance of each copy of JSGME can run at a time, you could call it without caring if it is already open and let JSGME manage the mechanics. All you'd need to do was know the mod path, and from there you could derive the related JSGME path, and call JSGME with the mod folder name and the relevant switch.

JSGME could post a message or somesuch advising whether success or fail.

That's an initial thought anyway. I'll have a play after I get a few other things out of the way.

I have enough work myself so no hurry for me ;)

Just some more thoughts:
- Whenever a user saves in the mods folder with S3D, a post-save check for the SH-exe can determine the root game path. That way I have all the info needed to spawn JSGME.
- I guess it would be wise to prevent full automatic mod (un)install if the mod sits somewhere in the middle of the list, as to prevent unwanted mods being (de)activated. Maybe a popup confirmation in JSGME (edit: I think it already does??)...
- I could send along the window handle to receive a postback using SendNotifyMessage (PostMessage/SendMessage can cause problems on Vista across processes). We can register a message using RegisterWindowMessage using a specific string (aka WM_JSGME_ACTIVATE, with lparam 0 or 1). The only problem I see here is S3D can't query state if it reloads a mod/file.

Regarding the last point, I am thinking maybe only an activate/reactivate command is needed, and not deactivate. That avoids the need to post state info back. Let the user decide in JSGME whether or not to deactivate a mod, and not in S3D (which doesn't make sense anyway, that's what JSGME is for!).

Anyway, just let it boil for a while :smug:

Something I've been meaning to ask:

Why does JSGME copy the files when it installs a mod, instead of just moving them? Moving files on the same hard drive is much faster, and moving requires only about half the space, even when you factor in the backed up files on installation.

Hi JS awesome Mod enabler i have been using it since day one.......i,m a little confused though...my version which i have been usinf for thr last 3 months or so already says 2.0.1 when i treid to down load it agian it just said file already down loaded do you wish to over right.

then i pressed update in youe mode tool and it said i have the latest version....is this so or do i need to DL it agian.

Yes, I'm well aware of that. There are, however, some fundamental reasons for the copy approach, not the least being file version integrity control.

And before someone says "hard linking will do everything and more", pls consider the limitations of such approach balanced against the average user competence level.

You did notice that this is quite an old thread? ;)

Sorry about that, didn't intend to confuse anyone, but I didn't think my request warranted a new thread :arrgh!:

See, that's why fundamental/must-have stuff should be stickied. From what ungodly depths was this thread unburied? :D

:up: I like it here, means less places for me to look when I forget what I had to do. :doh:

Sorry JS how dumb am i :oops: :D
This tool is a must have for all gammers.........great work:up:

:oops: Man am i so dumb.......
Great tool every one must have this.....................keep up the great work JS:up:

OK, with development work on SH3Cmdr now pretty much over, I've decided to go back to work on JSGME; there's a few features that I want to add.

So while I take a break from programming and actually play SH3 (and whenever I can get the UBM, SH4), pls feel free to post your wishes, comments or suggestions here.

I won't respond to them - I'll just add the useful ideas to my "to do" list.

JScones,
JGSME should be able to recognize if a mod also need changes via JTxE. (maybe checking if there is a ini_mods folder inside the mod ????)

Before deinstalling the mod, JGSME should popup a message that the user has first to deinstall the JtxE changes before deinstalling via JGSME.

The idea behind is, that through JTxE the paths to dds files can be changed. This give the modders the possibility to made extra graphic files for their mods. JGSME will be able to add the extra files to the folders.
Deinstalling this files only with JGSME, will let SH4 search the deinstalled files an break with a failure message.

With JTxE i cannot take influence at the deinstalling order - only JGSME can take care of it. Therefore plaese be so kind and let us find together a solution.

Thanks and sorry for my bad english.

Any thoughts to accepting a compressed zip or 7zip format as well as the expanded directories? Some of those mod folders are quite large uncompressed.