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]

But just to clarify I've understood correctly: you wouldn't feel that categorizing "fixes" and revising the mod would be another must if you didn't think (rightly or wrongly) that it's being advertised in a misleading way as a must-install for everyone's computer. If it was being advertised appropriately your only concern would be a lack of testing (given your view that it's up to mod authors how much to worry about compatibility).

If this has been your impression, then I must have phrased ambigiously. I'm not a native speaker (English is the third language I've learnt), so it's possible.

(1) Categorizing changes (or "fixes", using their definition), moving the "non-strict" fix categories (or in my interpretation: non-fix categories) to another mod, and starting to properly test the mods involved is a must, regardless how they advertise it, regardless whether they have a propaganda or not, etc.

(2) The fact it's advertised as a must-to-install (or more precisely, advertised in a way that most players will feel it to be essential) and as a must-to-use (for developers) just worsens the whole situation; on top of it all, they abuse the resulting popularity to convince players that the points of those who critcizie G3 FP are senseless.

Due to (2), players consider it a must (they are convinced -- more precisely misled -- that it must be used for ALL mods), and install it for all mods they have, even if many of those mods aren't prepared for it, or their readme doesn't recommend it. Because they all believe "it's probably good and needed, if it's advertised everywhere; it can't do any bad if I install this instead of Baldurdash" or similar things.

So I would be less harsh and explicit if it was only about (1) (more precisely, the lack of it) -- of course, I would still not recommend the mod for the well-known obvious technical ("professional") reasons. On the other hand, since (2) is present too, I can't just disregard it -- it affects players who play BWL's mods, and it affects mod developers who would like to create new mods.

Furthermore, I wouldn't be half as loud as now if it was about a "usual" mod. But it's supposed to be a fixpack, and a fixpack should NOT force all mod developers to add Fixpack-specific code to their mod in order to prevent the fixpack from breaking or corrupting their mod. The other choice for a mod developer is not supporting fixpack, which as two consequences. Due to (2), players will believe it's a bad and not modern mod ("if it doesn't support the new Fixpack which supersedes Baldurdash, then something must be wrong with it...") and will ignore it, or if they don't, then the other consequence "helps": some sympathizers of the G3 FP will bad-mouth his or her work (this is what happened with Improved Anvil V1, certain mod developers started to spread lies about it on other forums).

Yes, if it's installed with certain other mods. But the IA isn't so perfect either in the same respect.

Improved Anvil is a mod which adds content (similarly to Grey Clan and other similar mods). G3 Fixpack is supposed to be a fixpack. A fixpack is supposed to correct the problems of the original game and to make the original game better while offering a compatibility-friendly ground for mods that are based on it.

Let me tell an example.

Mod A gives a main villain one (or two) equipped items (e.g. two new swords) which the villain will use during an important battle (and thus replaces the original equipped items).

Mod B gives the same villain one (or two) equipped items (e.g. two new swords) which the villain will use during an important battle (and thus replaces the original equipped items).

Mod C is a special mod: a fixpack. It gives one (or two) equipped items (e.g. two new swords) which the villain will use during an important battle (and thus replaces the original equipped items). The reasoning: the new items seem to be more suitable, because e.g. according to the D&D manual, that type of creature/race can't use the item type that the villain was wielding in the game.

Mod D adds a check to one of its scripts, whether any party members possess the items (taken from the gear of the slain main villain). It is required for its plot to advance. (The script checks the inventories for the original game versions of these items, not the items added by Mod A, B or the fixpack.)

------------------------------

Mod A and Mod B are obviously incompatible with each other, and with the fixpack too. However, this isn't an issue. Installing Mod A or Mod B after the fixpack will override the fixpack's changes. There is no problem here.

Obviously Mod D is also broken by Mod A, B and the fixpack (Mod C). Because the script of Mod D will never find those items in the inventory of party members (as they're replaced by Mod A, B or C). However, while Mod A and Mod B aren't meant to be standard parts of every installation or base mods for other third-party mods, it's an acceptable incompatibility. On the other hand, the fixpack (Mod C) should NOT replace those items, because it's a FIXPACK and unless the original versions of those equipped items broke the game or a part of the game (or caused some "unambigiously undesired effect"), it should NOT overwrite them just because there is some sort of subjective reasoning. (On a side note, can anyone tell a counter-argument against the example reasoning I've provided, i.e. the D&D rule mismatch? Please do so )

So these types of "fixes" (changes) which have some sort of reasonable but subjective justification BUT introduce potential dependency violations are not real fixes (= in my interpretation: they are not fixes).

A "usual" mod can introduce incompatibility risks because there is no other way to install new content (new content often affects existing interrelations and interfaces), but if a fixpack does it (and NOT just for 2-3 files or game elements), it's another question because a fixpack is used by ALL mods as a base mod.

Just imagine that the new mods are houses to be built, and the fixpack is the soil layer. If the soil layer can easily collapse, it WILL collapse for some houses, and break them. On the other hand, when a mod is installed on top of another, the previous mod (which is far not as big as a fixpack) will only introduce some holes. If the hole is big enough and a mod element (e.g. a person living in the house) steps into it, it breaks a part of the mod -- but this won't endanger other houses. "Usual" incompatibility between mods, perhaps even it's unsolvable (for example, a villain can only wield two weapons, not four...). If the holes cannot be filled up, the house can be built on another place (= the mod will never be installed together with the other mod that caused the incompatibility). On the other hand, there is no way to fill up a giant volume of collapsing soil layer...

As for the documentation and generally about incompatibility, it is WeiDU which has severe disadvantages here. I know how to efficiently build and implement a much better system than WeiDU (with long-desired and completely user-friendly features), but so far no one has asked me about this matter, so I assume there is no interest or intention.