I'd be interested to hear your definition of an objective, unquestionable fix. (& I mean definition, not example)... otherwise the worry is that "subjective" is itself subjective

First of all, a few examples to illuminate, illustrate the matter. But you will get a definition as well.

• The correction of a broken item (or any other resource) which causes the game to crash is an unquestionable fix.
• The correction of a grammar typo or mistake in a text is an unquestionable fix.
• The correction of a certain faulty element (e.g. incorrect description) where the original (e.g. developer, D&D or similar) intent is unambiguously known is an unquestionable fix.
• The correction of a certain element that seems to be inconsistent or faulty and causes an unambigiuously undesired phenomenon/effect due to this fault or inconsistency is an unquestionable fix.

On the other hand:

• The "correction" of an element that seems to be inconsistent or faulty according to a certain interpretation and its effect isn't unambigiously unpleasant or undesired in the game (and possibly hardly noticeable, on top of it all) is a strongly questionable fix, which shouldn't be in the same category as the previous list of fixes. Depending on the concrete case, it may even be considered as a tweak.
• The "correction" of an element, which seems to be incorrect according to a non-objective, non-technical reasoning (such as "guessing what the developers meant", "this is how it works in D&D") and doesn't cause any unambigiously undesired effects in the game is a questionable fix, which shouldn't be in the same category as the previous list of fixes.
• The "correction" of an element in order to make it more comfortable for the player or better-looking is nothing else than a cosmetic change or comfort modification. If such a change would affect at least one important "interface" of the original that may be a dependency of any third-party mod, it is a strongly questionable as a fix, and should be in a different category than the strict fixes (i.e. the first category).

I'm not saying that the group of "fixes" covered by my second (two-element long) list shouldn't be accepted, but since there is a many of them (=> increased incompatibility probability with third-party mods and much burden to those who want to remove them for their mod) and they are questionable, they should be in a different category. In fact, categories! But this will be examined in a later part of my post.

Now a few examples to the above... examples.

Assume that the script of a creature (the behaviour of a creature) seems to contradict what we would expect (e.g. from P&P or directly from the IE game, the quest, the dialogue etc.) and prevents the game from proceeding, e.g. a cutscene freezes (it never ends). This belongs to the following element of the first category:



In fact, even the second part of the sentence should be considered as sufficient criteria for a required fix (my definition that I will write later will reflect this):

Of course, the way such a problem is fixed should be carefully discussed, to guarantee a more or less reasonable solution. In this case, more subjectivity and free interpretation is allowed than in case of problems that cause hardly noticeable or negligible effects in the game. This is because the problem is severe, and even if it's fixed in a slightly subjective, questionable way, it needs to be fixed -- no one can argue that it shouldn't be fixed just because they interpret it in a different way and don't think it's a fix, because it causes an unambigious and spectactular problem. (On the other hand, they can argue about how it should be fixed, but this doesn't mean the fix should be put to the second, "subjective" category of fixes.)

On the other hand, it's much more than a little exaggeration to say that it's a fix (!) to change the alignment to evil of a smuggler captain who attacks your party when you reveal his business. It belongs to this element of the first category:

Assuming one agrees with the subjective change, the "biggest" problem it fixes in the game is that the Detect Evil and similar spells didn't highlight the captain before. And I emphasize: assuming one agrees that the alignment change is justified (there are pros and contras). On the other hand, the "biggest" problem it may cause with this change is breaking the AI of other mods: for example, in this specific case, it may break Improved Anvil's certain scripts. If this (and all the tons of other questionable "fixes") were in a different mod, perhaps Improved Anvil would just be incompatible with that mod and would be able to support the core BG2 Fixpack.

Finally (as far as "example examples" are concerned), let's see another change that cannot be considered as a (strict) fix, and belongs to the following category element:


"Doors not Consuming Keys". Due to the "fix", now they do, the item (key) disappears from your inventory. This is a very nice as a "comfort fix", because many players like it because it makes life easier in the game:


On the other hand, other players wouldn't prefer it (bold added by me):


Why to force the latter group of players by adding such a "fix" to the Core mod (or Core part of a mod)? The previous group of players could still install it by installing the other mod (with the "questionable fixes"), while the second group wouldn't be forced to use them (and mod developers whose mod uses the keys wouldn't be forced to tamper with G3 Fixpack code through their own mod's code to prevent G3 fixpack from breaking their mod). This is the "influence and power of apparent majority" I was talking about: dictating the base content for players and modders, taking the possibility to choose from them. (And let's not forget we're talking about a BG2 Fixpack that is meant to be a standard part of every game installation, so it indeed has a big influence and possibility to dictate; on the other hand, it's interesting that Improved Anvil, a mod which isn't a fixpack and no one is required or recommended to install it for such reasons, was criticized for "forcing certain things on players" and "forcing playing styles". Do mod developers and players have a choice whether to support Improved Anvil or not? Yes, of course. Do mod developers and players have a choice whether to install G3 BG2 Fixpack? If they want the important fixes, they are FORCED to install a lot of other questionable fixes as well).

Back to the example, the biggest problem of the "Doors now consuming keys" change isn't that it's subjective and disliked by some players, but that it may also break third-party mods. What is the balance? Nothing else than introducing a comfort change (that might disliked by some players after all) vs. the risk to break other mods! Why can't it be in a different mod, instead of the mod with the core, strict, crucial fixes?!

Again, the general problem isn't that there is captain with a changed alignment, some keys which disappear from your inventory, or things like these. The problem is that there is very many of them, and the tendence doesn't change. Questionable, mod-breaking "fixes" aren't put to a different mod, forcing all players and mod developers who would need the strict fixes of the Fixpack to accept or tamper with tons of additional problematic "fixes" and changes.

I owe you a definition yet, DavidW. I remember I've made up a quick definition once, and the answer I got from CamDawg (after asking him twice to tell what's his problem with it): "It's not practical enough". He didn't like it because it obviously excluded the questionable, risky "fixes" from the group of strict fixes.

