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).

[Tervadh]

I see a lengthy philosophical or perhaps political discussion in this thread, but no concrete examples of what the problem is, or more importantly, what the solution is.

Why is it, that the g3 no NPC-mods are incompatible with the Blackwyrmlair mod

With which Blackwyrmlair mod exactly?

If you mean that many of the G3 mods are often incompatible with other mods, it's because their development doesn't follow certain important guidelines (for example, that's why the G3 BG2 Fixpack may break almost any other mod in unfortunate cases), and BWL's more complex projects are more sensitive to these crucial aspects.

Can you give an some examples of these guidelines? As an independent modder (i.e., not affiliated with the staff of any particular forum), I'd be interested in seeing these.

Feel free to split this topic off, but I see no reason why something this important to the modding community should be kept to private discussions.

The problems with this are excellently reflected by the G3 Fixpack, which still hasn't been split to two mods up to now -- despite the fact it's now obvious for everyone that it ceases the possibility for mods even to be compatible with the original game by introducing and changing too many dependencies.

Obvious to "everyone"? It's not obvious to me. Some examples of what you're talking about here would help too.

Unfortunately, I don't have the time, and -- after I've seen the lack of interest -- neither intention to provide more material about how you can improve the process. Let's just keep up everything in the way it has been going so far...

This statement conflicts with this one:

However, incompatibility risks between mods could significantly be decreased if modders made a little bit more effort to learn (instead of crazily producing and extending mods).

If you're not going to provide any concrete examples, how are modders supposed to "learn" what you're talking about?

[Baronius]

Feel free to split this topic off, but I see no reason why something this important to the modding community should be kept to private discussions.

Because I've only found deaf ears in the past. I've no time to repeat the same thing again and again. Also, I hope you know that concrete examples only confirm a point, but they aren't sufficient to describe a general problem. Unfortunately, several problems are of general nature. (That is, there may be 2 examples today, and there will be 10 tomorrow. No one knows.)

The problems with this are excellently reflected by the G3 Fixpack, which still hasn't been split to two mods up to now -- despite the fact it's now obvious for everyone that it ceases the possibility for mods even to be compatible with the original game by introducing and changing too many dependencies.

Obvious to "everyone"? It's not obvious to me. Some examples of what you're talking about here would help too.

Jastey already provided a link to my long post, please also read that one. I'll repeat only one important point here:

Dependencies can be area script names, items, stores, and even creature alignments -- practically everything in the game. If a dependency is missing (was removed or changed), entities that refer to it will be broken -- this leads to bugs in most cases. A mod should have exactly as many original game dependencies as it requires. (This may sound trivial, but it's not: UB v15 changes an inn's scriptname for "cosmetic" reasons -- and its readme says it's a fix -- which broke ToD v1, and *still* breaks any mod that uses the original scriptname. So this is an example of an unnecessary change -- it's not required to realize UB's novelties, because UB could use the original script name, even if its name is inconsistent with the area resource name. It's a harmless inconsistency, and "fixing" it breaks mods compatibility with the original game itself.)

A fixpack that is meant to be a standard part of any installation should take much more care. Its primary goal isn't to introduce various novelties, rather to fix unambigious problems. It's nice to identify "illogical" things as well (and other less crucial "problems", "issues"), but it must be done very carefully. Exactly because every change you make in the original game may affect the dependencies of any other mod, and thus possibly break any other mod.

Not all dependencies are of the same type. Some of them are more sensitive cases. For example, *removing* items after a given stage of the game (items that are normally kept in the original game) is a very serious hazard. (Concrete example: Sekolah's Tooth of G3FP broke Improved Anvil. It's now fixed, but there are still many items of the same type removed! What if another mod wants to use any of them?). One of the main points is, fixes (and basically any changes of any mod, not just FP) should be reviewed from dependency aspect as well, and if added, they must be documented on data level as well. (TP2 isn't sufficiently user-friendly as far as self-documentation is concerned.) However, reviewing the changes and reviewing & splitting e.g. G3 FP would require much work, and the authors rather spend their time to fix the continous consequences of these problems (and to identify more "bugs" in the game) -- instead of considering my advice. Of course, it's possible to solve specific issues caused by dependency problems (e.g. by modifying the mod's code, or maybe FP's code), but FP's size has grown so much that now it's uncontrollable from this aspect. If a modder wants to undertake that he or she will fix his/her mod each time G3FP causes a collision, well, he/she is free to do so. (Check the parts of my long post that deal with "fix a fixpack's fix". Isn't it a big strange that mods have to *fix* a *fixpack's* changes to avoid issues?)

Many types of big/complex mods always have a high number of dependencies. Such as Improved Anvil. Since dependencies are the primary things that determine compatibility, it's much harder or impossible to ensure reliable compatibility with other mods in these cases. Sometimes it's best to instruct players to use the mod during different games. Simply because the risk is so serious. (Though players often tolerate bugs that are not so crucial. Please check the relevant part of my long post about why mod authors can't allow "partial compatibility" so easily.)

Consequently, it's annoying when some modders simply ignore our arguments and keep harassing with their "technically compatible code" mania. Compatibility is much more than code. A (technically) good mod is much than good code. If someone cannot or doesn't want to understand all this, at least shouldn't spread false information about mods or keep harassing us. We're open to address specific cases, but sometimes our answer is no -- not because we don't like the other mod, rather because it has a *very* good reason such as high risk due to dependencies.

You asked for guidelines, here are some other that could improve mod development process but I don't expect anyone to know them (even I haven't yet fully specified the exact details of their application): (1) Precise design (2) Continous documentation (3) Proper verification. If you don't mind, I won't detail them. I might write a guide some day, I don't know.

Unfortunately, I don't have the time, and -- after I've seen the lack of interest -- neither intention to provide more material about how you can improve the process. Let's just keep up everything in the way it has been going so far...

This statement conflicts with this one:

However, incompatibility risks between mods could significantly be decreased if modders made a little bit more effort to learn (instead of crazily producing and extending mods).

If you're not going to provide any concrete examples, how are modders supposed to "learn" what you're talking about?

No, they don't conflict. By saying "let's just keep it up", I said that solving problems (such as incompatibilities) should be restricted to the same way as it has been going so far: modders can contact each other to cooperate in specific cases, i.e. to solve issues. (A change could be, for example: I could write a tutorial that would tell more about how these issues could be avoided even before the mod is released. So many of the issues/bugs wouldn't appear at all later. Of course, my long post about G3 Fixpack as well as this post includes such information already, not too much though, but important points.) The point is, many more bugs and problems could be avoided before the release of the mod if those guidelines (e.g. about dependencies, though there are non-technical guidelines as well) were followed. Instead, many modders say that the current situation is perfect, i.e. that "if an incompatibility appears, modders contact each other and solve the issue". Wouldn't it be easier to avoid these bugs even before they appear? For example, G3 FP is still a source of many possible bugs, it's just a question of time when it will cause problems with a new mod.

As for learning, I specifically referred to learning more IE modding (e.g. in a specific field) before making determined judgements. Sometimes certain contributors (e.g. of G3 Fixpack) defend points which they obviously don't understand, just because it was told by their favourite modder. (Concrete example: when IA released, CamDawg brought up an incompatibility issue with Delainy. Of course, without actually testing it in practice -- this is typical to some G3 authors as Sikret has said, i.e. they try to guess many things just by taking a look at the code. The statement was incorrect, i.e. it wasn't incompatible with that part of Delainy at all; even CamDawg admitted it. The point is: at least 4 people -- some of them in a trolling way -- were supporting CamDawg in the discussiion. Jastey was the first who actually sacrificed a little time to try it out in practice. But this wasn't a unique case. IA was attacked countless times by users -- including modders -- who have never tried it and some of them apparently knows much less about modding than Sikret, yet their posting style reflects "I'm the man". Examine and study a problem first, before you undertake to make a judgement!) Similarly, some modders just accept the word of others unconditionally, without actually doing own research. (In many cases, this would be possible, yet they don't do it. And this can lead to bugs in their mods too.)


In case it's still not clear:

I don't want to force anyone to make mods the way I recommend. All I suggested is understanding that the motivations behind certain decisions of BWL modders have valid theoretical and technical roots. Or, if someone wants to close his or her eyes and ignore what we say, then at least peace should be kept. (Show me one BWL modder who has made such comments about others and others' work as TheBigg, Nythrun, seanas, MajorTomSawyer, Drew etc. does/did. Many of the statements were lies. Not exaggerations. Lies. Is this really needed, ladies and gentlemen?)