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]

Incidentally (and off-topic), thanks for the civil tone in which this conversation is happening (to me at any rate!).

You don't need to thank anything, but I'm glad to see you feel it in that way. If someone (from those who seem to disagree with us) should be considered as a more credible discussion partner, then it's definitely you. For obvious reasons. Of course, everyone deserves civil tone, except trolls (who don't get any tone, they get Crom Faeyr at BWL).

By that same definition, something is a bug in Fixpack if it contradicts the intent of the Fixpack team.

Their intent is to spread the BG2 Fixpack, and collect as many happy players for it as possible; and meanwhile, to teach as much WeiDU skills as possible, which also brings traffic for their site, and spreads the use of WeiDU.

This is all nice, but meanwhile they forget the real goal of a fixpack (= to fix real bugs and offer a compatibility-friendly ground for mods that are based on it), instead they add lots of things they call "fixes" so they can advertise it to be big, continously-improving etc., necessary mod. Same with WeiDU: they forget the fact modding is about ideas (and learning as much knowledge as required to realize one's ideas), and not learning as much knowledge as required to support their G3 Fixpack (and possibly to negate the changes of the G3 FP which break one's mod).

EDIT: correct me if I'm wrong, but under your definition of a bug, something in fixpack wouldn't be a bug just because it broke another mod: something more would be needed.

I haven't defined bug, I only defined a fix (= real fix). I will try to give a simplified description. Obviously, let's disregard the "obvious" bugs (= corrupt file, faulty implementation of a fix). On the other hand, a change ("fix", but not fix) which affects a potential dependency (e.g. monopolizes a supposedly "popular" game interface of mods) without a valid justification is basically a bug (see my definition of fix for what a valid justification is: e.g. a broken or "unambigiously undesired" element can be enough justification). This has been one of my major points all the time: if a change of a fixpack corrects an actually faulty or broken element, interface monopolizing is acceptable; otherwise it isn't. This is because there aren't many real game bugs to be fixed, and this means there won't be many monopolized interfaces => this means there will be very few broken mods. But I've devoted a complete post to explain this, as you also surely remember, so I won't repeat it.

I know I've quoted it already, but I like it so much:

something is a bug in Fixpack if it contradicts the intent of the Fixpack team

This probably hits the nail on the head, and is in perfect harmony with what I've been saying all the time: they believe their methods are superior and thus they have right to decide what is considered to a bug in their work and what isn't. TheBigg pointed out a few posts earlier, that it's never good if a developer is a tester as well for the same project (More accurately, the tester team is "external" in the reality, they are obviously not those who develop the project -- but this is off-topic). Well, the case is the same here: they develop the fixpack and they are also those who define what is the bug in it. We all know that it's never good if the same person criticizes (or proofreads, examines, etc.) a certain work as the one who has created it. Unfortunately, the G3FP developers believe their methods to be superior and perfect, and do not allow others to make suggestions. They even don't consider others suggestions.

Let me create another definition then, based on your latest one:
Something is a bug in the game if the Fixpack team thinks that the Fixpack should change it.