A fix (or strict fix, if you will) satisfies at least one of the following criteria:

1. It solves a problem that unambigiously and noticeably hinders the proper functionality of the game, or a problem that prevents the game plot from proceeding, or a problem that causes crash, freeze or similar critical problem.
2. It solves a problem that causes an unambigiuously undesired phenomenon/effect in the game.
3. It changes an element which functionality, behaviour or feature(s) were incorrect according to an objective or non-objective, technical or non-technical reasoning (such as "guessing what the developers meant", "this is how it works in D&D") and this does not result in any severe incompatibility risk for third-party mods by affecting potential game dependencies.
4. It applies a cosmetic or comfort improvement according to an objective or non-objective, technical or non-technical reasoning (such as "guessing what the developers meant", "this is how it works in D&D") and this does not result in any severe incompatibility risk for third-party mods by affecting potential game dependencies.

Remember that there is an OR relationship between the criteria in the definition; I wouldn't be happy seeing it twisted anywhere by presenting (quoting) them as necessary criteria, as requirements which all must be met -- this is not the case.

Indeed, a good definition should be practical, usable. The best feature of a good definition is its usability. However, usability is also "defined". Defined, dictated by the expectations of players and by the expectations of mod developers (this latter group includes technical expectations, which are related to compatibility and development). It isn't correct to say that a definition isn't practical enough because it doesn't allow all reasoable (but possibly subjective) improvements to be called fixes. In this case, a definition is practical if it helps us to identify which changes should be considered as strict fixes (which are required to be in a central mod) and which changes should be considered as non-strict fixes, and incorporated into additional categories. A practical definition allows as many reasonable improvements (including crucial corrections) to be added to the group of strict fixes as possible while also keeping incompatibility risks due to dependency violations as low as possible.

A practical definition offers balance: increasing the number of required & useful fixes vs. decreasing the probability of introducing problems for third-party mods.

That is what I would expect from every mod developer, including G3 BG2 Fixpack developers: balance. Balance between the urge for constant improvements, additions (to provide new content and better gaming experience for many -- but not all -- players) and the incompatibility risks introduced by the many new changes (which may cause headache for mod developers, and force them to work much).

It would be crucial to realize that other viewpoints can make sense too, and your viewpoint might not always be 100% superior and seamless, guys. I've noticed that "rules"
For example, let's see the case of a creature who has some "illegal" stats, some statistics that its class/race etc. wouldn't allow. Telling that these are bugs and must be fixed is a strongly subjective approach. Who knows that in this case, it wasn't "developer intent"? To make that particular creature stronger/better in the game. And justification can also be found: it's called imagination and the Forgotten Realms setting.

For example, telling that an elf with 19 constitution is illegal and thus buggy and must be fixed is very narrow-minded (note that this elf is a theoretical example to illustrate the attitude I discourage). That elven hero also had its own adventures, might have found a Manual of Bodily Health, and so on.

