THE CONFLICT THREAD

[Targor Avelany]

I think that is the kind of the CTD volodya was talking about: the CTDs caused by mods that are not visually (lets say in JSGME) affect each other, but somehow do create major problems for each other, causing all kinds of problems.

I don't play at the moment for two reasons: one is the time, second: I don't want to sit and figure out everything the way I like and not break things. I would use just sober's list, but my computer will die; plus, I love using voice recognition, and it hasn't been updated for a very while.

[gap]

Originally Posted by Targor Avelany

...mods that are not visually (lets say in JSGME) affect each other, but somehow do create major problems for each other...

There is at least one way that this can happen:

let's say that some settings of the mod A rely on a group of settings in another file, be them stock settings or settings from a second mod (B) that the said mod A is based on. The author of A, assumes that the essential settings are already in game, and he doesn't include in his package the files containing them.

A third mod, let's call it C, might remove/change the aforementioned settings. Note that, though conflicting with B, C might be designed to work well with the latter. Nonetheless it doesn't take into account A. result: despite the fact that it is not overwriting any of its files, C will break A

There are also cases where a mod can mask an incompatibility between two other mods. A practical example: in sobers' mega mod, OHII follows FXU. Their relative order didn't matter before FXU 0.0.22, because their conflicting files were identical, but now some new settings which were added to FXU are not present in OH. This is not a big problem anyway, because RSD, which is enabled on top of them, ovewrites the two mods, restoring the missing settings. But try removing RSD without switching OH's and FXU's relative orders, and you will transform a stable mod list into a buggy one.

[Targor Avelany]

Originally Posted by gap

There is at least one way that this can happen:

let's say that some settings of the mod A rely on a group of settings in another file, be them stock settings or settings from a second mod (B) that the said mod A is based on. The author of A, assumes that the essential settings are already in game, and he doesn't include the files containing them in his package

A third mod, let's call it C, might remove/change the aforementioned settings. Note that, though conflicting with B, C might be designed to work well with the latter. Nonetheless it doesn't take into account A. result: despite the fact that it is not overwriting any of its files, C will break A

There are also cases where a mod can mask an incompatibility between two other mods. A practical example: in sobers' mega mod, OHII follows FXU. Their relative order didn't matter before FXU 0.0.22, because their conflicting files were identical, but now some new settings which were added to FXU are not present in OH. This is not a big problem anyway, because RSD, which is enabled on top of them, ovewrites the two mods, restoring the missing settings. But try removing RSD without switching OH's and FXU's relative orders, and you will transform a stable mod list into a buggy one.

Oh, believe me, I understand the principle It doesn't make it any less tiring to figure it out because realistically the only way to do it is to do it by trial and error.

[volodya61]

Originally Posted by gap

There is at least one way that this can happen:

let's say that some settings of the mod A rely on a group of settings in another file, be them stock settings or settings from a second mod (B) that the said mod A is based on. The author of A, assumes that the essential settings are already in game, and he doesn't include in his package the files containing them.

A third mod, let's call it C, might remove/change the aforementioned settings. Note that, though conflicting with B, C might be designed to work well with the latter. Nonetheless it doesn't take into account A. result: despite the fact that it is not overwriting any of its files, C will break A

There are also cases where a mod can mask an incompatibility between two other mods. A practical example: in sobers' mega mod, OHII follows FXU. Their relative order didn't matter before FXU 0.0.22, because their conflicting files were identical, but now some new settings which were added to FXU are not present in OH. This is not a big problem anyway, because RSD, which is enabled on top of them, ovewrites the two mods, restoring the missing settings. But try removing RSD without switching OH's and FXU's relative orders, and you will transform a stable mod list into a buggy one.

Very good explanation.. but.. two examples - Sub Flags and AI Sub Crew.. how these mods may corrupt a mod-list.. settings of these two mods don't overlap with settings of any other mods.. nowhere..

[plj]

They both mess with the models and what happens in/to them.

Originally Posted by volodya61

Very good explanation.. but.. two examples - Sub Flags and AI Sub Crew.. how these mods may corrupt a mod-list.. settings of these two mods don't overlap with settings of any other mods.. nowhere..

They could have ID's that conflict? That has been a bain on modding from SH3 up to and includeing SH5.
ID conflicts have also been shown to be wildly variable! It may take special conditions to cause a crash.
Such as being near Units that have ID clashes.

[lodebeard]

Submarines are stupid and modding is immoral and you guys are all totally stuck up and I wish I had never joined this place

[lodebeard]

Wait... I think I may have posted in the wrong CONFLICT THREAD...

whoops

[gap]

Originally Posted by Targor Avelany

Oh, believe me, I understand the principle It doesn't make it any less tiring to figure it out because realistically the only way to do it is to do it by trial and error.

Well, to some extent one can evaluate the compatibility of two mods from the features they affect and by having a quick look into their respective files, but I agree that the more mods are enabled, the more are their interactions, and the harder is tracking down every potential source of problems.

Originally Posted by volodya61

Very good explanation.. but.. two examples - Sub Flags and AI Sub Crew.. how these mods may corrupt a mod-list.. settings of these two mods don't overlap with settings of any other mods.. nowhere..

Sub flags, in several ways: see this post by me for an example. Dunno about AI sub crew though: never looked into this mod.

Originally Posted by privateer

They could have ID's that conflict? That has been a bain on modding from SH3 up to and includeing SH5.
ID conflicts have also been shown to be wildly variable! It may take special conditions to cause a crash.
Such as being near Units that have ID clashes.

Well said, this could explain some herratic and mysterious crashes.

Nonetheless, we must also consider that a 16-digit hex number can assume values from 0 to 18,446,744,073,709,552,000 lol. Unless we consider human error as a factor, the evenience of randomly duplicated Id's is extremely unlikely

[vdr1981]

Originally Posted by lodebeard

Submarines are stupid and modding is immoral and you guys are all totally stuck up and I wish I had never joined this place

LoL, It's not that kind of "conflict"...

[Trevally.]

Originally Posted by lodebeard

Wait... I think I may have posted in the wrong CONFLICT THREAD...

whoops