A question for experienced modders

[TDK1044]

I'm a real simpleton when it comes to mods.....I can download them, extract them, install them and uninstall them using JSGME, but that's about the limit of my mod knowledge.

So, to those of you with consideranle knowledge in this area, please forgive the question. What I want to know is if I'm running a large mod like TM, and I go to add a small mod and I get the message that the file or files I'm seeking to mod have already been modded by TM, if I go ahead and install the small mod, is that OK because all I've changed is TM? Or, by altering TM, when I disable the TM mod and the small mod, is there now a file corruption issue relative to the stock game?

I ask because I got that message when installing ROW mods on top of TM 1.6.5, but Dave said that was fine. Indeed it was fine, but I'm curious if that would always be the case, or whether as a general rule if you get that 'files have already been modded' message you should not proceed.

[Seeadler]

What I want to know is if I'm running a large mod like TM, and I go to add a small mod and I get the message that the file or files I'm seeking to mod have already been modded by TM, if I go ahead and install the small mod, is that OK because all I've changed is TM?
it's only correct for the files you've got the message of


when I disable the TM mod and the small mod, is there now a file corruption issue relative to the stock game?
not if you disable in install order
example:

1. stock game
2. enablel mod1 -> mod2 -> mod3
3. disabel mod3 -> mod2 -> mod1
4 stock game

[Fincuan]

The newest version of JSGME doesn't even allow you to disable mods in the wrong order, so there goes that too :) JSGME backs up every files it has to replace, even if it has already been modded. For example if you were to first enable TMaru 1.7.1, and then ROW camera mod(both modify cameras.dat), you would get two backups of the file in MODS/!BACKUP: one backup of the stock cameras.dat, and one of the TMaru one.

[Digital_Trucker]

Yep, it won't let you do it wrong if the same file has been overwritten 7 times or more:rotfl: When ROW was in the testing stages and Leo would toss out new stuff, all I did was put the new stuff in the mods folder and let it overwrite what was already there. At one point I had some files that had been replaced seven times and JSGME (hats off, mr. scones) would not let me disable the original mod until I had disabled each of the latter 6 in the reverse order of installation.

[Ducimus]

As a general rule, if you do not understand the file that is conflicting, then you should not enable the conflicting mod.

The exception to this rule, is 90% of ROW. Since all of it, except for the roll and shake mod is 100% compatiable (cause i changed some variables here or there). ROW, has become, the modular graphical package for all the other large mods use that concentrate on gameplay - and i totally dig this. It allows mods to focus on what they do best and work collaberatly rather then compedatively.

The worst that can happen by running row over TM, is a minor adjustments here or there not being present, but it won't break the mod.

Where things get dicey, is when you start talking about core files that deal with anything not related to 3d graphics or skins. For a mod to be compatible in this regard generally speaking, someone has to go through both mods, see what changes were being made in both, and make it so they coexist harmoniously, which isnt an easy thiing to do.

[AVGWarhawk]

You have to remember that what is loaded up behind the mods will change the previous mod. For example, I tried a mod that had DC and some sound changes. When I placed it in last it said it was overwriting ROW sounds. Well, I happen to like the ROW sound file. So I uninstalled the new DC mod and ROW sounds. Reintalled the DC mod and then added the ROW sound mod right behind it. Bingo, the ROW overwritten the DC mod sounds and I had what I wanted. You just have to watch major changes when the overwritten warning pops up. Textures and sound are no big deal. Just have to watch sensor changes and such. For example, I have RFB but wanted to try Peto's new longer evasion mod. I loaded it up behind RFB knowing it would change what RFB had to offer in the sensor file. This is the only file it changed and was harmless as the new file was making the DD sensor just a bit better. No issues.

Ultimately each mod in succession of loading will control the game and experience.

[TDK1044]

Now that JSGME is idiot proof it looks like I'm fine! Thanks for the input Guys.

[DrBeast]

I have a feeling, however, that JSGME is case-sensitive. For example: mod A has a file structure of data\whatever, mod B has a file structure of Data\whatever (notice the upper-case D here?). In that case, JSGME will not issue a warning, nor keep a back-up of the files from mod A. Have you guys noticed this? As a rule of thumb, I ALWAYS look up the file structure of the mods and change lower-case to upper-case and vice versa to comply with core game Data structure.

[skwasjer]

If you are sure about this, you should inform JScones about it :hmm:

Have you actually verified this or is it just a 'feeling' as you say?

[CapnScurvy]

Guy's I have a question regarding the compatibility of JSGME with JTxE by jimimadrid. This may switch us into a different gear but I think were still going down the same path. Jimimadrid's .ini Text Enabler can be found at this thread http://www.subsim.com/radioroom/showthread.php?t=123521

The ability to change just small pieces of .txt, .ini, .cfg files without overlaying the entire file, I think is a great prospect. As long as your not rewriting anothers change to the same file, the different pieces will be brought together changing the stock file from multiple sources. I have been trying JTxE with several changes to the menu_1024_768.ini and it works great. A problem that had occuried, developed when I removed JSGME (which holds the .ini mods folder for JTxE) before the JTxE part. Two files appeared in the JTxE program, on the right the mod I had made for an .ini file and on the left the .bak of the same file that JSGME had just put in when I closed it first. The mod could not be uninstalled until the .bak file was removed from the left "Available Mods" side. JTxE makes a loglist.txt file and by clearing it the .bak file was removed allowing the uninstall of the mod. I have brought this to jimimadrids attention and he has been working on it for a couple of days. He told me I have been the only one that has given him any feedback on JTxE. Well, I'm not the sharpest knife in the drawer when it comes to this, so I don't know if what I explained to him put him onto the right track. So any information on the subject could be helpful.

[DrBeast]

If you are sure about this, you should inform JScones about it :hmm:

Have you actually verified this or is it just a 'feeling' as you say?

Verified, though I could do a couple more tests to nail it for sure. Will do as soon as I get home and notify JScones tomorrow if I'm correct.