But to avoid being called someone who brings up a non-existent example, here is a real one: TorGal getting the same regeneration abilities as other trolls. This can easily break mods that are based on TorGal's original features, while it's strongly questionable. Who says that TorGal didn't sacrifice this native ability e.g. during a ritual in order to get other powers?! Why is it required to arbitrarily approach everything with RULES? The Forgotten Realms isn't about that; rules are guidelines, but they aren't meant to make the whole world boring and predictable.

Assuming that one's viewpoint is superior is very narrow-minded. The urge to override original solutions and elements, the urge to "improve" and "fix" everything should be restricted a bit. It's very narrow-minded to search some sort of justification to call everything as a (strictly required) "fix". Yeah, do find things to be improved, but don't put them to the same group that contains critical and important or commonly accepted fixes.

If you tell me, DavidW, that my definition contains words such as "unambigious" and who defines what is ambigious and what is not, my answer is that common sense and technical facts are the two things that are very helpful in 99% of cases. Common sense says that changing an alignment which affects only a hardly noticeable thing while potentially breaking mods is not a strict fix.

If you ask me how to put the changes (fixes) into more categories, and how to decide whether a fix belongs to one category or to another, then let me mention fuzzy logic (you're certainly far more skilled in this myself). The various categories cannot be completely well-defined, but it's possible to decide about most fixes which category they belong to in the greatest degree (let's think of fuzzy membership functions).

So it's not true that subjective fixes cannot be distinguished from strict fixes. For example, I suppose that three categories would be completely enough, suitable: strict fixes, other fixes, subjective fixes (with probably different names than I've quickly made up now).

The strict fixes could be in the central mod, which wouldn't force players and mod developers to accept or tamper with hundreds of questionable fixes. Players who would like the additional fixes could install the other mod as well (which would contain the other two categories, for example).

Easy as pie!

I do ask it again from those involved: why is this not possible? What's the real reason?

That's interesting, I'll consider it.

I take it you don't accept that adding HLAs to SoA creatures is a fix, then? (I thought I'd seen that as an example somewhere, but it's entirely possible I'm misremembering.)

Quick examples/thoughts to consider, off the top of my head:

- "unambiguously undesired" seems a bit open to exploits. Probably some people desire there to be two rings of the ram available from Tolgerias, and two necklaces available from the priestess of Talos, but (I assume?) you do think those are bugs?
- I don't see any space for explicit (unguessed) developer intent. It seems that even if we got an email from Gaider saying "Viconia shouldn't have got Holy Smite", that wouldn't count as a bug.
- Similarly, I don't see any space for even very obvious errors detectable at a lower level. e.g. a dlg file where the bcs contains a typo, but where that typo isn't blocking anything game-critical or unambiguously bad.

First of all, I've slightly extended the following criterion of the definition (and its similar version about cosmetic fixes):
The new version (also quoted below) allows objective and technical reasoning as well. This isn't too significant, because the questionable cases are most often about non-objective fixes that are based on non-technical reasoning (for example, "this is how it works for the other creatures of the same type as well", as opposed to the technical reasoning "this script error breaks the quest in the following rare circumstances...").


If the typo has any (even if very minor or practically negligible) consequences in the game, it can qualify as a strict fix due to (3) of the definition.

