The Black Wyrm Lair Forums
The Black Wyrm's Lair Terms of Use Help Search Members Calendar

Welcome Guest ( Log In | Register )

 
Reply to this topicStart new topic
> About hidden/subtle bugs
Baronius
post Jul 22 2008, 03:35 AM
Post #1


Master of energies
Group Icon

Council Member
Posts: 3318
Joined: 9-July 04
From: Magyarország




Since I don't have as much time even for IE mod/tool development as I would like to have, usually I don't write tutorials or guides. However, since many players and mod developers (even some of the more experienced ones) don't seem to be aware of an important phenomenon, I've made an exception and have written a short introduction to it.

The following reasoning can be read quite often: "I had Mod X, Mod Y, Mod Z installed and everything was fine, but when I installed Mod K, I experienced the bug you are talking about. Uninstalling Mod K helped, so it was the culprit I think.". The answer of the other person: "I uninstalled Mod K but the bug did not disappear for me... interesting."

I would like to point out that simple logical reasoning doesn't always give a correct result (but, of course, it can be a good basis for further investigation). Let me tell an example. (You can find a graphical illustration attached to this post; feel free to use it while reading my below lines).

There is Mod A, Mod B, Mod C and Mod D. The player wants to enjoy Mod A at any cost, but if possible, he would like to use Mod B, Mod C and Mod D as well. Mod B introduces a bug (for example, corrupts a file), but the bug doesn't appear in-game when only Mod A and Mod B are installed, because it doesn't affect Mod A. In fact, the bug doesn't appear in-game even when Mod C is installed, because the bug doesn't affect Mod C either. So we have three mods, Mod A, Mod B and Mod C installed, in this order, and Mod B is buggy, but the player doesn't experience anything! On the other hand, the bug introduced by Mod B affects Mod D (e.g. because Mod D uses the corrupted resource). So when Mod D is installed and the player starts to play, the bug appears. For example, his or her game crashes! "Oh no, Mod D corrupted the game! It's buggy!"

So bugs can be tricky! They might not appear in the game immediately or cause any problems, but in certain circumstances (e.g. mod combinations), they are "activated"! Like certain types of computer viruses, which trigger at a given time or in certain conditions.

A few consequences:
  • Just because you believe a mod caused a bug, don't condemn it immediately or remove it from your list forever (unless it's evident that the mod caused the bug)! Report it instead, and consider the opinion of skilled mod developers and testers. Of course, if you cannot solve the problem and/or want to play without the bug, you can uninstall it but don't forget that it might be the mod combination and not the mod which was responsible for the bug. That is, it's possible that another mod is buggy, but a harmless mod triggered the bug in the game!
  • As I emphasized countless times in the past, the statement "it's not a bug as long as it doesn't appear in-game" is nonsense. Unless you can prove that the bug will never appear in-game in any (reasonable) circumstances, the bug remains a threat and should be fixed.
  • For the above reasons, not all bugs can be recognized during tests. It would be required to test a mod with all other possible mods (or at least, with all other typical mod types that might interact with the tested mod), and this is impossible. This is why it's so tremendously important to correctly design and build a mod, and not to exclusively rely on testing!
  • The more complex a mod is, the more sensitive it is to the bugs, errors, negligences of other mods. For example, this is why Improved Anvil has so precise installation instructions. Latent, hidden bugs might do absolutely nothing with smaller projects, but a huge mod that relies on many resources and elements of the game (such as Improved Anvil) can easily be broken even by the smallest (but subtle) bug or flaw of a smaller mod!
  • In the past, I was the subject of the criticism of certain mod makers who demanded "practical examples" from me to prove my (theoretically and logically estabilished, proved) statements about certain things. As you can see, practice isn't everything. Sometimes skills and experience can help much more than practical tests when recognizing potential errors, problems.
To sum up, the mod which triggers a bug might not be the same as the mod that introduced the bug. Keep this in mind! On the other hand, it's certainly reasonable to use the "trigger" mod as a basis to find the bug (because it's affected by the bug even if it's not the source of it), i.e. to locate which mod is the real culprit.

It is important to note that this is a short summary that focuses on a very specific topic. For example, I could have written about bug types as well. There are bugs which don't have any spectacular consequence in the game. In fact, the effect of certain bugs is unnoticeable. BWL's Distinguished Developer, Sikret also pointed it out that these bugs can be really subtle and players usually don't notice them at all. E.g., a bug in a certain mod might prevent another (big) mod's quest from triggering. That is, the player even doesn't realize that the quest exists. No bug is reported! Yet, when it happens with more quests (they simply don't trigger or they behave in an undesired way) the author of the big mod won't be too happy; while the creator of the buggy mod can simply answer "there were no bug reports, where is the bug?". The author of the big mod shows the bug, it gets fixed. But when a mod is poorly designed and tested, it will be a continus source of bugs, and if its developer doesn't (want to) realize this (and doesn't want to revise the whole mod) and demands "concrete examples" of bugs instead, the problem just becomes bigger... It surprises me when certain mod makers ignore or reject the advice and criticism they get, because they are too self-confident and believe they can't be wrong and their methods/techniques are seamless. Instead of considering the advice and possibly improving their skills!

So it does matter very much how precisely/thoroughly mod authors design and test their works. Some authors say that too much attention spoils the fun of development, but I'm sure there is a level where fun and hard work is balanced (let alone the future advantages of a well-made mod).
Attached File(s)
Attached File  example.png ( 68.35k ) Number of downloads: 61
 


--------------------
Mental harmony dispels the darkness.
Go to the top of the page
 
Quote Post
Sikret
post Jul 22 2008, 06:09 AM
Post #2


The Tactician
Group Icon

Distinguished Developer
Posts: 7781
Joined: 1-December 05




QUOTE(Baronius @ Jul 22 2008, 08:05 AM) *
BWL's Distinguished Developer, Sikret also pointed it out that these bugs can be really subtle and players usually don't notice them at all. E.g., a bug in a certain mod might prevent another (big) mod's quest from triggering.


Baronius is most probably referring to this post of mine in which I have explained how hidden bugs in a mod can affect the content of other mods.


--------------------
Improved Anvil




Cheating is not confined to using external software or the console commands. Abusing the flaws and limitations of the game engine to do something that a human Dungeon Master would not accept or allow is cheating.
Go to the top of the page
 
Quote Post

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:



- Lo-Fi Version Time is now: 6th November 2024 - 01:33 AM