JGSME feature request think about.

[TigerKatziTatzi]

Since I became a member of a bigger mod, I've seen lot of problems by user getting mods installed or the update/ patch to a mod.

We are recommending users to use JGSME for installation of mods. But when an update or patch came out, they need to deinstall the mod first, copying the new files into the mod folder and installing it again to have latest version/ patch level enabled, without having serveral install-levels of one mod.
But there are also a lot of ppl which aren't using JGSME and doing everything by themself or copying it direct into the sh3 install folder, everyone like he wants. Therefore I'm writting an app. which will install our mod/updates/patches to sh3 direct, just to help users who aren't firm with handling JGSME.

But I was thinking about users who are using JGSME and how we can make it easier for them to handle updates/ patches. My idea to this was if it would be possible to have a 'update' function included to JGSME which would do the deinstall/ re-install after an update/ patching ?

This could be based on a readout of an 'version.ini' in the toplevel directory of a mod.
This would include also that all mods starting to include this 'version.ini' file.


What do you think about it ?


Greetz TKT

[JScones]

Originally Posted by TigerKatziTatzi

Therefore I'm writting an app. which will install our mod/updates/patches to sh3 direct, just to help users who aren't firm with handling JGSME.

How's that going to provide benefit over simply unzipping the mod straight into SH3? Old files will be updated with new files anyway.

Originally Posted by TigerKatziTatzi

But I was thinking about users who are using JGSME and how we can make it easier for them to handle updates/ patches. My idea to this was if it would be possible to have a 'update' function included to JGSME which would do the deinstall/ re-install after an update/ patching ?

This could be based on a readout of an 'version.ini' in the toplevel directory of a mod.
This would include also that all mods starting to include this 'version.ini' file.

Version control and file integrity will be the killer. Personally, I don't see the benefit. Currently, all JSGME users need to do to update a mod is:
- disable current version of mod
- unzip new version of mod over old version in JSGME MODS\<ModName> folder, or unzip to a new MODS\<ModName> folder (based on mod developer's instructions)
- re-enable via JSGME

What you're proposing is for JSGME to disable, then patch, and then re-enable automatically, but the files it needs to patch in still have to be unzipped somewhere. So getting users to unzip into a "temp" folder provides no benefits over getting them to unzip straight into either an existing, or new, JSGME MODS folder. And JSGME will still need to disable and enable all dependant mods in order to maintain file version integrity...too messy for my liking.

I see this as more confusing for users and more frustrating for mod developers.

Anyway, large mod developers can overcome the whole issue by providing a robust installation routine which automatically provides the ability for users to install the mod either straight into SH3 or JSGME.

[TigerKatziTatzi]

guess u got me wrong.

everything u'd said is correct. the unzip and copy procedure needs to be done by the user. but will be done for our mod only by an app in near future.

and they do so. but they forget often to deinstall first and install the updated mod again and asking then for support why it isn'T working.

i was thinking about like a proofing for current install version of mod ( when jgsme is been started). something like u do allready with files which has been modified by other mods when installing a new mod.

anyways, was just a thought to help n00bs a little bit more.



greetz TKT

[JScones]

Now I'm prolly more confused.

Anyway, if you are writing an install app for your mod, then perhaps you can:

1. Check for the presence of a \SH3 Commander\!BACKUP\data folder. If one is present, tell user to open SH3Cmdr, ROLLBACK SH3Cmdr and exit SH3Cmdr (or simply just provide the prompt anyway).
2. Open \SilentHunterIII\MODS\JSGME.ini and search for the presence of your mod's name under the [MODS] section. If found, tell user to open JSGME, disable mod and then exit JSGME (or again, just provide the prompt anyway);
3. At the end of your routine, assuming user has installed into JSGME, tell them to open JSGME, re-enable the mod, and exit JSGME.

BTW, this is a method which I am currently testing with another large mod.

[TigerKatziTatzi]

thx for details.

[Tikigod]

Originally Posted by JScones

Anyway, large mod developers can overcome the whole issue by providing a robust installation routine which automatically provides the ability for users to install the mod either straight into SH3 or JSGME.

Well from what I understand the point of putting together super mod (like grey wolves) was to create a simple one time install for the average joe that doesn't want to use jsgme or mess with editing and configuring mods. It wasn't made to be a standard install for the intention of jsgme users to add additional mods.

That was my main disappointment with Grey Wolves that it it didn't come in a modular format for those of us that use jsgme to keep mods up to date when new mods come out. But, like it says in documentation the purpose of it was to create a simple install so everyone has a chance to enjoy all the popular mods that are currently out there. The downside to this is that it is dated. Because as new mods come out you will always have this problem as you are describing of having to back track and fix edits, config files, etc which is why most solutions even for the installation of grey wolves is to start with a "fresh" vanilla install.

The issue isn't jsgme to change its ways....the issue is for super mod makers if they intend to cater to jsgme users is to break it up into a modular format. So, when a new mod or alternative mod comes out that changes a particular behavior of something already installed it can then be kicked back to the vanilla install to put in the new mod.

The standard should be JSGME modules and the standard vanilla sh3 installation. Not, a supermod like Greywolves. Greywolves can't be a standard because it has to much extra stuff that is not needed. A standard install is like RUB where it only changes a behavior of one particular aspect of the game and nothing else or a collection of fixes that patched broken behaviors...a standard should be a unofficial patch like captain america's gauge fix...these are standards...because they don't need to be changed later....not compilations of textures, music, campaigns, user interfaces, map tools, and other extra stuff that will be changed consistently by each personal preference anyway....these should only be offered as modules as a standard by supermod makers so they can be swapped easily with jsgme based on the individual tastes...

My biggest problem I have with mod makers is they don't go by standards. You always see somone add extra features or fixes they like in addition to the mod the user origianlly wanted to install. Like if you wanted to install a ship it would add some fix to a plane or to the weather....something completelty unrelated...just because the mod maker thought this was a nice fix based on his assumptions that his install is what everyone is using.....this stuff needs to be broken up into modules so as they outdate or becoem more advanced they can easily be replaced...plane and simple...that way the problem and instructions can simply be written for the configuration of that specific module and not the 4 different uber mods people are using as supposed standards...people don't have time to write lengthy install instructions for what various supermod needs...if supermods are going to modified they need to be broken up into a modular format that can easily be replaced.