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.

[Sikret]

I will devide my post into two categories: Common modders' false beliefs and common players' false beliefs. I will then edit this post to add more entries and more arguments to each category rather than posting new posts. So, please revisit this post frequently.

Common modders' false beliefs:

- Patching files (via WeiDu) is almost always preferable to overwriting files:

This is a very badly spread false belief. I can think of a few arguments (and many examples) against it:

I can think of numerous cases in which if both mod A and mod B use WeiDu to modify (patch) a file, the two mods will turn to be totally incompatible; whereas, if at least one of them had overwritten the file, at least a minimal and acceptable degree of compatibility could have been achieved.

Moever, there are cases in which if both mods patch a certain file, the result will be a bug in the game (even if both mods have used correct patching codes).

Of course, I don't deny that there are also equally cases in which patching is preferable to overwriting; however, the cases in which overwriting is preferable to patching are much more frequent than some people think and advertise.

Let me give you examples of both situations:

- An example of when patching is preferable to overwriting:

If for any reason, you need to modify the INTERDIA.2da file, patching it is a much better choise than overwriting it, because overwriting that file will cause unnecessary incompatibilities with all NPC mods which have been installed before your mod.

- An example of when overwriting a file is preferable to patching it:

If you are the author of a tactical mod and you need to modify the STATS.ids file, overwriting it is a much better choice than patching it. Patching that file can at best (and if you are lucky) result in the same outcome you can gain by overwriting it, but there are many possible scenarios in which patching that file can lead to disasters. Since patching preserves the changes made by previous mods to the file, if some other mod has already changed the STATS.ids file, its changes to it will remain if you try to patch it. Consequently, the final STATS.ids file which will remain after applying both mods' modifications will be neither the first mod's intended file nor the second's, but an invalid mixture of them. Consequently, neither the first mod's scripts will work properly nor the second mod's.

The main point is that patching preserves previous mods' changes to the file and this is not always desired and beneficial. STATS.ids is one of the best examples of files which should not be modified in more than one way (or by more than one mod) and it's not desired to preserve other mod's modifications to it. You should either leave it intact or if you want to touch it, you should overwrite it, because having extra entries and modifications of other mods in that file can never be something desired and doesn't even lead to compatibility with other mods.

Encouraging modders to patch the stats.ids file and discouraging them from overwriting it is one of the biggest lies and false beliefs in the history of modding community. The G3 site is one of the main culprits for spreading such false information and some naive modders repeat what they say without thinking for a second time.

A good example of spreading such false beliefs is what CamDawg and some other people have written in this thread. They either don't understand what they are talking about or were deliberately spreading false information to mislead other modders (or pehaps a mixture of both).

- Dynamic and systematic modification of other mods' files is ethically right and ensures a high level of quality and compatibility:

This is another common false belief. If some items, spells, etc... of another mod makes it incompatible with your own mod, the ethically right thing to do is to announce that mod as incompatible with yours rather than adding codes to your mod to dynamically detect other mods' files and modify them without the other mod's author's permission. However, many modders have taken this as granted that they have the right to do such modifications if they use WeiDu to do it (interestingly, they will frown upon similar modifications if they are done by simply overwriting other mods' content; but if it is done by WeiDu, they are happy with it! Actually, doing such modifications are simply wrong, no matter if it is done by WeiDu or not).

