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: "good 'coding' with WeiDU = bug-free mod"

One of the misbeliefs is that the well-written WeiDU installation code of a mod can guarantee compatibility with other mods, and will not result in bugs. This is not true. "Coding" is just one (important) part of mod development. It's just a way to express our intentions, i.e. to implement our changes for the platform. If our model is faulty, it will result in a buggy game or incompatibility, no matter how good our "coding" is. To sum up, an incorrect model or methodology can easily ruin a mod's quality, because the code will (correctly) implement a faulty model. Models of mods should meet general requirements, not just arbitrary and specific ones.


Example: a fixpack's change to the TorGal file

In incompetent hands, code can cause a lot of problems. It's the example of incorrect methodology, where the code follows a faulty approach. I have drawn the attention of the G3 BG2 Fixpack developers several times that a generally usable model is required, because their current model is strongly limited and faulty. They didn't listen to me. When I say that a generally workable model is needed, I refer to the matter of the dynamic environment that IE mods have to face. That is, you can't build a fixpack (that is meant to be a standard part of all installations) according to specific, arbitrary and unverified criteria. Notice the contradiction: part of all installations vs. specific criteria. A fixpack should meet general criteria (i.e. it should assume that a lot of different mods will be installed together with it, hence the dynamic environment), and not some arbitrary specific criteria set by the fixpack's developers.

Such faulty models practically always result in serious bugs. One of such bugs is when BG2's TorGal (modified by the G3 Fixpack) appears in a multi-mod environment, and breaks other mods (becomes unkillable). When G3 BG2 Fixpack isn't installed, this bug doesn't appear.

In the past, I was told that it's a question of how we define "bug". The serious TorGal problem of G3 Fixpack fits my definition of "bug", but my definition isn't as important as common sense. "Does the change of G3 Fixpack break another mod?" is a simple question. If the answer is "yes", common sense would say: this is a bug, because it causes a problem that it shouldn't (because it's avoidable with a correct model).

The worst thing is that such fixpack changes cause the bug to appear in another mod, so it will be misleading to both players and mod developers. They will believe it's caused by another mod (and will uninstall that mod) and not the G3 Fixpack, and when they uninstall the third-party mod, the bug will disappear. It will disappear because G3 Fixpack cannot break the mod because the mod is uninstalled (but, of course, the player will believe that the uninstalled mod caused the problem, because the uninstallation caused the bug to disappear from the game). You can read about subtle/hidden bugs here.

Back to the TorGal bug caused by G3 Fixpack (which is supposed to apply a fix on TorGal instead of creating a bug), this player report is a good example when it's not known that the G3 Fixpack caused the bug. It remains hidden from players and mod developers. The topic linked above also proves what I said about the importance of common sense: as someone says there, "it's a common bug". This proves that players also consider such things as bugs (regardless of how mod developers define 'bug'), and it also perfectly presents how a common misbelief is created.

A common misbelief indeed. Because the "non-dying TorGal" was not a "common bug" until G3 Fixpack added it as a bug. This is a good example how a mod, based on a faulty model but with a powerful marketing and propaganda, can mislead lots of players. Lots of players believe it's a "common bug", yet it wasn't present before G3 Fixpack anywhere. For example, "somehow" it doesn't appear on Baldurdash-based mod platforms (such as Baldurdash+Improved Anvil).

The topic linked above about the bug added by G3 Fixpack is dated 10th March 2008, but such bug reports certainly appear for other players too, e.g. this bug report appeared on 2nd August 2008. The situation is usually the same: the player doesn't know that the bug is actually caused by G3 BG2 Fixpack, and mod developers who give their name to support G3 BG2 Fixpack despite its severe technical deficiencies just mislead these players even more.

However, all these statements would make no sense without a proof. So let's examine the relevant G3 BG2 Fixpack installation code specific to TorGal:

// add monhp1 item to trolls to prevent death; assign script to force transformation to dead form at low HP
COPY_EXISTING ~torgal.cre~ ~override~
ADD_CRE_ITEM ~monhp1~ #0 #0 #0 ~NONE~ ~AMULET~

This adds the "amulet" to TorGal which prevents him from dying due to zero HP. One could say now: "OK, but other trolls in the game also have this ability, and those abilities don't create bugs!" Indeed, because they form an integral part of the game, and mods created by mod developers are aware of this fact. That is, it's a natural, non-arbitrary requirement. On the other hand, TorGal isn't like other trolls in the original game, and G3 BG2 Fixpack makes him identical to other trolls in this respect -- an unthoughtful change that is sensitive to a dynamic environment. In other words, it will break mods because those mods aren't prepared to work with an arbitrarily modified TorGal. So the G3 Fixpack creates a bug with this fix (more precisely, with this change: I think that something which causes a bug cannot be a fix at the same time).

The topic linked above doesn't just reflect that players consider these things as "common bugs" (because they are misled and don't know that these are actually caused by the G3 BG2 Fixpack), but also offers a fix to this bug of the G3 Fixpack:

How about that? Already found the solution. Open Torgal's .cre file with Shadowkeeper and delete the item he has on his neck. You have to do this before entering the D'Arnisse Keep dungeon (ie: before Torgal spawns) for it to work.

The "item he has on his neck" is exactly the "fix" of the BG2 G3 Fixpack added by the instruction "ADD_CRE_ITEM ~monhp1~ #0 #0 #0 ~NONE~ ~AMULET~". Notice that the "coding" is good, but the result is a bug!

So players often find out how to fix the bugs caused by a fixpack, but I don't think this should be normal. Instead, a fixpack should be based on a model that is generally usable, and is stable even in a dynamic environment. I repeatedly drawn the attention of the G3 Fixpack developers to this, but my advice was always ignored. The result: a fixpack creating bugs, a fixpack breaking other mods.

On a side note, such "fixes" also imply that some developers are very narrow-minded or have a very limited imagination (something which isn't an advantage to developers who work with computer role-playing games in the Forgotten Realms setting). This is because TorGal is a unique character in the game, and isn't like an ordinary troll. TorGal also had his adventures in the past, and perhaps he gave up his native ability in order to gain special powers or strength (e.g. a powerful Troll Shaman made a ritual etc.). But this is a minor thing compared to the fact that this 'fix" breaks other mods.


Summary: general model required, "coding" is not enough

My first entry in the "Common misbeliefs" topic has come to its end. At the beginning, I introduced the general problem in a few sentences, then I provided an example which I analysed in several paragraphs. I explained why a generally correct model is required for mods, especially for fixpacks, while I also introduced how some common misbeliefs can be created due to incompetent mod developer hands. I also explained how correct "coding" can result in bugs, if the underlying model of the mod is faulty. I hope it was interesting to readers.