Quote:
|
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.
Quote:
|
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.