If the typo doesn't have any consequences in the game, then it doesn't make any sense to fix it, but it still can qualify as a strict fix due to (4) of the definition (so those who are in favour of such fixes for the sake of completeness can be happy). However, in such an extreme case (= it doesn't affect the game at all), it should only be accepted as a fix if it introduces 0 (zero) incompatibility risk.

(I admit that the previous version of the definition -- where criterion (3) and (4) didn't allow objective and/or technical reasoning -- didn't give space for the bcs typo problem you've mentioned. If this is the only reason you feel that such fixes weren't included, then I suppose your quesion is now answered.)

Personally I'm not in favour of this "guessing developer intent" approach, but as far as I can remember, this was one of the principles listed by the G3FP developers as something they use as a guideline when deciding how to "fix" something. This is why I've mentioned it among my definitions and examples -- if someone wants to use it, he or she is free to do so.


The actual question is, whether their correction can be considered as a strict fix or not. Assuming the implementation of such a fix doesn't cause a considerable compatibility risk (e.g. a dependency problem), it would qualify the fix to be a strict fix, due to this criterion:


It's important to note that relativeness is an important factor. How important the fix is after examining the possible negative effects it might have on third-party mods. What is the size of its "stamp" on the game, that is, how many possible dependencies and interrelations it can effect. The more important/crucial a fix is, the more dependencies it should be allowed to affect.

This is why fixes for game-breaking bugs must be considered to be strict fixes even if their best known implementation requires modifying several game elements (potential dependencies). Similarly, this is why cosmetic and comfort "fixes" that may introduce relatively many problems for third-party dependencies should never qualify as strict fixes.

It also follows from the above claims that since the number of important fixes is significantly smaller than the number of questionable fixes, the total incompatibility risk introduced by the important fixes is still relatively low (even if each important fix affects relatively many dependencies).

Frankly, I'd reduce this list to 1&2 parts (or even to the first thing only). Since I used to take Baldurdash's TP2 and cut out of it fixes for, say, Simulacrum's and Mordy sword's not breaking invisibility. Because the way it was fixed was unacceptable by me. And so on.

So you Baronius would want the core component of the G3BGIIfixpack to be broken down to bug fixes, and fixes that might brake a mod? According to the severity of the change... as in, "there can never be too many choices with the tp2's" or link, look at the Imps reply.

That might make the beta testers get the right info on which component could be still safely installed with a mod, thus providing a larger compatibility...

Do you mean that only the first and second criterion (or just the first critierion) should be used to define strict fixes, or do you mean that you find the other two criteria needless because the first ones include them (which I wouldn't understand)? I suppose it's the first case. Well, strictly speaking, the most important, crucial fixes of the Infinity Engine games are indeed covered by the first two criteria, and 80% of such problems have already been fixed by the original Baldurdash. However, since players seem to prefer other less important fixes as well and many supporters of G3 BG2 Fixpack are eager to fix many things, I tried to compose a not too restrictive (yet accurate) definition. Of course, it's needless to day that this definition applies to fixes, so -- for example -- obvious tweaks aren't covered by it.

On a side note, for those who don't know my viewpoint about it yet (or were misinformed): I've never said that Baldurdash or Baldurdash-WeiDU is perfect and flawless:

• Baldurdash is reliable but not comprehensive
• Baldurdash-WeiDU includes mod-specific optimizations/elements (Tortured Souls, Neverending Journey)
• G3 BG2 Fixpack includes tons of questionable fixes and quasi-tweaks, introducing very high risk of incompatibility with other mods, and requires very much effort from authors who want to base their work on the G3 Fixpack

No. What I would precisely want is the following:
- Re-examine all the fixes (the obvious ones just take a few seconds) during a few days according to the guidelines I've been suggesting for ages (and which were basically repeated in the present thread as well)
- Put the fixes into more categories (but at least to two categories), based on more aspects (how important, how subjective, how risky compatibility-wise)
- Put the real (i.e. "strict") fixes into G3 BG2 Fixpack (I don't care how components are allocated, I suppose it even doesn't need to have multiple components)
- Put the other categories into another mod (or mods, it doesn't matter), e.g. called BG2 Fixpack Plus (with a note in its description that these are more subjective fixes)

So, Jarno Mikkola, it even can have one component per mod.


Yes, exactly, this would be one of its big advantages. The fact itself that the core mod contains strict fixes would guarantee a certain probability for better compatibility (the less changes on the game's interrelations, the smaller probability for incompatibility, and the smaller headache for third-party mod developers).

I don't want to hijack the topic, but I think what the G3 FP developers do (considering their attitude for quality assurance and third-party mods) can be characterized by two words: egoism and populism. Abusing the popularity of their work, BG2 Fixpack.

Thinking about this more: I'm slightly nervous that what makes something a bug should be dependent on how it affects third-party mods. That might be a reason for not fixing a bug, but I don't see why it's relevant for assessing if something is a bug in the first place.

Affirmative.

As for Baldurdash, I merely wanted to say that as small as it is (compared to FP) even it had recieved some questionability (imo). So, technically speaking, I do approve the request to split FP into smaller pieces, not sure if I ever mentioned it'd be a bad idea. Thing is, it just won't make a weather for me, as I used mostly my own fixpack (cut BD with pieces of FP included).

Let's apply your definitions to a real situation. I get lost within abstract ideas and long explanations. Simple is best for me. I'm also not that familiar with BG2 Fixpack components. What I want to know is where you would classify what we've decided to with the following? Are our choices in line more with one side of the debate or the other?

BG1 Fixpack (please note the ONE)

The nobleman in the Friendly Arm Inn who has the Golden Pantaloons.
There is a dialog option that ends with the player receiving 2 gold as a tip should the Gabber's charisma be high (like 18). There is no gold assigned to the creature file and the action command is GivePartyGold(2). It's been changed to GiveGoldForce(2).

During situational testing we found that, if the player were to steal the pants before talking they could still get the dialog option to receive the pants and the 2 gold. Upon further investigation, if the player were to pick certain dialog choices after having stolen the pants, they would be taken from him. As far as we can tell, it was intended to be that way.

For sake of clarity, if the player takes the pants, the nobleman can't give the pants. So we gave him a check to see if he had the pants before offering the dialog that gives the pants. Now we receive an interesting scenario where, as long as the player has never talked to him, steals the pants and then talks to him, they have a 50% chance rather than 33% chance of having the pants taken away.

Since this obviously changes known behavior, but doesn't break any known dependencies that we know of at this time we've set the addition of HasItem checks into the realm of player's choice. Nice, but not really a fix. Actual appearance in the mod has not been set.
Options are:
1) a whole new component in a group of "Optional But Cool"
or
2) a subcomponent alongside the single fix of the GivePartyGold command.

It's important to note (and I might have not emphasized it) that my definition for the strict fixes is primarily for deciding what doesn't qualify to be a strict or at least, a real fix (and as such, should be treated differently). That is, a fix that qualifies to be a strict/real fix does not have to be added as one. There are other aspects as well. For example, if it meets criterion (3) or (4) but seems to be very subjective (but not so much that it should be considered as a tweak) then it should be added to another category (another mod). On the other hand, if such a non-crucial "fix" would introduce incompatibility risks, then there is no way the definition would qualify it as a strict fix.

Since you say that it doesn't affect any potential dependencies (it would indeed be difficult to find a reasonable scenario where a third-party mod would expect a certain behaviour here) and can't be considered as a tweak (there is no reasonable counter-argument), it can even be considered as a fix. Not a bugfix, but a correction, improvement.

If I've interpreted you correctly: the noble can't give something he doesn't have; if you've taken the pants, he doesn't have them any longer. This sounds to be an absolutely non-critical fix, but a very reasonable fix, which is more than just a comfort fix. There is no reasonable counter-argument, because no one can deny the fact that the noble shouldn't try to give something he doesn't have. One more comment though:

There is no problem with the changed behaviour, because it's still completely deterministic. Either I missed something, or the chances you've written are just theoretical, because they are based on the number of dialogue options. The player chooses one dialogue option which gets executed for 100%, so it's completely deterministic. It would be different if your fix introduced some sort of uncertainty, e.g. that he would take the pants with a probability of 0.33 (so he would take them once from three cases).

So I would even classify it as a real fix (provided I correctly interpret the problem you've described). Not a critical or important fix, but something which is more than a cosmetic change. It meets three important criteria:

• Its implementation doesn't affect potential dependencies, interfaces (I haven't seen your implementation, this is an assumption).
• It is not a tweak. It isn't questionable either, because there is no reasonable counter-argument against the newly presented behaviour.
• It is based on a natural, non-arbitrary condition (you need to possess something to be able to give it), unlike changes that argue with "D&D", "rules", "legal stats", "developer intent" and other things.

As I've said, this doesn't have much to do with my definition, it's a matter of designing your mod's architecture and installer.

Personally I wouldn't separate it from the noble's GivePartyGold fix (again, provided I correctly interpret the problem), and I don't see why it should be optional at all. The fact you can't give something you don't possess isn't a "Cool" thing, it's a "Necessary" thing. It follows from the world.

On the other hand, I don't recommend filling the "Optional But Cool" component with too many questionable, subjective and/or risky (compatibility-wise) changes, because most players will choose to install that component too, even if a third-party mod EXPLICITLY states in its readme that it doesn't support it (many players don't carefully read readme files). The result is incompatibily and (possibly misleading) bug reports. If you have many such changes, put them to a different mod, and give an appropriate name to that mod.




I intentionally avoided the use of "bug". Many types of fixes we've been talking about are not bug fixes. If we want to define "fix" as "bugfix", we would have to re-define the word "bug" as well, its common definition is unsuitable for many fixes applied by the various fixpacks (especially G3's BG2 Fixpack).

In other words, these fixpacks make corrections, they fix problems, but not just bugs.

At least, I do hope that the developers of the G3 Fixpack didn't consider the Smuggler captain's neutral alignment as a BUG, or the fact that keys weren't consumed by doors as a BUG. Of course, these were extreme examples, because they even aren't real fixes (let alone bugfixes). The first one is a strongly questionable, subjective "fix" (i.e. reasonable counter-arguments can be found, unlike in case of plainab's pantaloon example), while the second one is a tweak. A huge tweak, which is still in the core, mandatory component of the G3 Fixpack (instead of being in a different mod). *sigh*

Looking at the documentation, I suspect your hopes are in vain: I don't think they particularly distinguish between "fix" and "bug". (And it wouldn't have occurred to me to do so until your post - it's possible this is a language issue?)

But then, I'm fairly sure that their definition of a bug is very different from yours: it's "feature of the game which it's reasonable to infer the designers did not intend or which contradicts their intent". And the burden of proof for "reasonable to infer" is something like "balance of probabilities" rather than "beyond reasonable doubt" (that's UK/US legal terminology; apologies if it doesn't translate well).

But look: in a multilingual community, possibly it's better to acknowledge that different people are using "bug" in different ways than to argue about the "right" meaning?

Sure, there is no problem in acknowledging that. Then it seems they consider that all things they "fix" are "bugs". It doesn't change on anything: then they also believed that the alignment of the captain is a bug, and according to the definition you've provided, "it was probably not intended by the designers or contradicts their intent". How do they know what the developers intended? A Smuggler captain can be Neutral as well as Evil, there are pros and contras, so it doesn't qualify as a (real) fix, especially because it may violate reasonable dependencies.

On a side note, I use/accept different definitions for bug (definitions that are closer to software technology), but it doesn't matter, because it's totally indifferent in the aspect of the severe problems of G3 BG2 Fixpack. If I used a different "bug" definition (as in the first paragraph of this post), the conclusion wouldn't differ either.

Okay, so is this just a documentation issue? If their readme has a section called "our definition of a bug" that said something like

"We define something to be a bug if in our collective opinion there is sufficient evidence to conclude, on the balance of probabilities, that it was unintended by the developers and/or contradicts their intent",

would that address your problems? (I ask mostly for curiosity: it's not as if I have the power to add such a section.)

EDIT: incidentally, from a software point of view I can see the logic in a bug/fix distinction: I guess computer games are interesting in this way as they have content as well as framework, whereas (say) a word-processing package is pure framework. One could make the case that there's a relevant distinction between content fixes and framework fixes, though I'm not sure how precisely it could be done... this is more your area than mine, I suspect. (As you say, it's probably not germane to the fixpack discussion.)

It doesn't solve anything. Regardless how they define "fix" and "bug", real fixes either address important game problems (with as low incompatibility risk as possible, but possibly with higher risk) or address faulty elements (minor problems) while keeping the incompatibility risk low. My definition (in a few posts earlier) of what can qualify as a real fix doesn't depend or rely on how we define bug and fix, because it's quite descriptive. In fact, that definition can even be used to define what a FIX is for the IE games. Due to the fact there are differences between the definitions/guidelines G3 FP developers and I seem to use, I used the expression "strict fix" and "real fix", but personally, those what I call "fix". Others are improvements, comfort changes and such.

Well, it does if you accept, as I think you do, that people can write whatever mods they like and it's up to them whether to make them compatibility-friendly or not.

Or more accurately, it means that if there's a problem, it's a marketing problem and not a content problem. If different people mean different things by "fix", it can't be wrong for anyone to produce a mod which fixes things under their definition of fix and call it a fixpack. There are separate issues of whether it's marketed in good faith and whether it's adequately tested (both of which I'm deliberately avoiding in an attempt to keep the discussion civilised )

Indeed, they can. I think it should be expected to thoroughly verify a mod before its release, but as you've said, it's up to the author. On the other hand, when I offer advice, and then they don't just ignore it (it would be 100% OK) but accuse me of being biased and of simply "disliking the G3FP", then I don't appreciate that. Especially because misled players tend to arrive to BWL occassionally. I don't like when people are manipulated and the members and certain mod developers of BWL have to pay the price for it.

My problem has always been double:
1. Severe technical problems with G3 FP. This is why I don't recommend it to readers. I never mention 'propaganda' and similar things in such topics unless I'm accused that I don't recommend it for personal reasons, or unless I'm questioned or attacked how I dare not to recommend G3 FP. I restrict my statements to technical facts.
2. Their attitude and propaganda. I wouldn't mention these anywhere if our technical arguments wouldn't simply be twisted and negated by their manipulation, and if I didn't see several misled players and mod developers all the time.

You asked me what was my definition of fix. I answered that, so I think it's difficult to introduce any novelty to this discussion.