UB bug still present in v16, [split by Baronius] Options

[Baronius]

The bug was known for v15 already. Wouldn't it be easier to fix it in UB itself?

[This topic was split from this]

[Baronius]

Nice solution, plainab. It's "intelligent" code, because it detects the script's name.

However, it's still a reactive solution. It has been done only after a few mods have been broken. And it's a solution to a specific problem. On the other hand, my point was meant to be general, so let me clarify it in such an aspect.

One could argue that this could be made proactive by systematically applying such intelligent codes in mods, but it wouldn't be a widely usable solution (at least without the support of additional tools).

When a mod is tested and its quality is verified, the author and the testers experience certain things (expected and unexpected events, bugs and flaws, certain behaviour and AI of creatures, etc.) in the game. These help the author to develop and refine the mod to a state which meets his or her expectations. The public release of the mod will work according to these expectations.

It's natural to consider the original game as a basis when creating a mod. The files of the game, the dependencies of the game are primarily taken into account when creating a mod. When developing a (bigger) mod and finalizing it, you assume "too" many given things about the game. For example, the intelligent code you presented is for scripts, but similar code could be written for practically all other resource types as well. Let's see an example.

Certain alignment changes of G3's BG2 Fixpack may break Improved Anvil's scripts (note that it isn't a practical threat, as Improved Anvil doesn't support the installation of G3 Fixpack). I remember that Sikret was advised to set the alignments of the creatures in question to the alignments required by scripts. In other words, Improved Anvil would have overridden (overwritten) any previous changes -- including G3 Fixpack's changes -- on the alignments it requires for its scripts. It seems to be a working solution, but there is a problem:

What about the other thousand (or more) dependencies required or modified by Improved Anvil? Should all of them be checked by intelligent codes during the installation or enforced through some sort of "patching" code? This would practically mean overwriting half of the game with "patching" code.

One could argue that you should only enforce those changes which are modified/overwritten by other mods. But what mods? If the installation order isn't fixed, the player might install any mods before the mod in question, so there is no way to know what will be changed in the game by other mods. But let's assume we only want to build on G3's BG2 Fixpack. It's still not an option: G3 Fixpack changes all the time, and even most of its existing modifications are unverified (or even untested). How can you prepare your mod to something which will happen in the future?

In other words, enforcing expected dependencies and using intelligent codes to detect other mods' changes on the game cannot be applied proactively, because bigger mods would have to overwrite half of the game and scan several hundreds of fields to detect changes. So the reactive solution remains: mods crash, mods trigger bugs, mods cause problems -- developers find the problems, and apply specific fixes on their mods to work with each other. Then it's starts from the beginning again.

To cut a long story short, the approach favoured by certain groups of mod developers strongly relies on reactive modding. Again, let's see an example.

G3's BG2 Fixpack applies a huge amount of changes to the game (and very many changes aren't strict fixes). These changes tend to break mods, or at least, they cause mods to work in an unexpected or undesired way. So the developers suggest you to remove the fix through the installation code of your own mod. That is, the G3 BG2 Fixpack requires mods to negate its changes, if those changes cause problems for a third-party mod. This is how its developers imagine it should work:

1. G3 BG2 Fixpack is installed as a base mod.
2. A third-party mod is always developed and tested with G3 Fixpack installed.
3. The undesired or problematic "fixes" of G3 Fixpack are negated by the third-party mod's code.

One of the problems is that negating/removing changes isn't so easy. The changes can form a forest of dependencies with recursive relationships, and without knowing G3 Fixpack in details, your changes might be unsuccessful (and problems might appear in a future combination of mods) or even introduce a bug.

