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.

[DavidW]

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.

I think you're misunderstanding what I meant, which could perfectly well be my fault.

My point is that the FP is operating with this definition of bug:

Something is a bug ("thing needing fixing", if you like) in software X if it contradicts the intent of the designer(s) of software X.

And actually I think that's fairly defensible. If someone asks me whether such-and-such thing they've encountered in SCS is a bug, the reply is normally either "oops, yes, I'll fix it", or "no, it's intended to work that way". I'd have thought the same is true for most people's mods. It might be, of course, that once they know that (say) my giving Mulahey a Summon Fallen Deva spell is intentional, they decide that that's a really stupid feature (rightly so in this case!), but that doesn't make it a bug.

Now of course, the problem for the FP developers is that they want to know what the bugs are in vanilla BG2, which requires them to make inferences about what the developers want. Occasionally they've been able to do that by actually asking them (I think they corresponded with David Gaider a couple of times), but mostly they're having to resort to various deductions and evidence-gathering (my "balance of probabilities" from earlier in the debate).

(Incidentally, I'm using "designer/developer intent" in a relatively narrow way. In a sense, the "intent" of the BG2 designers was to create a bestselling game and make lots of money; the intent of Sword Coast Stratagems is to entertain me by seeing what can be done within the confines of the engine; on your theory, the intent of the BG2 fixpack designers is to spread the fixpack, collect happy players, and advertise WEIDU (I'm not necessarily buying that theory, of course ).

But in a narrower sense, my intent in writing such-and-such bit of code for SCS is that mages should cast these spells in these circumstances; the intent of the designers of the fixpack in writing code to change someone's alignment is to change it, etc. )