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]

It seems to me that this mod we're discussing is a mod which attempts to modify those bits of the game which the authors think, on the balance of probabilities, contradict developer intent, and make them not contradict developer intent. It also seems to me that "fixpack" is a reasonable name for such a mod [..]

For Sikret and me, it doesn't. There is no need for definitions, just common sense. For us, a fixpack is what solves problems, and not creates them. Note that I didn't use the words 'fix' and 'bug'. I used the word 'problem'. In this case, a problem for a player is -- for example -- what has a negative impact on gaming experience. For a mod developer, it's a nuisance to be deal with, something which requires plus effort and time; effort and time that isn't devoted for his or her own mod's internal improvement, but rather for something that is triggered externally, by the silliness of someone else.

(SMALLER PROBLEM) The G3 BG2 Fixpack changes things that are liked by certain players while disliked by others. It has a negative impact on the experience of those who dislike it.

(BIGGER PROBLEM)
The G3 BG2 Fixpack changes things that can break third-party mods.
(1) It has a negative impact on the experience the players who encounter the problems and broken content in the third-party mods.
(2) It causes a nuisance and burden for third-party mod developers, because they are forced to touch their (possibly well-made) mod and modify their own work to fix the problems of an external mod (the G3 Fixpack).

'Developer intent' or not, 'balance of probabilities' or not, definitions or not -- common sense is the best advisor, and it says: a fixpack should not introduce PROBLEMS for players and mod developers. No matter how we define fix, bug, developer intent or whatever. Problems are problems. Nuisances are nuisances. Negative effects are negative effects.

Generally, in my dictionary, something which causes negative effects for players and modders can't be a fixpack.

As someone wrote in a Gibberlings3 forum topic:

What is a fixpack fixpack? It's a fixpack written to fix things that a fixpack breaks, of course.

It hits the nail on the head.

Your below statement is a nice but rather theoretical, formal definition:

whether something is or is not a fixpack depends on the definition of "fix"

Yes, but it disregards the external conditions, expectation of the "world" that surrounds this statement.

An army can also have a definition (I don't want to define it, let's imagine something reasonable for it, e.g. "an armed organization which ...., controlled by the ... " etc. ).

Your statement quoted above is almost like this:
"whether something is or is not an army depends on the definition of "army""

If we want, we can define an army as a "group of mounted warriors with bows". It's another question that such an army won't really protect a country nowadays from anything. Is it an army? By definition, yes. Practically, it isn't!

So there are qualitative measures as well, not just static definitions which think in absolute things.

It's senseless to keep focusing on definitions so much, because definitions themselves don't help at all. We could use completely different definitions to build up Physics -- everything would be consistent and OK, but completely different. It's another matter that things would be hard to handle etc., because of the impractical definitions.

I can define 'hero' as "Any person with nickname Baronius". It won't make me a hero.

So I think saying that the creators of fixpack have a consistent definition with their work does NOT justify it that their work causes problems and nuisances. It's a poor justification, just like the earlier one (i.e. that "how Baronius defines 'subjective' then", asked by certain G3FP developers), which was easily solved by my post where I presented that it's not that hard to categorize fixes (the fuzzy membership functions example, etc.).

To cut a long story short, common sense says that a fixpack -- regardless of its definitions -- shouldn't cause PROBLEMS. We say that a fix should never cause problems -- a fix should SOLVE problems, instead.