Compatibility of TS v6.11, and general problems, [Topic split by Vlad, move by Baronius] Options

[cmorgan]

Currently reviewing TS v6.11 code alongside DR code to look for what could be causing hassles. ETA on summary is 6 weeks unless I am sidetracked (plenty of stuff going on) - please feel free to drop off specific problems on G3 or PPG or SHS boards.

(IA compatibility is a completely different question, please see the readme in that mod for more information).

While each of us in the IE community are allowed their own opinions, I think a constructive way of addressing those questions would to be to go to the NPC mod makers in question, and ask the same question. My current Tutu and BG games run with a large mod loadout for testing, and they all work extremely well, including several BWL mods (TGCep1 and Herbs and potions, and Jastey's Slime Quest on Tutu). At SHS, there is a section of MegaModders who successfully handle various versions of BP/BGT/etc., incorporating TS and NEJ, etc, on the same installs as many other NPCs from PPG and G3, et al.

I understand the frustration of two opposing philosophies of modding, but I am afraid that the choice of words indicating that development of G3 mods makes them widely incompatible is neither accurate nor fair. Nor is the development process a short one; widespread testing among several platforms, with anywhere between a handful of beta testers and an entire set of 12 or so folks specifically providing testing and feedback (depending on the mod, of course). Cooperation among teams of coders and an open policy of producing joint public code and testing it, then writing up tutorials on it and updating it with feedback allows modders access to many helpers, making coding review a strong and vibrant process.

The way to get folks to be able to identify the specific incompatibilities and give information on tracking the difficulty down is to experience the problem, get a savegame, and write up what the specific dialogue/action was that was taken. Then the modders in question can attempt to isolate and fix whatever is causing the trouble (assuming they wish to be friendly enough to help eachother out).

[Baronius]

Further for some modders it's quite funny to read these allegations at BWL, that hosts incompatible mod(s)

And, you see, this is exactly why some BWL modders (including me) refuse to "cooperate" sometimes. (You present incomp. as something negative, yet it's a natural consequence of certain things.) This "incompatible mods" idiocy is exactly what new (but not just new) modders should not believe without conditions, and do their own research. Unfortunately, way too many modders have believed that idiocy already.

If "compatibility" causes serious risks in a specific case, it should NOT be forced -- that's the point. If playing two mods in different games is the best for players (because there will be many less bugs), then it's good, and not bad. But, of course, those who only make small (and probably very good!) mods and can't accept that some players will prefer a bigger mod, will come with this "incompatible mods" idiocy when the author of the bigger mod doesn't want to give up concepts in his mod to ensure "technical compatibility", let alone mods such as G3FP which break compatibility with the original game (and as such, automatically mean risk for all other released and future mods). Sometimes "conceptual" and "technical" aspects overlap. E.g., when there is a very high number of dependencies of the same type, sometimes it's better to play the mods in different games, even if they aren't conceptually incompatible.

Has anyone been thinking about why IA works seamlessly and has had a negligible number of bugs compared to its size & complexity? Not just due to the proper verification, but also because it precisely handles compatibility!

Ensuring compatibility between two mods in a *specific* case does NOT necessarily guarantee that problems of the same nature won't appear between the mods later. Simply because *specific* technical changes address *specific* issues. If the general source of problems still remains present, it makes little sense to keep fixing the problems forever. Because it's *sure* that there will problems all the time.

Should ALL present and future mods who use that tavern in City Gates contain a check for Unfinished Business?! (Instead of UB following the guideline about dependencies...) Wouldn't it be easier to write reliable, as "dependency-proof" mods as possible (so other mods wouldn't need to fix what we messed up) ?

Sometimes forcing two mods to be played together (forcing "compatibility") will do more bad than good. When the problem can't be solved neither avoided (e.g. in case of a fixpack which a player always installs), one of the mods (the fixpack) must be designed and implemented according to very strict guidelines to minimize the general risks!