Common misbeliefs, with examples Options

[Baronius]

Since much information can be read from incompetent sources that can't be considered credible, we've decided to open this thread, where I will occassionally publish examples, with explanations & facts. Other BWL members might also post here in the future. It will function similarly to a "blog", though I don't think it will be updated too often.

Interesting or surprising parts in posts may be marked with bold.

[Baronius]

Misbelief: "technical incompatibility can always be eliminated"

The expressions "technical incompatibility" and "conceptual incompatibility" could be heard quite often in the past (and probably can be heard in the present too), and certain mod developers have been using them to justify their own development style and methods, to "prove" the superiority of those methods.

Let's see what "technical incompatibility" and "conceptual incompatibility" is supposed to mean.

In brief, it's "conceptual incompatibility" when the concepts of two mods contradict each other (for example, both mods change the major tactical elements of a the same battle). Furthermore, it's also a "conceptual" incompatibility when two mods change the equipped weapons of a main villain -- the villain can't wield four items, it can only wield two (e.g. a sword and a shield, or two swords in two-handed style). Similarly, an item can't have two prices at the same time, so mods which change the price of the same item should be considered "conceptually incompatible".

"Technical incompatibility" should be used when the incompatibility between Infinity Engine mods is the consequence only of technical implementation. It's related to the changes made by the mods and the method used by the mods to apply these changes. It should be used to refer to incompatibilities which can be solved purely by changing on the technical realization, without requiring qualitative/conceptual changes on any of the mod(s).

Unfortunately, certain mod developers started to consider every case as "technical incompatibility" which they could solve by creating some sort of mix of the two mods' content. Most of these cases actually result in changes on the concepts or content of at least one of the mods, but these mod developers have always denied it in such cases -- they pretended not to realize that the changes on the technical implementation also affected the mod's concepts, the mod's model. In other words, they consider two mods compatible if they can create a "working" (= no crash, no freeze) mix of the two mods with technical changes. That is, they conceal the reality behind the "technical changes" -- they can do it, because "conceptual incompatibility" is also eliminated via technical methods (so they use technical methods, and thus call it as a fix for a "technical incompatibility"). In other words, "conceptual incompatibility" is also a type of "technical incompatibility" (and this is what they abuse). Since eliminating conceptual incompatibility requires changes on the content/concepts of at least one of the mods, the "mixed mods" that are created in this way are far from what the original mods (separately) would offer. This results in two major things:
(1) Not all mod developers want to cooperate with those who use this twisted interpretation of "technical incompatibility", i.e. not all mod developers want to allow their mods to be added to such "mixes".
(2) Due to such -- often unthoughtful -- "mixes", the resulting mod combination often becomes buggy. This is because the local changes made on the mods disregarded the global impact they can have on the mod's system as a whole.

For example, such a "mix" can be when there is a tactical battle in a mod, and another mod changes a certain creature of that battle which causes the battle to work in an undesired, faulty way. This is clearly a "conceptual incompatibility", yet certain mod developers would call it "technical incompatibility which elimination doesn't affect the concepts of the mod". They would call it "technical incompatibility" just because they can solve it via "coding" -- for example, they change the code that affects the creature in a way which doesn't break the battle any more. On the other hand, they forget that it still changes the battle, so it works in a different way than the mod that adds the battle requires it. This may even create bugs, because the local changes on the creature of the mod with the tactical battle may have a global impact on the mod as a whole.

To cut a long story short, those certain mod developers who twist "technical incompatibility" in the aforementioned ways actually abuse the fact that these terms ("technical incompatibility", "conceptual incompatibility") cannot be well-defined. They declared their own interpretation as a generally true and mandatory interpretation (ignoring that perhaps not all authors agree with it), and started to use it as a standard to qualify all mods (including other mod developers' works) in terms of compatibility. Thanks to their loud advertisements and self-confidence, they managed to mislead several other mod developers and players (who unconditionally believed/believe all what they said about "compatibility").

Creating such "mixed" mods is similar to mixing all types of food in the same dish, and then eating it. Perhaps you won't become ill or dead after it, but it clearly ruins each food that is included (and would be delicious separately). Of course, in the IE mod development, such a "food mix" may even result in "poison", i.e. it may also create bugs and other serious problems in the game.

It just makes the situation even worse when one of the "components" for the "mixed" mod has a faulty model, a bad design. For example, this is the case for G3 BG2 Fixpack, which has a lot of bugs and a faulty model (despite my repeated requests to its developers, asking them to revise the whole mod). When G3 Fixpack is combined with smaller mods, these bugs appear less often. The bigger (or more complex) the other mod is, the higher the chance a bug will appear.

I don't know exactly what motivates those certain mod developers who use and spread such a twisted interpretation of "technical incompatibility", but I suppose it has to do with the fact that most of their projects are smaller (but possibly very good) mods. They want as many players to install their mods as possible, and in order to do this, they have some sort of urge to make their mods "compatible" with other mods (so more players will choose them, because they're "compatible" mods). Meanwhile, they forget that the "compatibility" they force actually isn't real compatibility, because it can cause bugs and modifies the original content of mods as well.


Example: a big part of mods that have had many bug reports on their forums

I'm sure that very many bug reports are due to compatibility problems, which root in this "compatibility urge". However, since this type of "compatibility" is usually applied among smaller projects (as authors of bigger projects obviously -- and wisely -- refuse to allow their projects to be affected in such ways), usually these bugs can be fixed quickly -- which even increases the traffic and visitor count of the forums of the mods in question (think of "bug report" -- "bugfix" sequences).

On a side note, the fact many such mod "mixes" contain hidden bugs results in an interesting thing: many mods that are advertised as "compatible with many other mods" are actually not compatible with those other mods at all -- because the "mixed" install causes bugs and problems. Sometimes certain users write about Improved Anvil that "it's incompatible with many other mods" and at the same time, state about other mods that they are more compatibility-friendly than Improved Anvil. While, actually it's possible that Improved Anvil is compatible with more mods than those certain other mods! This is because those certain other mods result in bugs when they are installed together with mods which they are supposed to be "compatible" with.


Summary: technical incompatibility is a complex matter, always thoroughly examine any technical changes

Certain mod developers overestimate the significance of "coding", and believe that everything can be solved via "coding". They often forget to examine whether a local change (implemented via "code") can have any global impact in the system of a mod. They often forget that many others might not agree with their interpretation of "technical incompatibility", with the principle that two mods are compatible if some sort of "mix" of them can be created.

Consequently, the statement "certain modders are more concerned about compatibility, while others don't care" is often just a trick of populism, considering that those modders who are "concerned about compatibility" often make buggy mods by mixing more mods without thorough examination of the mods' possible impact on each other. On the other hand, a part of those mod developers who "don't care about compatibility" actually refuses compatibility in most cases because it would result in bugs and problems (this is especially true to complex mods), and not because they don't want to support compatibility with others' mods. Unfortunately, certain mod developers abuse the fact that most players and new modders don't know this (i.e. that compatibility is a complex matter which can't be easily controlled) -- they obscure players and new modders with their misleading statements, and then convince them about their own -- usually oversimplified and popularity-oriented -- notions about compatibility.


Note that when I write about "mixed" mods, I talk about a general phenomenon and developer attitude (which affects several mods, of course), not about the BiG World Project. I decided to emphasize this because the BWP is known to be a combination of many mods, so some readers might accidently misinterpret my words and might believe that I refer to BWP by saying "mixing many mods". I don't. I don't know the system of BWP (but based on what I read, I assume it's a well-tested work, but I can't state that for 100%, as I haven't examined it myself), so I am not implying anything about it in this post.