- Players are testers (since modders are not paid for their work, they don't need to test their mods and release bugfree mods). Bugs won't make your mod a low quality mod, because it's natural to have bugs:

This is a false belief spread out by modders of low quality mods. They release untested and heavily bugged mods and pretend that it is natural. That's what I call "Mistaking players for testers". I have already written a lot about this on previous occasions and will probably write more in the future.

Before the release of Improved Anvil, most players were totally deceived by the propaganda of certain modders to believe that the existence of serious bugs in a mod is something very natural. Once IA was released, it proved itself as an excellent example of a bugfree mod. Players started to realize that it is indeed possible to release stable mods and those other modders had been fooling them for all those years.

Another related phenomenon is that some modders tend to hide the bugs in their own mods or in their friends' mods just because they don't want players to stop using those bugged mods. One astonishing example is what you can read in this post. What players read there is a misleading recommendation, because that particular component of that certain tweakpack is totally broken and has several hidden bugs which can easily break other mods' content. The author of that tweakpack has released several bugged mods and has never cared to fix them; yet we see that some other modders who either do not know about those bugs or do not care about them, advertise a broken mod just to keep players installing and playing it. This is a good example of what we call "misleading propaganda". Instead of encouraging the bugged mod's author to fix the bugs of his mod, they simply hide them and advertise the mod as if it is totally reliable (which is plain falsehood, of course).

- Modding is all about technicality and coding:

This is another false belief some modders have in mind. They believe that if a novelty or a good idea is used in a mod for the first time, it doesn't deserve any credit and they can simply "steal" and use it without giving any credit to the original creator unless that new idea also required some difficult technicality for implementing. For example, Improved Anvil was the first mod in which the Spell Immunity spell was tweaked in a way that multiple SI's do not stack with each other and SI:abjuration gives immunity to all abjuration spells including the protecion removal spells. This idea was a novelty in Improved Anvil while implementing it to the game didn't require any complex technicality. Hence, some people thought "ok, this is easy to implement; there is no need to give any credit to its original creator; just let's pick and use it silently". See this post and the relevant discussions after it to see how such false beliefs have affected some people's minds (to the extent that they even shamelessly deny that the tweak was my idea in the first place).

Anther example is IA's unique Item Randomizer which has been silently stolen and released as a separate mod by a thief in the G3 site.

Common players' false beliefs:

- Install a mod because of its name:

The player says "Hey! It's called 'BG2 fixpack'; so, it is fixing bugs; let's go on and install it". Poor player!

One interesting phenomenon regarding the G3 fixpack is that some people try to hide its bugs by giving wrong addresses to players. See this topic as an example. The problem reported by the player in that topic is caused by a bug in G3 BG2 fixpack but a certain modder (who is also known for stealing material from other mods) gives the player a wrong address by accusing the Tactics mod.

However, I'm glad to see (link) that many players have begun to understand what we have been trying to elaborate since long ago. Some players were initially reluctant to accept our points (they were under the influence of the G3 sites heavy propaganda in favor of their fixpack), but thet have fortunately started to understand our points.

- Cheating is limited to using the console commands, using the ctrl-keys and using external programs such as shadow keeper.

This is a misbelief. Fortunately not every player thinks in this way, but they are still many cheaters who believe that if something can be done inside the game without using the console command or an external editor (such as SK) or the ctrl-keys, then that action is legal and should not be considered a cheat.

This is wrong, because the game has many glitches and the engine has many limitations. There are many things you can do inside the game which are not intended and a DM in a pnp game would not allow you to do it. Whenever you do something to deceive the game's engine, you are cheating, even if you are doing it inside the game and without the help of any external program.

For example, abusing the possibilities to gain infinte gold or infinite xp in the game is cheating. There is practically no difference between using these methods and using the console command to add gold or xp to your character. Fortunately, many of these possibilities are blocked in the current version of IA and more of them will be blocked in future versions.

As another example, any action which enables you to kill an enemy sooner than intended and before he actually starts fighting you is cheating, exactly because you know that a DM in a pnp game would never allow you to kill enemies in such ways. An obvious example is casting Time Stop off-screen from distance and before the enemy detects you and then rush to the enemy to kill him. This is a cheat. Again, most of these possibilities are blocked in IA, but some may still exist. If you want to win a battle and be proud of your victory, you should win it in an honorable way without deceiving the game's engine; otherwise, you are cheating.

- Role-player vs. Powergamer:

There are many players who have a totally wrong definition of "role playing". They think that if a mod increases the game's overall difficulty, it also decreases the game's role playing flavor. This is wrong!

Role playing consists of two major elements:

1- The player should have genuine options to make in the game (that is to say, the storyline should not be linear)

and

2- The player makes decisions in the quests/stories in harmony with his character's personality inside the game.

The first one is what a mod-maker should have in mind and the second element is what the player should have in mind. But the important point here is that there is absolutely no reference to "difficulty" in the abovementioned definition. You can be a great role-player and an excellent tactician in the same time. There is no contradiction or opposition between them.

And let's not to use the term "powegamer" at all. It's a word which has already gained a very bad reputation. We don't call us "Powergamers", we are "Tacticians" and we hold that there is no contradiction in being a role-player and a tactician.

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

[Baronius]

Misbelief: "Sikret and Baronius criticizes G3 Fixpack (and certain other mods) because those mods follow a different design philosophy than what Baronius and Sikret prefers"

It seems some people believe that we don't recommend certain mods (e.g. G3 Fixpack) because our design philosophy is different. If releasing big amount of unverified, faulty content can be considered as a design philosophy, then yes. Otherwise, no. It is not about "design philosophy", i.e. not about how one approaches and builds things. It is about lack of design and considerations.

Creating a complex building without an architectural plan, just by starting to put bricks on top of each other -- I don't think it's about a "difference" in design philosophy. It is simply not design. It is a matter of lacking architecture, design. I don't think that the fact a house/building has collapsed can be justified by saying that the developers had a "different design philosophy".

There can be more reasons why G3 Fixpack is so badly designed and thus keeps introducing problems (which facts are disguised by various misleading comments of its developers, who blame other things or mods instead of admitting their own weaknesses and negligences). As we know, in order to increase the traffic of the mod's forum and increase the overall popularity of the mod, the developers try to add lots of new additions ("fixes") in a short time, this happened in the past numerous times. This always ended (and ends) in serious bugs in each release. This has two main roots: (1) Lack of skills (2) Lack of time. Either of the two things could help a lot in the situation, I believe (i.e. if at least one of them wasn't lacking). If they allocated more time to verify and test the mod -- even without revising its architecture -- it would result in less bugs. (One of its developers, devSin publicly admitted that they don't test G3 Fixpack, and they expect players to test the mod and to find its bugs.) On the other hand, they couldn't/can't do it because otherwise it would be impossible to release new and new versions and content of G3 Fixpack (in order to increase its popularity), due to the lack of time. It would only be possible with a development framework and only if the developers/contributors had much better skills, and they would know how to manage a scheduled project in a proper way. This can't be expected from hobby modders, and it's OK. On the other hand, allocating time to verify (test) the mod can be expected, at minimum.

Unfortunately, instead of admitting their own weaknesses, G3 Fixpack developers often try to present the mod's *serious* bugs as *natural parts* of any mod, and keep advertising the project as something reliable, safe. They hide under expressions such as "community effort", a "wide variety of contributions from other communities" etc., trying to disguise the mod's serious bugs -- and their own responsibility -- by presenting G3 Fixpack as some sort of "community effort". The fact G3 Fixpack seems to have many contributors from more sites does not guarantee any quality -- most contributors aren't skilled modders, but the biggest problem is that even the developers undertake bigger work than what they are able to cope with. They make a lot of unthoughtful decisions, and on top of it all, they don't test the new content that is based on these decisions. Instead of admitting their own weaknesses and accepting criticism & advice, they are proud -- they hide behind populistic statements, and mislead players by spreading incorrect misbeliefs about mods.

To sum up, the criticism of Sikret and/or myself about certain mods is not about difference in design philosophy. It is about difference between well-made and poor work. Poor work means unverified, untested work (and not designed correctly either), which is -- on top of it all -- often advertised with misleading slogans and misleading information.

[Baronius]

Misbelief: "BG2 (and other IE) mods can be created easily, you just have to learn WeiDU which is surprisingly easy! Don't worry about bugs in bigger projects -- serious bugs are part of any newly released bigger mod, they can be fixed once they are found"

No, IE modding is not easy. While you can make a small mod with a good editor and some copied WeiDU TP2 code, it is not easy to make a complex, big mod at all. A big or medium-sized mod is similar to any slightly complex software: its creation is engineering work.

Engineering work, no less. Of course, it doesn't mean that its developers must be engineers in some relevant field (though it's an advantage), but a great amount of engineering approach and IE modding experience is required. Otherwise, the mod will have several problems, and will contain bugs and may introduce latent bugs as well (for latent bugs, see this thread). With a development framework (something which WeiDU can't offer), the error ratio and bug probability can be decreased, but for complex mod projects, skill is always required.

Modders who advertise WeiDU (or IE modding itself) as something surprisingly easy are lying. This is more than a friendly reassurance to a beginner -- it is misleading. They want to convince more and more modders to use WeiDU, because they want to spread the use of WeiDU at any cost (since it means more popularity for their WeiDU-based mods, and their WeiDU-based development techniques can also be spread). To sum up, the advertising of WeiDU as an "easy to use" tool is nothing more than *populism*. On a side note, BlackWyrmLair plans to develop a new system to replace WeiDU (something which will be more user-friendly than WeiDU, but we will never advertise it as something which needs zero modding skills), it should be released in a few years.

The misbelief which says that bugs are "natural parts of bigger mods" is spread by those who can't (or don't want to) make reliable, verified mods. E.g. they have too little time to test the mod and/or inadequate skills, but they want popularity and big traffic for their mod's forum (e.g. G3 Fixpack). In these cases, serious bugs always appear, and they try to justify the presence of these bugs with various baseless technical statements. A properly designed and verified mod does not contain very serious bugs at all, or only 1-2 at maximum. It is a lie that mods always contain serious bugs, and it's a misbelief that the probability of bugs can't be decreased for unreleased IE mods.