Another big disadvantage of this type of reactive approach is that the third-party mod becomes dependendant from the mod it was based on (e.g. in this case, G3's BG2 Fixpack), so any future changes on the base mod will affect (possibly break) the third party mod as well. The author of the third-party mod has no other choice than checking the base mod's news and events, and revise/extend his or her own work when the base mod has been changed. He or she can never say "At last, I've finished with the most of it, now it will be just minor fixes once per year". On the other hand, the original game is a static system, it doesn't change and thus it won't break mods that are based on it.

In case of our example, G3 Fixpack, one could argue that the third party mod author only have to deal with the changes of the Core component of G3 Fixpack. Apart from the fact the Core component is huge too, there is another problem: while the other parts are optional indeed, most players usually choose "Yes" when the installer asks them about it (why would they skip components with tempting, cool-sounding content). The consequence is obvious: all optional components will be installed too, and the third-party mod isn't prepared to their changes.

The third problem of this solution is that it expects the author of the third party mod to study the base mod (e.g. G3 BG2 Fixpack), and negate/remove certain changes of it that cause problems for the third-party mod. It makes the life of new mod developers even more difficult. Let's see how these things changed with time (in case of a simple or medium-simple mod):

1. At the beginning, you could create a reliable and stable mod (even a serious quest mod) by creating a bunch of item, spell, store, creature, script, area etc. files and adding them to a TeamBG IAP/SFX pack. Such a mod isn't compatible with other mods that change the same files, but it works in the game.
2. Now, we expect an IE mod developer to learn the basics of the WeiDU system, and install these changes and additions to the game via WeiDU. This code is still relatively easy, and even if the mod developer doesn't understand its computer science aspects, he or she can still use a sample code from somewhere else.
3. In the present topic, we've been talking about intelligent codes and mods that enforce their required dependencies by using code; I've been talking about the developers of certain mods (such as G3 Bg2 fixpack) expecting third-party mod authors to ensure compatibility with the G3 Fixpack... It isn't so easy any more, is it? Is there a difference e.g. between the code you've pasted and the complexity of creating an IAP pack?

Don't get me wrong (and before anyone would try to twist my words: no need for it), I'm not saying that IE mod developers should use IAP. I'm merely trying to express that the expectations (demands) towards an IE mod developer have increased a lot. It's not enough to thoroughly test the mod, certain mod developers would expect others to understand data types, bitwise manipulation, variables, programming language structures etc.

For example, let's see our previous example again, G3 BG2 Fixpack. I ask it, why can't it work in the following way:

1. G3 BG2 Fixpack is one mod, with the strict, unambigious fixes. Most mod developers could easily support this fixpack without having to study its code or negate/remove its changes via their own mods' code.
2. There is another mod which includes all the questionable, subjective fixes. This would be a bigger mod, with a lot of changes, so those who couldn't support it (e.g. authors of big or complex mods) could still rely on the aforementioned "strict" Fixpack.

This is a big question: why aren't the questionable, subjective "fixes" put to a different mod? I have never got a reasonable answer to it.

Why IE mod development has to be the privilege of those who understand data types, bitwise manipulation, variables, programming language structures etc.? One could argue that there is sample code available, but in the hands of those who don't understand the code they use, it just becomes the source of bugs. And adjusting, extending sample code isn't possible without the understanding of certain fields of computer science.

One could say that someone who wants to be an IE mod developer should learn these things or forget about modding. It's indeed reasonable to expect a certain level of knowledge and user skills for modding, but they are far from what a WeiDU programmer needs to understand and use in the practice.

In the light of the fact WeiDU is a very useful and versatile system which -- on the other hand -- lacks high abstraction and certain important services, my conclusion is as follows:

• Developers of mods such as G3 BG2 Fixpack should reconsider their viewpoint, and think about splitting, revising and thoroughly testing their mod, instead of waiting for players to report bugs (which isn't a problem -- most G3 Fixpack fans gladly do so), and instead of expecting third-party mod developers to use their monolithic fixpack and adjust their mods to it after learning advanced WeiDU skills.
• IE mod development could be made much more reliable and easy. The current system isn't user-friendly enough, so IE modding is currently the privilege of those who devote very much time and effort to learn, and remain active to constantly support and adjust their mod according to the newer and increasing expectations of the "mainstream" of the IE modding community.