Currently reviewing TS v6.11 code alongside DR code to look for what could be causing hassles. ETA on summary is 6 weeks unless I am sidetracked (plenty of stuff going on) - please feel free to drop off specific problems on G3 or PPG or SHS boards.

(IA compatibility is a completely different question, please see the readme in that mod for more information).

While each of us in the IE community are allowed their own opinions, I think a constructive way of addressing those questions would to be to go to the NPC mod makers in question, and ask the same question. My current Tutu and BG games run with a large mod loadout for testing, and they all work extremely well, including several BWL mods (TGCep1 and Herbs and potions, and Jastey's Slime Quest on Tutu). At SHS, there is a section of MegaModders who successfully handle various versions of BP/BGT/etc., incorporating TS and NEJ, etc, on the same installs as many other NPCs from PPG and G3, et al.

I understand the frustration of two opposing philosophies of modding, but I am afraid that the choice of words indicating that development of G3 mods makes them widely incompatible is neither accurate nor fair. Nor is the development process a short one; widespread testing among several platforms, with anywhere between a handful of beta testers and an entire set of 12 or so folks specifically providing testing and feedback (depending on the mod, of course). Cooperation among teams of coders and an open policy of producing joint public code and testing it, then writing up tutorials on it and updating it with feedback allows modders access to many helpers, making coding review a strong and vibrant process.

The way to get folks to be able to identify the specific incompatibilities and give information on tracking the difficulty down is to experience the problem, get a savegame, and write up what the specific dialogue/action was that was taken. Then the modders in question can attempt to isolate and fix whatever is causing the trouble (assuming they wish to be friendly enough to help eachother out).

No problem, I didn't say that specific incompatibilities shouldn't be addressed by joint effort. E.g. Sikret and aVENGER did such a thing too, to my knowledge.


It's not just about testing; it's about theory, methodology and guidelines. The problems with this are excellently reflected by the G3 Fixpack, which still hasn't been split to two mods up to now -- despite the fact it's now obvious for everyone that it ceases the possibility for mods even to be compatible with the original game by introducing and changing too many dependencies. These problems can only be addressed in "reactive" ways (based on reports, tests, ...), everyone can see the frequency of bug/problem reports on certain G3, SHS and PPG mod forums.

So verifying and adjusting code is not sufficient to write highly reliable mods. (Especially because coding, implementation is the very last step of development.) Even bigger G3 mods are usually compatible to each other, mostly because there is a big cooperation among its creators (as it should: it's one group), to test the mods together and compare codes. It's good that such a cooperation also exists between different groups/sites, but it's very big effort and very time-consuming. (And thus some BWL modders can't afford the time or simply refuse this prodigal method of improving compatibility.) Thorough design, implementation and verification may require more sacrifices at the beginning, but it will make a mod more robust, with less compatibility risks with future mods as well. This is what I try to favour at BWL, and hopefully with more and more success (though much depends on the author's time, preferences and possibilities). If you see the (few) incompatibilities of BWL mods that were revealed after their release, most of them were caused by the problems of other mods. (G3 Fixpack to IA, UB to ToD, G3 Fixpack to Sheena etc.) Unfortunately, these problems were/are of general nature (so UB's and FP's problems will affect any other mod too which has the same dependency).

Unfortunately, I don't have the time, and -- after I've seen the lack of interest -- neither intention to provide more material about how you can improve the process. Let's just keep up everything in the way it has been going so far, i.e. everyone peacefully makes mods according to his or her preferences and knowledge, contacts other modders and fixes specific problems according to his or her preferences and knowledge, and so on. Don't get me wrong, I don't expect modders to know (or even to learn) the principles of my more systematic development approach -- modding is fun, and if it's a burden for someone, it shouldn't be done. On the other hand, I would welcome more respect and honesty from certain modders (i.e. not coming here to harass people such as Sikret after they've got a final answer; not spreading lies & unverifiable statements about mods they don't like for certain reasons, and so on). And, perhaps, more own thinking. Many modders just eat what a few others (such as "TP2 ninjas") say about compatibility and code, without actually trying to understand it. And, which is worse, they even defend it arrogantly.

Any further discussion of this -- let's use private messages. Let's not continue hijacking this TS topic. I think trufa's question has been answered.

Understood. I was unaware I was the one hijacking the thread. I apologise.

To summarize,
To obtain assistance with incompatibilities between TS and DR, Auren Auseph, or other G3 mods, please report the incompatibilities to the untrained hobbyist modders that are using flawed development models, antiquated design theory, widely incompatible code, and arrogant attitudes to the aforementioned forums. Please leave the trained professionals of Black Wyrm's Lair alone, for the IEcommunity has determined that it is better to leave things as they are rather than attempt to work together to provide utility to the players of IE mods.

No, we both did it, but at least it was slightly related to trufa's question.

Your "summary" is exactly a very good example of why some modders here refuse to cooperate with those who you seem to represent. (They often talk in the same way as you in your summary.) It twists what I've said, it's highly exaggerating and generalizing. Where did I say they're untrained hobbyists? Where did I generally say or imply that their code is "widely incompatible"? You know it very well that I consider several G3 mods very good. And where did I say that *all* modders work/act in such a way? Etc. Etc.

And no one has said there are trained professionalists here. Everyone knows different fields of modding, and in a different level. Cooperation exactly means we're listening to each other and considering what the other says, and not forcing our methods on each other. Some of the "untrained hobbyists" (quote from you) know certain aspects of BG2 much better than I ever did. I've learned several things from them in the past. Similarly, it's possible that I'm more familiar with certain other modding aspects than others. It's really needless to emphasize these obvious things (i.e. that everyone knows different fields), but after the countless accusations ("They don't like the mod, so they mark it as incompatible"), I thought it's time to make it clear: I do know what I'm talking about e.g. when I say that a fixpack shouldn't break compatibility with an original game. (Similarly, Sikret or DavidW obviously knows the aspects of developing tactical content much deeper than others.)

So it's not me who considers anyone "untrained hobbyist". It's not me who comes to other mod's forums to harass the author (such as what certain people have done with Sikret or Vlad). It's not me who spreads lies about certain mods. It's not me who tells *anything* bad about others' works. The only big mod I've had objections with is the G3 Fixpack, and I've supported my statements with general proof. It's not me who used to regularly discourage players from trying TS (yes, it's kulyok), with arguments such as "it's not modern", etc.


And, you see, this is the big problem: if someone or something is different from you (and this applies to those who you feel to be attacked by me) or your methods, you immediately try to form it to your own shape. Cmorgan, you've been quite moderate in this (others were not), saying that "author advice should be followed" and similar things. However, your latest post reflects that somehow you also don't understand the real point. I'll tell an example.

G modder offers/recommends making a B mod and a G mod compatible to each other, via installation code. G modder calls this cooperation, and B modder too -- to this point, it's cooperation (because it's an initiation by one of the modders). B modder says that he doesn't support it, and G modder considers the whole thing as refused cooperation from B modder. G modder even doesn't think that the following is also possible: hey, maybe B doesn't want compatibility because he thinks that's the best for players (i.e. has good technical reasons, strictly *technical* compatibility could harm one or both of the mod's concepts). Instead, G modder believes "B modder doesn't like my mod, so he marks it as incompatible", simply because G is unable to accept B's arguments, they're out of his scope of the meaning of "argument". That is, cooperation is discussing problems together, and not a one-sided offer to "cooperate". (Very similar could be seen with IA: when it was released, it got a invasion, simply because some modders couldn't accept it's contrary to their concepts and wishes.)

Also, it's easy to notice how often you use "code" in your words. "Widely incompatible code". If you check it, you will see I've never said *code* is incompatible. Generally, I've used "code" not too often. It's because producing code is just a part of the development process, and not the central part. You seem to focus on code, yet it isn't the crucial part of a mod. Overestimating its importance and putting it to the center is also something I don't recommend. While "code" is what determines the technical compatibility eventually (this is a bit simplified, but reflects the point), ensuring technical compatibility and decreasing comp. risks shouldn't only be done on code's level.

I see a lengthy philosophical or perhaps political discussion in this thread, but no concrete examples of what the problem is, or more importantly, what the solution is.Can you give an some examples of these guidelines? As an independent modder (i.e., not affiliated with the staff of any particular forum), I'd be interested in seeing these.

Feel free to split this topic off, but I see no reason why something this important to the modding community should be kept to private discussions.Obvious to "everyone"? It's not obvious to me. Some examples of what you're talking about here would help too.
This statement conflicts with this one:
If you're not going to provide any concrete examples, how are modders supposed to "learn" what you're talking about?

Have a look at Baronius' arguments concerning the G3 fixpack here: http://forums.blackwyrmlair.net/index.php?...c=2968&st=0

Be aware that this discussion deals with what I call "community politics", and what seems to be presented as facts often come from precudices, attitudes and (un)wishful thinking, unfortunately. Statements like "most mods of xy-community are not compatible" and "modders of community yz don't care about compatibility" are bound to be exaggerations, unless the poster can provide proof of his statement. (Further for some modders it's quite funny to read these allegations at BWL, that hosts incompatible mod(s) EDIT: That, in some parts of the IE modding scene, shares the prejudice of a mod site that hosts incompatible mod(s) (Improved Anvil, that per design is recommended not to be played with other mods EDIT: For example Improved Anvil, which is, as far as I understood, a mod that has a concept that is meant as a whole experience of BGII. So, principally, the idea is a mod that changes the experience of the game in a way that in some points would be disturbed by other mods. Therefore, the way the mod is implemented into the game makes it incompatible with some other mods, from a technical point of view. Since the mod is intended to change the game in exact the manner it does, the author does not see the necessity of making it technically compatible in these cases, since such a compatibility would destroy the intended game experience the author wants Improved Anvil to give. Nevertheless, this reluctance and "planned incompatibility", so to say, raised some aversion in some parts of the community. I hope this was the politically correct way of saying what I meant.) and with modder(s) that openly stated that he doesn't care about compatibility with other mods (Vlad with the Never Ending Journey mod. This might have changed, though), but that's a different thing.)

Recommended not to be played with some other mods or with all other mods?

The natural reading of what you wrote indicates the latter (= all other mods) which will make it a false statement about IA and about my recommendations. Is this an example of the sort of exaggerations you warned us against in your own post? (Perhpas you just forgot to add the term 'some' to your sentence, or Perhaps you deliberately dropped it because with that term added to your statement, it wouldn't have the psychological effect you wanted it to have on the innocent third party readers, eh?)

In fact, BWL mods and IA in particular have been victims of such exaggeration more than any other mod. People say false things about our mods; later after being refuted, they claim that they were exaggerating or joking. I'm sure you don't need the links.

But yes, Improved Anvil is incompatible with some other mods, but they are not many compared to the total number of available mods and compared to the huge amount of new content IA adds to the game. Some of those incompatibilities are due to cosmetic changes some of those other mods have applied to the game (which removes the dependencies, as Baronius has nicely explained before); some other incompatibilities are conceptually unavoidable (ex: you can't have the "improved Firkraag" simultaneously from Improved Anvil, Improved Battles and Tactics all in the same installation). In general, the number of conceptual incompatibilities naturally increases when we are talking about mods which add huge amounts of new content to the game. In such cases, the player can play mod x in one game session and mod y in another game session and it's not the end of the world. All this said, I'm always willing to cooperate with other modders to remove incompatibilities as long as they are removable without sacrificing any content of the either mods. aVENGER and I have nicely done this kind of cooperation with each other.

Edited to fix a typo

Sikret: My above statement concerning Improved Anvil was poorly phrased. I edited the post.

Because I've only found deaf ears in the past. I've no time to repeat the same thing again and again. Also, I hope you know that concrete examples only confirm a point, but they aren't sufficient to describe a general problem. Unfortunately, several problems are of general nature. (That is, there may be 2 examples today, and there will be 10 tomorrow. No one knows.)


Jastey already provided a link to my long post, please also read that one. I'll repeat only one important point here:

Dependencies can be area script names, items, stores, and even creature alignments -- practically everything in the game. If a dependency is missing (was removed or changed), entities that refer to it will be broken -- this leads to bugs in most cases. A mod should have exactly as many original game dependencies as it requires. (This may sound trivial, but it's not: UB v15 changes an inn's scriptname for "cosmetic" reasons -- and its readme says it's a fix -- which broke ToD v1, and *still* breaks any mod that uses the original scriptname. So this is an example of an unnecessary change -- it's not required to realize UB's novelties, because UB could use the original script name, even if its name is inconsistent with the area resource name. It's a harmless inconsistency, and "fixing" it breaks mods compatibility with the original game itself.)

A fixpack that is meant to be a standard part of any installation should take much more care. Its primary goal isn't to introduce various novelties, rather to fix unambigious problems. It's nice to identify "illogical" things as well (and other less crucial "problems", "issues"), but it must be done very carefully. Exactly because every change you make in the original game may affect the dependencies of any other mod, and thus possibly break any other mod.

Not all dependencies are of the same type. Some of them are more sensitive cases. For example, *removing* items after a given stage of the game (items that are normally kept in the original game) is a very serious hazard. (Concrete example: Sekolah's Tooth of G3FP broke Improved Anvil. It's now fixed, but there are still many items of the same type removed! What if another mod wants to use any of them?). One of the main points is, fixes (and basically any changes of any mod, not just FP) should be reviewed from dependency aspect as well, and if added, they must be documented on data level as well. (TP2 isn't sufficiently user-friendly as far as self-documentation is concerned.) However, reviewing the changes and reviewing & splitting e.g. G3 FP would require much work, and the authors rather spend their time to fix the continous consequences of these problems (and to identify more "bugs" in the game) -- instead of considering my advice. Of course, it's possible to solve specific issues caused by dependency problems (e.g. by modifying the mod's code, or maybe FP's code), but FP's size has grown so much that now it's uncontrollable from this aspect. If a modder wants to undertake that he or she will fix his/her mod each time G3FP causes a collision, well, he/she is free to do so. (Check the parts of my long post that deal with "fix a fixpack's fix". Isn't it a big strange that mods have to *fix* a *fixpack's* changes to avoid issues?)

Many types of big/complex mods always have a high number of dependencies. Such as Improved Anvil. Since dependencies are the primary things that determine compatibility, it's much harder or impossible to ensure reliable compatibility with other mods in these cases. Sometimes it's best to instruct players to use the mod during different games. Simply because the risk is so serious. (Though players often tolerate bugs that are not so crucial. Please check the relevant part of my long post about why mod authors can't allow "partial compatibility" so easily.)

Consequently, it's annoying when some modders simply ignore our arguments and keep harassing with their "technically compatible code" mania. Compatibility is much more than code. A (technically) good mod is much than good code. If someone cannot or doesn't want to understand all this, at least shouldn't spread false information about mods or keep harassing us. We're open to address specific cases, but sometimes our answer is no -- not because we don't like the other mod, rather because it has a *very* good reason such as high risk due to dependencies.

You asked for guidelines, here are some other that could improve mod development process but I don't expect anyone to know them (even I haven't yet fully specified the exact details of their application): (1) Precise design (2) Continous documentation (3) Proper verification. If you don't mind, I won't detail them. I might write a guide some day, I don't know.


No, they don't conflict. By saying "let's just keep it up", I said that solving problems (such as incompatibilities) should be restricted to the same way as it has been going so far: modders can contact each other to cooperate in specific cases, i.e. to solve issues. (A change could be, for example: I could write a tutorial that would tell more about how these issues could be avoided even before the mod is released. So many of the issues/bugs wouldn't appear at all later. Of course, my long post about G3 Fixpack as well as this post includes such information already, not too much though, but important points.) The point is, many more bugs and problems could be avoided before the release of the mod if those guidelines (e.g. about dependencies, though there are non-technical guidelines as well) were followed. Instead, many modders say that the current situation is perfect, i.e. that "if an incompatibility appears, modders contact each other and solve the issue". Wouldn't it be easier to avoid these bugs even before they appear? For example, G3 FP is still a source of many possible bugs, it's just a question of time when it will cause problems with a new mod.

As for learning, I specifically referred to learning more IE modding (e.g. in a specific field) before making determined judgements. Sometimes certain contributors (e.g. of G3 Fixpack) defend points which they obviously don't understand, just because it was told by their favourite modder. (Concrete example: when IA released, CamDawg brought up an incompatibility issue with Delainy. Of course, without actually testing it in practice -- this is typical to some G3 authors as Sikret has said, i.e. they try to guess many things just by taking a look at the code. The statement was incorrect, i.e. it wasn't incompatible with that part of Delainy at all; even CamDawg admitted it. The point is: at least 4 people -- some of them in a trolling way -- were supporting CamDawg in the discussiion. Jastey was the first who actually sacrificed a little time to try it out in practice. But this wasn't a unique case. IA was attacked countless times by users -- including modders -- who have never tried it and some of them apparently knows much less about modding than Sikret, yet their posting style reflects "I'm the man". Examine and study a problem first, before you undertake to make a judgement!) Similarly, some modders just accept the word of others unconditionally, without actually doing own research. (In many cases, this would be possible, yet they don't do it. And this can lead to bugs in their mods too.)


In case it's still not clear:

I don't want to force anyone to make mods the way I recommend. All I suggested is understanding that the motivations behind certain decisions of BWL modders have valid theoretical and technical roots. Or, if someone wants to close his or her eyes and ignore what we say, then at least peace should be kept. (Show me one BWL modder who has made such comments about others and others' work as TheBigg, Nythrun, seanas, MajorTomSawyer, Drew etc. does/did. Many of the statements were lies. Not exaggerations. Lies. Is this really needed, ladies and gentlemen?)

And, you see, this is exactly why some BWL modders (including me) refuse to "cooperate" sometimes. (You present incomp. as something negative, yet it's a natural consequence of certain things.) This "incompatible mods" idiocy is exactly what new (but not just new) modders should not believe without conditions, and do their own research. Unfortunately, way too many modders have believed that idiocy already.

If "compatibility" causes serious risks in a specific case, it should NOT be forced -- that's the point. If playing two mods in different games is the best for players (because there will be many less bugs), then it's good, and not bad. But, of course, those who only make small (and probably very good!) mods and can't accept that some players will prefer a bigger mod, will come with this "incompatible mods" idiocy when the author of the bigger mod doesn't want to give up concepts in his mod to ensure "technical compatibility", let alone mods such as G3FP which break compatibility with the original game (and as such, automatically mean risk for all other released and future mods). Sometimes "conceptual" and "technical" aspects overlap. E.g., when there is a very high number of dependencies of the same type, sometimes it's better to play the mods in different games, even if they aren't conceptually incompatible.

Has anyone been thinking about why IA works seamlessly and has had a negligible number of bugs compared to its size & complexity? Not just due to the proper verification, but also because it precisely handles compatibility!

Ensuring compatibility between two mods in a *specific* case does NOT necessarily guarantee that problems of the same nature won't appear between the mods later. Simply because *specific* technical changes address *specific* issues. If the general source of problems still remains present, it makes little sense to keep fixing the problems forever. Because it's *sure* that there will problems all the time.

Should ALL present and future mods who use that tavern in City Gates contain a check for Unfinished Business?! (Instead of UB following the guideline about dependencies...) Wouldn't it be easier to write reliable, as "dependency-proof" mods as possible (so other mods wouldn't need to fix what we messed up) ?

Sometimes forcing two mods to be played together (forcing "compatibility") will do more bad than good. When the problem can't be solved neither avoided (e.g. in case of a fixpack which a player always installs), one of the mods (the fixpack) must be designed and implemented according to very strict guidelines to minimize the general risks!

Partial quoting is unfair. I was hoping my explanation in brackets would explain how I meant that remark. It was an exaggeration, but did not contain valuation of whether it's good or bad, despite how much you read into it, Baronius.

EDIT: Edited the above post again. I agree that the original phrasing was not good.

Well, with all that explanation I've given here and in other topics, I just wanted to make it clear that certain modders often use "prejudice" or "personal preference" too when they don't understand the proof (or they understand it perfectly, but simply hide their heads in the sand). And they try to imply to others that the proof does not exist at all, while the proof is there, they just try to make it ignored by others. Which is sad. Sure, it's much easier than sacrificing time and energy to understand the theoretical basics behind the practical statements of Sikret or myself. (Or to admit that they were wrong, and thus they would need to alter their mod completely.)

It's possible that sometimes we don't attach a complete proof for each statement, simply because it's very obvious, and Sikret also said it somewhere: one just have to search, and will find plenty of proof everywhere. For example, it's easy to find concrete examples to confirm the fact that G3FP's complexity isn't handled correctly and it causes bugs & problems, due to the insufficient verification process and due to too many dependencies that are manipulated unnecessarily. Ymarsakar's experience is just one. As Sikret has said, the number of bugs in each release of FP is another proof, forum topics are the evidence. Third, my long post about G3FP also lists several examples (consumed items, manipulated alignments etc.). So when CamDawg or anyone demands concrete examples, there are many. And the general source of problems will produce even more.

But it isn't just Ymarsakar who felt that my general explanations (e.g. in that post) are valid. It's enough to see others' replies as well. Some of them are players, who know less about IE modding and computer science than IE modders. Yet, they do notice the *proofs*, which existence is interestingly denied/ignored by those certain IE modders themselves. These players do see the consequences, and don't keep demanding "concrete examples" to hijack the situation from its real problem. Just see Iroumen's posts, or this post of luan. This post of Iroumen is also a very good example. Pure common sense. While I might explain things in a more complicated way sometimes, the aforementioned posts don't. I can recommend them to anyone who thinks there is no proof to my statements.

I read the post jastey linked (well, most of it anyway... no offense, but I think the Communist Manifesto would be a shorter read ). You have some valid points. Alignment Corrections could certainly be an optional (non-fix) component. Rather, there are probably some invalid alignments that are definitely fixes and others changes that are more subjective. This may, in fact, have already been addressed.

All of the other things you mentioned can be (and probably are or have been) dealt with in the normal course of continuing development. As for methodologies, well, those will always differ between developers. That isn't a good enough reason to dismiss an entire mod, or, more abusively, an entire modding community. I doubt every modder who hosts a mod on a particular site shares the same development methodology. But as jastey suggests, this seems like more of a political debate than anything else.
I don't see what the big deal is (or was) about this. Given this knowledge, either the Fixpack can leave the item as is, or IA can spawn its own key. Doubtless, you say "but there are other issues" but it's a finite list of issues and therefore, a list that can be addressed and resolved. [And later on, you even seem to suggest this has been fixed already (but somehow it "doesn't change things"...?).]

I haven't read the Fixpack's documentation in depth but what little I glimpsed at seemed to be fairly verbose. Documentation can always be improved though (something that developers sometimes pay little heed to, as they're too busy developing). Also something that's not a major issue and gets addressed in the natural development cycle.

One obvious question springs to my mind. Why not just install the Fixpack and develop your mod based on its adjusted dependencies, rather than develop your mod on an unfixed game and claim that the Fixpack 'breaks' your mod? I know you have probably got loads of arguments against this approach, but one could produce just as many for it as well.

As for your (rather vague) mod development guidelines, they're loaded with subjective terms like "precise" and "proper." You can argue for or against any mod fulfilling or failing those criteria, based on your personal biases. (And by your own admission, even you "haven't yet fully specified the exact details of their application".)

A lot of your other examples seem aimed at certain people, some of whom I'm not even familiar with. Nor am I arguing for or against any particular mod. I'm rather new to the modding community and would prefer not to get involved in that kind of mudslinging. It just seems a bit bizarre to me so I'm trying to understand it, but that probably won't happen.
Ironically, the game text update is considered one of the most problematic components even by the Fixpackers themselves (see various posts on G3 re: correcting it, etc.). From what I understand though, this was taken from Baldurdash almost without modification.

Any large program or mod will have bugs. If not, perhaps few people are using it. Maybe it's been around longer. Maybe, just maybe it was better designed, but the fact fewer bugs get reported (if that's true) isn't necessarily prima facie evidence of that. It would be nice if the BG2 Fixpack tested cross-compatibility with every single BG2 mod out there. This, of course, would be absurdly impractical, even if they had a huge staff of testers. And finally, as everyone seems to recognise here, you will always have potential for incompatibility. If I decide to change a minute detail, like a line in a script of a single creature, and modder X somewhere, perhaps years ago in some mega-mod, has already done this or done something opposing, well right away we have a conflict. We don't need to delete some key or other "dependency" to get that. Unfortunately, there's little way of knowing this until someone happens to hit the exact combination that will trip the conflict and then hopefully, either the modders can resolve the conflict or document it as unresolvable. But that shouldn't involve wholesale dismissal of the conflicting mod (or as I said, modding community comprised of many individuals with differing viewpoints).

I couldn't withstand here. Really, what could be the problem with amending strings?



And it should be so, as Kevin made a good work on it.

Intro: I'm not g3 modder, nor bwl modder, nor (insert any other comuunity here) modder. I prefer to talk to people / do things whereever it's convenient for me, and my point of view is not inspired by some Big Modder, whom I trust without questions.
(hopefully it will save me from being consumed by one side of the Force and thrown into Blood War)

And my remark:
Baronius, not including things into a fixpack (a fixpack, not the fixpack), because some other mods could use them is not an argument. If mods rely on bugs, the mods should be adjusted, not a fixpack. I'm sure there are plenty of issues adressed by baldurdash, that could make other mods not function as they're supposed to if they will not be taken into account. But what consider a bug is a way another question, and I agree g3fixpackers sometimes overdo things.

Vlad,

It is not so much that it doesn't work, it is more that the older mods like Unfinished Business that fixes some of the same things and it causes conflicts when both are installed.

It's one of the main complaints that you have often made Vlad. When I pointed out a bug in a mod that a modder updated while having BDash 1.5 installed (now that the FixPack is out there is a bug/conflict), he said 'Oh the joys of modding other's work'. This and other mods need to be updated to work with the FixPack. I know you don't have the time or energy to keep updating your mod to work with all the others. I think the FixPack is a good idea, but (although good) has many of the 'fixes' that are subjective. I wish that the core of Fixpack and Baldurdash v1.6.4 would merge and the rest in optional components (I know I wish for many unlikely things like that 'Good' would always win, that I have the perfect life, and all mods are fully compatible).

Keep up the good work, Vlad!!!!

You have apparently missed the point as did the other poster when he wrote:


The point which you (both) missed is that many of the modifications the BG2 fixpack applies to the game are not really "bugfixes" at all (despite what the fixpackers claim); they are rather subjective arbitrary (sometimes cosmetic) tweaks. (And no, we don't develop our mods on an 'unfixed' game; we use Baldurdash as the base and we fix whatever other bugs baldurdash has not fixed in our own mods.)

Other reasons for which we do not support BG2 fixpack or do not base our mod developments on it are discussed in the related other topics. I suggest people to read other related topics before sending comments which have been repeatedly answered before. We seem to be falling into repetition loops again. I don't think that I will send any other post to this topic because everything mentioned here have been addressed to before.

Political discussion or not: it's not me who questioned the technical justifications behind someone's statements. (In other words, accused others with "prejudice", "marking mods incompatible that they don't like", and so on.) And, of course, spreading malicious lies.

Yes, "precise" and "proper" are subjective terms, which mean I can imagine how they could be improved, i.e. design could be more "precise", and verification could be much more "proper" than it is in case of several mods. The fact they're not fully specified just means I haven't written any complete specifications, descriptions and/or guides. It does not mean that I don't know what concrete details should be changed and developed. Otherwise I wouldn't have brought it up at all. And you can see that I said I didn't expect anyone to know them. They were just presented as a fact, and I don't expect e.g. G3FP developers to follow them -- exactly because of what you said, i.e. that they aren't well-specified. I just presented them as a fact, as something that is present. On the other hand, the meaning of other points (continous documentation not just in TP2, drawing attention to interfaces and dependencies, etc.) are obvious to everyone.


Exactly. That is why proper design and implementation is required. ("Following certain guidelines.") While I didn't want to detail many of them, I did describe one of the most important ones several times. It's about drawing attention to possible data-level interaction. In other words, what dependencies to use, and how. In case it's still not clear: proper design decreases the probability of bugs that you make during implementation. You could ask again: what is "good" design? Well, one aspect was given already: draw greater attention to organize how your mod applies its changes on the game -- this is strongly related to dependencies. (So if it's *better designed* it WILL have *fewer bugs*.)

Exactly. Two points:
(1) Data-level dependencies are only one of the things that determine compatibility. (There are object-level interactions as well, for example.) However, since it doesn't require a too skilled modder to understand the importance of dependencies and design his/her mod according to it (and since such things can be examined much more easily than object-level interactions), this is really a must for every mod.
(2) Exactly as you say: even a minute detail can make a difference. (I think I've written "one bit" as an example in that very long post.) This is exactly where the design process has enormous role. Simply because good design (or, more specifically in our concrete case: good solutions to apply changes, few dependencies) allows the "easy to change" principle of software technology to be better applied. (Again, understanding that in details isn't a must. However, here is a simplified, "common-sense" explanation for those who are interested: if there are few dependencies, the probability that other mods will collide with yours is smaller! In other words, the chance that another mod uses the same dependency as yours is smaller -- because you have less total dependencies!). This has been practically proved in industry as well. To simplify it in our concrete case: try to have exactly as many dependencies as your mod needs. If it's too high or another mod has many same dependencies (often, this is the case for "conceptual incompatibilies"), they shouldn't be played together to avoid constant collision and problems. (Consequently, a fixpack which can't be incompatible with most mods should have as few dependencies as possible -- while also fulfilling its goal, of course, i.e. fixing real problems.) I hope that now you see that future bugs aren't completely random or unavoidable: their chance can be decreased.


Let me tell some counter-arguments then, using G3FP's case.

(1) As I've said, it's really suboptimal that a modder has to override the changes of a fixpack in so many cases. Sometimes, very many lines of WeiDU code may be required. And at each new release of the fixpack, check what has changed in it (because "new fixes are added to each release"), and which of the (probably subjective) "fixes" may break the mod. Beside the principle itself ("fixing a fixpack's fixes???"), there are two problems here:
(a) Modders who support fixpack are obliged to check FP's every bit (which is a LOT of time) each time a new FP version is released. Or they just wait for a player bug report -- more comfortable, but we at BWL don't favour this solution.
(b) Modders who are less skilled in WeiDU are in trouble, because some of the fixes to override G3FP's fixes may require advanced code. I know G3FP and other people who are more skilled in WeiDU might help, but eventually the modder has to create his own adjustment code. I know it's nice to motivate more modders to improve their WeiDU skills, but some modders just don't have time or energy. It's very unfair to expect from a modder to learn such WeiDU things which normally he/she would never need in his/her mod. (And it's "funny" what we can see in that thread I remember in G3FP forum -- "I hate this FIX" -- that is supposed to deal with negating FP's fixes in mods. The only thing it can offer to these less skilled modders is a cynical statement: "Well, that's okay too. You can play Baldur's Gate 2 without even the official patch if you want to to - the game will crash more, and lag more, and have more chances to muck up, but if you're getting by without it, then go have fun." Which isn't just arrogant, it also contains misleading information***)

(2) As we know, very many users (including myself) believe that G3FP contains many ambigious or subjective changes (and it introduces them as "fixes"). How can we expect a modder to use a fixpack as a basis for his/her mod, if he or she can't agree with several changes of that fixpack? Should he learn all required WeiDU skills and spend hours to find and negate these problems?! And as others have already said, G3FP is (interestingly) a very dynamic project, which changes. How can a mod be based on something that constantly changes in an unpredictible way?

(3) Generally, it's reasonable to expect that many modders -- especially starter modders -- will develop their mods based on the original game. All or most of us have played the game in its original form many times. That is what we know. Replacing everything with an unofficial gigantic "fixpack" is possible, but how can we get familiar with the immensely high number of changed game aspects? It's reasonable to believe that when creating the mod, the modder naturally has the pictures of the original game in his or her mind. I don't think a fixpack should override compatibility conditions of all mods with the original game, to such a giant extent.


To sum up:
1. G3FP contains a lot of "fixes" that are not fixes at all, rather subjective changes. As I've detailed it in the very long post, the arguments are very problematic: such as guessing developer intent, finding "illogical" things. So this is the huge conceptual problem here.
2. Unfortunately, G3FP affects very many potential dependencies, as a natural consequence of the lots of changes ("fixes"). So the subjective, ambigious "fixes" also greatly increase the probability of technical incompatibilities !!!
3. There is no "proper verification" (which would at least decrease the number of bugs caused by the too many affected game elements and dependencies). As Sikret has said, G3FP developers mistake players for testers. Sure, some players like their names to be carved to Credits, but again, others don't feel they should be testers and they won't install G3FP. The developers of G3FP focus on code too much, they are trying to guess many incompatibilities based on code, *without* practical tests. Sure, it's impossible to test everything, but due to the huge number of miscellaneous questionable changes ("fixes"), even it's hard to make typical, well-defined tests. But no problem, players will be good testers!


*** The aforementioned quote from the thread in G3FP forum ("I hate this FIX") implies that G3FP fixes so crucial bugs that without its use, the player will *surely* encounter serious bugs. This is nothing else than ridiculous propaganda. And blackmail as well. To sum up, it says: If you don't want or have no possibility to improve your programming and WeiDU skills, then undertake its consequences: your game WILL crash and will have bugs!. What sort of behaviour is this?

It's incredibly funny that jastey (one of the greatest defenders and representatives of G3FP), exactly jastey, did NOT notice any bug when playing Baldur's Gate II long ago:
jastey's post
Don't get me wrong: I don't want to say there are no critical bugs, but how can anyone say nowadays that all those new, ambigious "fixes" of G3 Fixpack are crucial to avoid bugs?! Generally, how can anyone believe that the game still has so many "bugs" to be "fixed" that it justifies the mandatory presence of questionable, arbitrary "fixes"?! (Which, on top of it all, may cause bugs as well! A fixpack which causes bugs.......!)

Oh, it's so simple, in my opinion. You always install Baldurdash with the Text Update just right after installation of the ToB patch, i.e. before any other mod, and you are set. Just refer to Baldurdash as a supplement of the ToB patch, and ignore everything what others say.

and you seem to miss the second part of my post.

you see, not everyone uses your mods. Should all players who don't use them continue playing with bugs?


Baronius,
1 - This is a subjective opinion, nothing more. There are changes in bg2fixpack that I personally do not consider to be bugfixes, as well as there are such changes in baldurdash-weidu. Now we have 3 sides - badurdash developers, bg2fixpack developers, and me. Who is right?
2 - as I have said, potential dependencies should not matter for a fixpack. Even if all the mods would use some buggy creature - a fixpack should fix it, because it's a fixpack. Question "is this creature really buggy or not?" is another question, and there is no objective opinion about it.
3 - cannot say anything, I don't know how things are tested and introduced in bg2fixpack.

No, they shouldn´t, they can install all fixpacks they want and play "fixed" and "cosmetically changed" game, but in that case the whole discussion is pointless I believe. Nobody is forced to use our mods.

It is not immediately clear to me why fixing "cosmetic" issues is objectionable. If on one occasion Irenicus inexplicably turns up using an upside-down neon green gnoll avatar, I can quite easily smile and say "oh, that's just cosmetic!" and play on, but it's probably still a bug and personally I'd lean towards doing something about it. The fixpack exists not solely to prevent your house from burning down when you run the game, but more broadly to improve the playing experience (in a way which is faithful to developer intent).

1. As you can see, in that post I didn't say BD or BD-WeiDU was perfect, either. However, they don't contain so horribly many problematic "fixes", which means they change many many less potential dependencies.
2. It's so *many* potential dependencies caused by changes that are NOT fixes. These may cause serious problems with other mods.


Three points:

(i) Making a difference between crucial, important fixes and totally subjective, ambigious changes IS possible. Don't say there is no sufficiently "objective" answer to most questions related to these changes. "Is a creature buggy or not?". Indeed, if an ordinary Ogre has an Ettercap animation without any context that would justify it, it's a bug. But if that smuggler is Neutral, it's really not an explicit BUG. (This case is also detailed in my long post, I won't repeat myself.) Again, let me emphasize that most of these changes can cause severe problems for other mods. (E.g., G3FP's Alignment Changes may break Improved Anvil's scripts.) Similarly, if a sword has an incorrect inventory icon (BAM) -- e.g. it shows up as an axe, or a corrupted BAM -- it IS a bug. On the other hand, if its description implies that its fiery damage should be a bit higher (so not the stats, rather the "tale" part), a fixpack has NO right to increase its fire damage even by one single point.

(ii) Even SimDing0 admitted above that G3FP also aims at increasing gaming experience. And didn't deny there are "cosmetic" fixes, either. Increased gaming experience and fixed bugs aren't equal: normally, the effects of the latter one is a real subset of the first, but increased gaming exp. can include much much more than just the result of fixed bugs.

(iii) And, come on, why is that "I *hate* this FIX" thread in G3FP forum? The one which talks about how to NEGATE a fix of a fixpack. I understand you're an enthusiastic follower of the project, Gort, but even you can't deny that everyone knows it very well that very subjective changes are also added.

All in all, it's an unfair attitude to expect from modders to use the G3FP, check all of its changes, and negate the undesired effects with -- possibly advanced -- WeiDU code, instead of allowing them to decide what they want to add to their mod (e.g. by offering a serious fixpack and another completive mod with the giant collection of questionable "fixes", changes and other stuff).


First, because they are dangerous. Unfinished Business v15 changes a scriptname, calls if a "fix". It would be the same incorrect if G3FP did it -- it overwrites a potential dependency of other mods WITHOUT actually fixing anything. (The newly assigned script has no original content in the game.)

Second, because they are often subjective. Many modders might not agree with them, and want to make decisions on their own. Cosmetic changes are nice, but do it in a different mod. But not in a fixpack that you advertise to be *the* BG2 Fixpack, the standard fixpack, the one which is crucial to avoid bugs, etc. etc.

Simple question: why aren't the questionable changes in a different mod? Instead, G3FP developers want/offer modders to *negate* the problematic changes (or those which simply BREAK someone's own mod), possibly with weidu knowledge that the modder would normally never need. All this propaganda also discourages possibly talented players to start working on their own mod.

Why do you want to keep all that stuff in ONE mod? Why do you want to DICTATE modders and players what things are changed in their game? (Maybe G3 and PPG mods won't have to apply these changes on their own? Most of them are mods that are planned to be played with each other in a big mod collection, so they only use not too many dependencies separately. This makes BG2 Fixpack optimal to them, but not optimal to other mods of different type. But this was just a very sudden guess. The exact truth is really a mystery to me.)


Gort, wake up! No offense, but you also seem to be greatly influenced by their propaganda. Let me tell why. (Bold added by me, it wasn't part of quoted text.)

Mods relying on what "bugs", please? -- i.e. bugs that are fixed by the G3FP? That is, so anything "fixed" by the G3 Fixpack is per definition a bug?! So does the work of a modder who believes that a Neutral smuggler isn't a bug rely on bugs?! Does his/her work rely on bugs?! Who decides whether a strongly questionable "fix" of the G3 Fixpack is really a bugfix or not? This is exactly what they try to dictate: "we tell what the exact bugs are, and you must accept it and develop your mods according to that". Ridiculous!

I think you've missed the context here. I'm saying that the purpose of a fixpack should be to fix ALL bugs, not just those that cause your house to spontaneously combust. There should not be some arbitrary line under which some fixes are considered unimportant. It is enough that we must consider "is Irenicus using an upside-down neon green gnoll avatar a bug?" without having to supplement it with "does anyone care?"

People often choose such "arbitrary" borderlines in real life as well. While such a "line" doesn't have a strictly determined "position", common sense allows us to make a difference between things. In other words, the line doesn't have an exact position (it "moves within a small range").

As it was said numerous times, this "fixing ALL bugs" mania just urges G3FP developers to extend their "fixpack" with more and more arbitrary changes that aren't fixes.

A bug usually decreases playing experience. However, lots of "fixes" of G3FP aren't bugfixes. They may correct things which may appear illogical to the FP developers (and thus their "fix" increases their playing experience), but for other players, these may decrease -- and not increase -- the playing experience. This is why strongly questionable changes should not be in the same mod as FIXES.

In other words, the problem with the terribly subjective "bugs" is that while someone has an argument why it's a bug, someone else has a counter-argument, why it's not a bug. G3FP follows the philosophy "if there is any argument to call it a bug, let's do so". (On the other hand, no one will question that a spear with a club animation -- or an item that causes a crash -- is a bug.)

Lots of players are misled, because they believe all the propaganda; that "it's *the* standard fixpack which supersedes all previous ones", and it contains "hundreds of new fixes" -- while in the reality, each G3FP release contains critical bugs (everyone can check its forum for evidence). "Hundreds of new fixes", this is my "favourite" -- you FP developers, are trying to force your mod into each player's installation, no matter at what cost. (If there was a minimal level of modesty in your intentions, you and your supporters wouldn't keep harassing Improved Anvil and wouldn't keep spreading malicious information about IA, Tortured Souls and ANY other mod that doesn't play according to your rules.)

The fact that G3FP may break other mods (the accurate reasons were already detailed several times) just makes the whole situation even worse.

If its developers refuse to reorganize this "fixpack", they will have to undertake the consequences in the long run.