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]

Political discussion or not: it's not me who questioned the technical justifications behind someone's statements. (In other words, accused others with "prejudice", "marking mods incompatible that they don't like", and so on.) And, of course, spreading malicious lies.

As for your (rather vague) mod development guidelines, they're loaded with subjective terms like "precise" and "proper." You can argue for or against any mod fulfilling or failing those criteria, based on your personal biases. (And by your own admission, even you "haven't yet fully specified the exact details of their application".)

Yes, "precise" and "proper" are subjective terms, which mean I can imagine how they could be improved, i.e. design could be more "precise", and verification could be much more "proper" than it is in case of several mods. The fact they're not fully specified just means I haven't written any complete specifications, descriptions and/or guides. It does not mean that I don't know what concrete details should be changed and developed. Otherwise I wouldn't have brought it up at all. And you can see that I said I didn't expect anyone to know them. They were just presented as a fact, and I don't expect e.g. G3FP developers to follow them -- exactly because of what you said, i.e. that they aren't well-specified. I just presented them as a fact, as something that is present. On the other hand, the meaning of other points (continous documentation not just in TP2, drawing attention to interfaces and dependencies, etc.) are obvious to everyone.

Any large program or mod will have bugs. If not, perhaps few people are using it. Maybe it's been around longer. Maybe, just maybe it was better designed, but the fact fewer bugs get reported (if that's true) isn't necessarily prima facie evidence of that.

Exactly. That is why proper design and implementation is required. ("Following certain guidelines.") While I didn't want to detail many of them, I did describe one of the most important ones several times. It's about drawing attention to possible data-level interaction. In other words, what dependencies to use, and how. In case it's still not clear: proper design decreases the probability of bugs that you make during implementation. You could ask again: what is "good" design? Well, one aspect was given already: draw greater attention to organize how your mod applies its changes on the game -- this is strongly related to dependencies. (So if it's *better designed* it WILL have *fewer bugs*.)

If I decide to change a minute detail, like a line in a script of a single creature, and modder X somewhere, perhaps years ago in some mega-mod, has already done this or done something opposing, well right away we have a conflict. We don't need to delete some key or other "dependency" to get that.

Exactly. Two points:
(1) Data-level dependencies are only one of the things that determine compatibility. (There are object-level interactions as well, for example.) However, since it doesn't require a too skilled modder to understand the importance of dependencies and design his/her mod according to it (and since such things can be examined much more easily than object-level interactions), this is really a must for every mod.
(2) Exactly as you say: even a minute detail can make a difference. (I think I've written "one bit" as an example in that very long post.) This is exactly where the design process has enormous role. Simply because good design (or, more specifically in our concrete case: good solutions to apply changes, few dependencies) allows the "easy to change" principle of software technology to be better applied. (Again, understanding that in details isn't a must. However, here is a simplified, "common-sense" explanation for those who are interested: if there are few dependencies, the probability that other mods will collide with yours is smaller! In other words, the chance that another mod uses the same dependency as yours is smaller -- because you have less total dependencies!). This has been practically proved in industry as well. To simplify it in our concrete case: try to have exactly as many dependencies as your mod needs. If it's too high or another mod has many same dependencies (often, this is the case for "conceptual incompatibilies"), they shouldn't be played together to avoid constant collision and problems. (Consequently, a fixpack which can't be incompatible with most mods should have as few dependencies as possible -- while also fulfilling its goal, of course, i.e. fixing real problems.) I hope that now you see that future bugs aren't completely random or unavoidable: their chance can be decreased.

One obvious question springs to my mind. Why not just install the Fixpack and develop your mod based on its adjusted dependencies, rather than develop your mod on an unfixed game and claim that the Fixpack 'breaks' your mod? I know you have probably got loads of arguments against this approach, but one could produce just as many for it as well.

Let me tell some counter-arguments then, using G3FP's case.

(1) As I've said, it's really suboptimal that a modder has to override the changes of a fixpack in so many cases. Sometimes, very many lines of WeiDU code may be required. And at each new release of the fixpack, check what has changed in it (because "new fixes are added to each release"), and which of the (probably subjective) "fixes" may break the mod. Beside the principle itself ("fixing a fixpack's fixes???"), there are two problems here:
(a) Modders who support fixpack are obliged to check FP's every bit (which is a LOT of time) each time a new FP version is released. Or they just wait for a player bug report -- more comfortable, but we at BWL don't favour this solution.
(b) Modders who are less skilled in WeiDU are in trouble, because some of the fixes to override G3FP's fixes may require advanced code. I know G3FP and other people who are more skilled in WeiDU might help, but eventually the modder has to create his own adjustment code. I know it's nice to motivate more modders to improve their WeiDU skills, but some modders just don't have time or energy. It's very unfair to expect from a modder to learn such WeiDU things which normally he/she would never need in his/her mod. (And it's "funny" what we can see in that thread I remember in G3FP forum -- "I hate this FIX" -- that is supposed to deal with negating FP's fixes in mods. The only thing it can offer to these less skilled modders is a cynical statement: "Well, that's okay too. You can play Baldur's Gate 2 without even the official patch if you want to to - the game will crash more, and lag more, and have more chances to muck up, but if you're getting by without it, then go have fun." Which isn't just arrogant, it also contains misleading information***)

(2) As we know, very many users (including myself) believe that G3FP contains many ambigious or subjective changes (and it introduces them as "fixes"). How can we expect a modder to use a fixpack as a basis for his/her mod, if he or she can't agree with several changes of that fixpack? Should he learn all required WeiDU skills and spend hours to find and negate these problems?! And as others have already said, G3FP is (interestingly) a very dynamic project, which changes. How can a mod be based on something that constantly changes in an unpredictible way?

(3) Generally, it's reasonable to expect that many modders -- especially starter modders -- will develop their mods based on the original game. All or most of us have played the game in its original form many times. That is what we know. Replacing everything with an unofficial gigantic "fixpack" is possible, but how can we get familiar with the immensely high number of changed game aspects? It's reasonable to believe that when creating the mod, the modder naturally has the pictures of the original game in his or her mind. I don't think a fixpack should override compatibility conditions of all mods with the original game, to such a giant extent.


To sum up:
1. G3FP contains a lot of "fixes" that are not fixes at all, rather subjective changes. As I've detailed it in the very long post, the arguments are very problematic: such as guessing developer intent, finding "illogical" things. So this is the huge conceptual problem here.
2. Unfortunately, G3FP affects very many potential dependencies, as a natural consequence of the lots of changes ("fixes"). So the subjective, ambigious "fixes" also greatly increase the probability of technical incompatibilities !!!
3. There is no "proper verification" (which would at least decrease the number of bugs caused by the too many affected game elements and dependencies). As Sikret has said, G3FP developers mistake players for testers. Sure, some players like their names to be carved to Credits, but again, others don't feel they should be testers and they won't install G3FP. The developers of G3FP focus on code too much, they are trying to guess many incompatibilities based on code, *without* practical tests. Sure, it's impossible to test everything, but due to the huge number of miscellaneous questionable changes ("fixes"), even it's hard to make typical, well-defined tests. But no problem, players will be good testers!


*** The aforementioned quote from the thread in G3FP forum ("I hate this FIX") implies that G3FP fixes so crucial bugs that without its use, the player will *surely* encounter serious bugs. This is nothing else than ridiculous propaganda. And blackmail as well. To sum up, it says: If you don't want or have no possibility to improve your programming and WeiDU skills, then undertake its consequences: your game WILL crash and will have bugs!. What sort of behaviour is this?

It's incredibly funny that jastey (one of the greatest defenders and representatives of G3FP), exactly jastey, did NOT notice any bug when playing Baldur's Gate II long ago:
jastey's post
Don't get me wrong: I don't want to say there are no critical bugs, but how can anyone say nowadays that all those new, ambigious "fixes" of G3 Fixpack are crucial to avoid bugs?! Generally, how can anyone believe that the game still has so many "bugs" to be "fixed" that it justifies the mandatory presence of questionable, arbitrary "fixes"?! (Which, on top of it all, may cause bugs as well! A fixpack which causes bugs.......!)

[Gort]

The point which you (both) missed is that many of the modifications the BG2 fixpack applies to the game are not really "bugfixes" at all (despite what the fixpackers claim); they are rather subjective arbitrary (sometimes cosmetic) tweaks.

and you seem to miss the second part of my post.

(And no, we don't develop our mods on an 'unfixed' game; we use Baldurdash as the base and we fix whatever other bugs baldurdash has not fixed in our own mods.)

you see, not everyone uses your mods. Should all players who don't use them continue playing with bugs?


Baronius,
1 - This is a subjective opinion, nothing more. There are changes in bg2fixpack that I personally do not consider to be bugfixes, as well as there are such changes in baldurdash-weidu. Now we have 3 sides - badurdash developers, bg2fixpack developers, and me. Who is right?
2 - as I have said, potential dependencies should not matter for a fixpack. Even if all the mods would use some buggy creature - a fixpack should fix it, because it's a fixpack. Question "is this creature really buggy or not?" is another question, and there is no objective opinion about it.
3 - cannot say anything, I don't know how things are tested and introduced in bg2fixpack.

[Valiant]

you see, not everyone uses your mods. Should all players who don't use them continue playing with bugs?

No, they shouldn´t, they can install all fixpacks they want and play "fixed" and "cosmetically changed" game, but in that case the whole discussion is pointless I believe. Nobody is forced to use our mods.