The bug was known for v15 already. Wouldn't it be easier to fix it in UB itself?

[This topic was split from this]

Naturally, and I do wish it were fixed, as well as other issues. I like having UB and QP in my install, and it is rather annoying when well-made, well-liked and popular mods have issues. Hopefully the authors will have some free time in the future - I, for one, am looking forward to it.

UB and QP have been severely bugged for years. The authors apparently have lots of free time (as they spend a lot of time in various forums writing jokes and insults to others); yet, they don't spend 5% of those free time to fix their mods' bugs.

As a side not, a mod's stability is the most important factor for calling it "well-made".

I agree about stability.

....and likely writing insults is more "fun" to them...so much that it has priority, apparently.
Thankfully not every modder is like that.

"Stability" is not the only criterion, but it's the first and the most important one. It's an essential (though not adequate) condition (for me) to call a mod "well-made". I wouldn't call "well-made" a mod which has critical and/or numerous bugs.

Once the stability issues are fixed and resolved, then there are other criteria which I will take into consideration to assess a mod's quality (such as the author's creativity in making quests, graphics, scripts, the nature of tweaks it applies to the game and et al).

One other important factor for deciding over playing or not playing a mod is how willing and quick the mod's author shows himself in fixing the reported bugs and issues.

These flamewars are harmful to whole IE modding community.

It's strange. Even when you are doing something just for fun, you don't have problems with finding your enemies (I don't mean specifically you Sikret ;-)), who are doing the same thing just for fun... But they are EVIL (in addition)!

Maybe each forum (PPG, G3, BWL, Spellhold S...) should have its own Ministry of Foreign Affairs - because it's not fun, it's policy already!

P.S. Pardon me for any mistakes, I'm not a native speaker and I'm arrogant (just fun ;-)).

@Jab

It's funny that you quoted a paragraph which states only plain and undeniable facts, but you decided to interpret it as "Flamewar". However, when some people were writing the most rude and insulting lies about us, I never saw you interpreting their words as flamewars and sending any similar comments in response to them. Are you scared of some people but feel safe to reply to some others?

I think you need to read more carefully (what you want to reply to) before hitting the "reply" button. Misreading my name for Vlad's is the simplest example which can't be justified by being a non-native English speaker (though misunderstanding what I wrote can be justified in that way).

Just my simple mistake (both of you have that BWL modder rank) and argument for you. ;-)
Proceed in your flamewars. I promise, that I will never write it again. - Results are very poor.

No flamewar is in progress in this thread; it's all in your mind. I just stated some plain facts.

If I wanted to get involved in flamewars, I would do it in the true flaming threads in those forums where certain people were telling all sorts of incredible lies about us and our mods.

Trust me, I don't wish to fight against your "plain and undeniable facts" in your "paragraphs".
It's just surprising, that there are ANY fights when it comes to modding. It's hard to earn money or real "social power" in modding. It's just something you do, because you are enjoying it. So why care about "lies and accusations"?

Well, if you intend to study the psychological aspects of flamewars in modding community, perhaps the better question to ask is to ask the liar "why to tell lies and to make false accusations in the first place?" (rather than asking the victim "Why to care about those lies and accusations?")

There may be several interesting answers to that question, but as I mentioned before, you have chosen the wrong thread for talking about these issues. You could ask the question in the true flaming threads on those days and in those forums. No flamewar is in progress in this thread unless you want to turn it to one by continuing to send offtopic remarks.

1) Some people consider this as a competition (or something like that) and/or want to make their site more popular, (so) they want to spread their mods (even by convincing other authors to change their own mods). A few modders even spread lies, just to cause harm to the other author. Or simply due to ignorance, envy or some other thing. They believe they don't need any more knowledge, and that they are right under any circumstances.
2) There are modders who invest a lot of time to their modding work (and this is true to many modders), and some of them becomes the victim of lies and attacks. Reasons detailed in (1) above.
3) There are forum users who have never made any mod, but love reading stupid topics and enjoy "fights". They enjoy the drama, the strain. Some of them prefer a certain modder, and defend that modder's interests/opinion even if they know jack about the topic. These users are the best troll army to support the people who I characterized in (1).
4) There are forum users who believe all the stuff they hear. Everything, even if they don't know the topic. Some of them belong to the group who I characterized in (3). Others aren't modders, and they get misled due to the things they hear.

But what is the answer to your question, "why to care about the lies and accusations"? The answer is above. Modders of group (2) invest a lot of time, and many of them are sensitive to lies (as most people). Jab, a mod is an intellectual work, intellectual property. They invest a lot of time, and is it a wonder they are furious after seeing that the people in group (4) believe all the lies told by (1) or (3)?!

In other words, a person has full right to reply accusations and reject lies about his or her intellectual work. Especially if there are naive users who may believe those lies unconditionally. I "love" the scenario when a modder tells total nonsense or perhaps a subtle lie, several trolls start to support him, but someone dares to defend the mod/feature in question, and what is the result? "You are going to get a heart attack", "You are over-defending it!" etc. Are they surprised that someone rejects lies? But they are hopeless. They enjoy the strain, enjoy ridiculing other's work, and so on. And the envy. Human envy is a big lord.



Version 16 was released, yet the bug wasn't touched. It is about changing three lines of its TP2:



For example, it can be changed to this:



So it has nothing to do with free time. It's about principles (or ignorance, sometimes). Modders often don't realize (or just don't care) that they may break "backward compatibility" when they modify the potential dependencies of mods by altering the original game.

In this specific case, mods that use ar0004.baf will be broken (for example, these mods use EXTEND_TOP in order to summon a creature in ar0021.are). A little illustration, specifically about the bug of Unfinished Business:

An "unmodded" game:




Five mods are installed, Mod1 and Mod3 depend on ar0004.bcs:



If the reference from ar0021.are to ar0004.bcs is removed, the content/plot of Mod1 and Mod3 may be broken.

Mod6 (e.g., Unfinished Business v16) is installed. It replaces the reference in ar0021.are (this is where we "fix" something and actually introduce a bug by violating backward compatibility):



The file ar0004.bcs is now a lonely file among the game resources of BG2. It has no function.

Note that it doesn't matter if Mod6 is installed before or after other mods; if installed, it may break Mod1 and Mod3. It's also important to note that ar0021.bcs has no function in the original game (it doesn't exist), so UB doesn't restore any original but unreachable game content here.

There are several other types of dependencies as well. This was just one example.

The best example for such (and similar) changes is the G3 BG2 Fixpack, of course. These changes cause severe incompatibility risk for other mods, and can't guarantee backward compatibility even with the original game itself. It can be acceptable for real bugfixes where the incompatibility risk should be ignored due to the severity of the problems (in other words, don't make mods that rely on bugs). On the other hand, it's unacceptable in case of subjective changes and quasi-fixes (quasi-tweaks) such as "Keys should be consumed after use" (may easily break certain mods) or "That person cannot be neutral because he is a smuggler and attacks you when you reveal him" (alignment changes may break certain mods' scripts). I brought up G3 Fixpack because it's the best example. But I know the usual reaction: "You don't like the mod so you try to discourage players from playing it" (no comment).

So now I hope it's clear why I keep emphasizing all the time that mods (especially those which are meant to be installed with many other mods, such as fixpacks and small mods) should only modify as much original content as *needed*. And no more. If the mod has lots of dependencies (such as Improved Anvil) due to its nature, its compatibility with other mods should be examined with even more attention, and proper documentation should be provided to help players and the author too (Improved Anvil offers all this).

If an IE mod is a plug, the IE game is the socket. You can imagine what would happen if the standard socket was modified...



Yes, all plugs (i.e., all devices with such a plug) would have to be modified. All existing copies. Funny.

"That is why bug reports and tests are needed". Funny statement. Wouldn't it be easier to build a reliable mod instead of mistaking players for testers and expecting others to change their earlier and current mods as well? (Needless to repeat that G3 Fixpack is the best example: it's not an ordinary mod, it's a fixpack which requires mods to constantly fix themselves to be compatible with the fixpack )


Ensuring backward compatibility can be tough. One of the main problems of big systems (as well). It's not hard to introduce new, shiny features, but what about the software or hardware components, tools, source code etc. that were produced for/with the earlier version of the system/language?

Finally, a concrete example again. Quote from the WeiDU readme:

Yes, that's the only way to solve it. (For those who aren't familiar with this topic: the quote isn't a negative example to criticize WeiDU. It's an example how WeiDU solves a problem -- correctly. A problem that arises quite often in this field.)

I was going to post about how backwards compatibility is only an illusion and accidents are bound to happen even when doing test units, but I think I'll rather take the time to say that I'm sorry for having posted the "not real" post, or any other over-the-line comment/insult I've thrown over the years.

Accidents and problems always happen, but:

1) It doesn't mean we shouldn't care about it (shouldn't try to work on it) just because "it's an illusion anyway" -- especially when it's possible to guarantee it.
2) We're talking about a relatively small system, and with some care, attention, responsibility and cooperation, it's not so hard to build good mods and proper documentation (at least, for experienced modders).

For example, "let's pack all stuff into the mod that we find cool, crashes & bugs will be reported anyway after the release and hehe the forum will get more traffic anyway" isn't the way to go IMO. Especially if the mod is meant to be a fixpack, installed by all players.

I'm deeply reluctant (as a newish observer of all this) to get into a deep debate, but I do feel you're exaggerating. I've written code with/without the BG2 fixpack and I haven't had any problems at all. As far as I can tell, provided you allow in a fairly generic fashion for the possibility that some other mod has modified game resource X (so you don't, for instance, do WRITE_BYTE 0x335c4 0 without checking that 0x335c4 is really what you're after) then it's fine.

Exaggerating you say? Well, not at all. I believe Baronius knows very well what he´s talking about, and he´s definetely trying to show up that some original game bugs (maybe not bugs literally, but some things that were forgotten by developers and doesn´t do any harm to the game especially) doesn´t need to be corrected, because some other mods (UB and TOD are perfect examples of collision) may use the same resources as the fixpack has corrected, but in original untouched form... Why are these so called "bugs" taken as bugs anyway? Who knows, maybe developers intended something we have no knowledge about...

But definitely it´s not exaggerating...

First of all, it's important to note that the severe technical problems of G3 Fixpack are used as an example here. G3 Fixpack has other problems as well -- e.g., conceptual ones such as "guessing developer intent" and adding quasi-tweaks, but they are beyond the scope of the present topic. Nonetheless I will probably mention/detail them after all, considering most technical issues follow from the conceptual ones, or closely related.



I have never said that G3 Fixpack (or mods that make the same technical mistakes) actually break lots of mods etc. On the other hand, the technical mistakes cause very many problems, the practice confirms this.

It breaks/broke certain mods (such as Improved Anvil or Sheena NPC), let alone the global bugs that affect(ed) almost all mods that are installed together with it. There are several mod types that don't interact much with this type of technical problems, but complex mods (e.g., which have many dependencies and interrelations) are very sensitive to the arbitrary changes made on the original game. Needless to say the reasons, they are obvious.

The biggest trouble (beyond conceptual and developer attitude problems): on top of the fact G3 Fixpack already includes severe risks for certain mods types, it's continously changing, possibly affecting new game resources again and again. Iroumen perfectly summarized what I've shown in those diagrams of my long post in the present topic. And what is the consequence?

The consequence is some broken mods, and the constant "obligation" for authors of many mods (and not just complex mods) to keep their work "synchronized" with G3 Fixpack. If they don't do it, there will be incompatibilities.

G3 Fixpack forces modders to follow and support its own arbitrary changes (and forces players to install these changes). If modders don't want those arbitrary changes, they have to spend a lot of time to negate (!!) those changes. If they don't or can't, their mod will either be broken (e.g., think of dependencies -- yes, I'm still on-topic), or conceptually incompatible (because he/she didn't agree with a change).

DavidW, you didn't encounter severe problems for more reasons:
(1) You have no problems with WeiDU TP2, you're skilled in WeiDU and G3 Fixpack so you don't have to spend hours to learn the basics. If you work for a longer time on a code after all (e.g. because of a more complex problem to harmonize a mod with G3 Fixpack), you gladly do it because you agree with the principles of G3 Fixpack. Not everyone agrees, and not everyone has the skills and/or time to spend hours for such things.
(2) Many of the mods you (also) deal with aren't such mods that are too sensitive to arbitrary changes on the game. So in this case it's not hard to implement compatibility and "cure" dependency problems via "reactive" coding. With a few or a few tens of WeiDU LOC.

The problem is that many of you guys there at G3/PPG don't realize (or don't care, though you seem to care DavidW, so this isn't directed at you) that there are OTHER mods as well beside your usual mod types, and these other mods have different structure and complexity. Which means they couldn't be harmonized with G3 Fixpack without conceptual changes or enormous technical alterations even if their authors agreed with G3 Fixpack's arrogance. But it's easier (and reflects big weakness) to reject the responsibility with a comment such as "it's a poorly designed mod, otherwise it could be made compatible with G3 Fixpack". So instead of actually reconsidering the attitude and principles, the developers and supporters of G3 Fixpack enjoy the wide reputation of G3 Fixpack thanks to propaganda it gets (e.g., "the game will crash more..." , or the pinned topics in all gaming/modding forums, telling about "hundreds of fixes" and "Baldurdash is totally obsolete"). They abuse this reputation, and mislead new players, e.g. discourage them even from trying mods such as Improved Anvil, Never Ending Journey, or Tortured Souls (mods which authors don't share their viewpoints and don't follow what they want to dictate).

Furthermore, not all players like that all things are dictated to their fixpack installation, because they also realise the severe technical risks. And it's present all the time, as we can see. Incredible, players complain due to subjective changes -- AGAIN. It's a mystery why such stuff can't be put to a different mod, to a mod similar to Improved Anvil, Grey Clan or any non-fixpack mod. It's a mystery why G3 fixpack creators want to dictate a default installation to players and brand-new default conditions/environment to modders, offering them the "possibility" to *negate* those changes in various ways. I've brought this up many times I know -- it's a mystery for me, and I guess many others.

Let me quote a post by Caedwyr (highlights added by me):


Caedwyr admits that older fixes might have caused issues. It's OK, but he also admits that their current versions "will cause less issues with other mods/material". That is, he is well aware of the fact that G3 Fixpack code is a possible source of problems. Of course, I know that he would say that modders can post feedback and/or fix the problems in their own code -- but that is what I was talking about: it can be a lot of effort for beginners, and in case of certain mod types, it's not possible!

Shouldn't a fixpack work like this: it's installed after the official patch, and modders can develop their own mods peacefully, players can be sure they don't have to "comment out lines". A fixpack that doesn't have to touched, its documentation and code (both are hundreds of pages) doesn't have to be read by others, etc.

I know I've actually been writing about concepts and attitudes in the latest paragraphs above, but 80-90% of the severe technical issues directly follow from these conceptual problems.

It's a mystery why those arbitrary changes have to be forced into G3 Fixpack, and thus forced onto the installations of hundreds of players (with the support of "this is the only stable, and practically the only usable fixpack -- the only option for you" propaganda). I have some guesses but I don't want to share them.

Finally, three quotes (highlighting added by me):


So players have right to request/convince G3 FP developers to remove arbitrary tweaks that shouldn't be in a fixpack at all? No comment


Of course, now kulyok would certainly say something like "it was back then, it was an old version, in fact a beta, now it has been improved and it doesn't keep introducing bugs anymore". This quote ("My only concern...") was just to reflect: it's obvious that the bugs started to come from the beginning, and G3 Fixpack's development principles haven't changed since then. It's also a mystery why a fixpack's beta can "start introducing bugs". Beta or not, it's meant to be a fixpack, so even in worst case, it may not fix all bugs it intends to fix, but to introduce new bugs?



(No comment for this one)


(Sources: Caedwyr, kulyok, Wounded Lion)

The is pretty good work, guys. You're actually having an argument without any opposition present.

So why don´t you write your opposition answer here instead of that ironical sentence you just did I wonder...

Because this is all daft and I don't care?

If you don´t care and all is daft, then just simple don´t answer at all. That´s the best thing you can do when you have nothing constructive to say.

Expressing my contempt for the proceedings is a perfectly valid response.

If you say so...

Replying rather late (I've been away). I'm only really following this out of curiosity but here goes:

I think you've been making three criticisms of Fixpack but we're only really talking about one here. The two we're not talking about are (i) "subjectivity" and (ii) "lack of testing". As it happens I don't really buy either of those objections, but your third point about dependencies can be made without reference to either, so I'll put both aside.

On the main topic: as it happens I agree with you about the Crooked Crane area script (I don't think it can really be called a bug, since it doesn't break either the vanilla game or UB itself, but it does seem to be a mistaken choice from the point of view of compatibility). I also agree with the other example you've used quite often, about keys being used up (in an earlier version of FP, before my time in fact). I mildly tripped over the Crooked Crane issue myself in a beta version of SCSII, in fact.

But I actually think these are special cases (one of which isn't actually in FP, of course; the other one of which was acknowledged to be a mistake), and what's special about them is that it's virtually impossible to work around them with good coding. Pretty much everything else in FP can be allowed for by appropriate coding. I think this is something you noted yourself in your reply to me:


I'd only amend that to say that I'm not skilled in G3 Fixpack (I've hardly even looked at its code). But I did go to a lot of trouble to write a mod that made as few assumptions as possible about the underlying structure of the files etc that it was dealing with. And I agree, that's considerably harder than just doing basic copy-replace in WEIDU.

But - and this is probably the key point - it's necessary anyway if you want to write a mod that's compatibility-friendly in general, that's not going to crash when confronted with the plethora of NPCs, quest packs, item packs, tactical mods, kits and tweaks that people use. These things modify vast chunks of the game in various different ways and you can't guess what they'll change and leave alone, so if you want to be compatibility-friendly you have to write advanced WEIDU code. (The original version of SCS I was much more basic, and choked badly on any install except my own - it was about the first lesson I learned after releasing the mod publicly.)

I think (I'm not sure) that it might be fair to say that FP isn't a good platform for beginning modders; but then, it's not designed as a modding platform, it's designed as a fixpack. I can also believe that it's not ideal for modders who aren't in any case particularly interested in large-scale compatibility (which seems to me to be a perfectly valid design choice, just not one I share). But I do think that (i) writing seriously compatibility-friendly code in an era of hundreds of complex mods requires reasonably sophisticated coding, and (ii) once you're doing that kind of coding, FP doesn't cause any further problems.

One case study: I wrote SCSII on FP v3. Once I wrote it, I tried it on an unfixpacked install, and on a BD install; it worked fine on both (I think there was one nonexistent file that had to be checked for on an unfixpacked install, otherwise no problems). It's also worked fine on subsequent versions of FP. I'm not showing off - just trying to demonstrate that it's doable without a detailed knowledge of what's in a given fixpack.

UB has many other serious bugs even if we put aside its issue with the Crooked Crane area; and it has those bugs for years. That's why when Kulyok said that it was a "well-made" mod and it's authors have not found "some free time" to fix it yet, it looked such a weird and out of place comment.

Note that this thread is not about the G3 fixpack. Baronius brought up the fixpack only as an example to show that creators of UB are also following the same modding philosophy or method (or whatever we call it). Releasing seriously bugged mods(= mistaking players for testers), not giving serious attention to testing before releasing mods, and sometimes not even fixing the bugs properly despite the bugs being reported.

As I once mentioned elsewhere, some of the bugs in the G3 fixpack were so easy to detect that it wasjust enough for them to run the game and test (for example) the corrupted spell by casting it for one single time; nonetheless, such easy-to-detect bugs were all there in their publicly released version. This is a solid proof for the fact that they either don't test at all or have miserably incompetent testers.

As for giving prority to large-scaled compatibility and spending long time to write codes which do not assume any of the vanilla game's dependencies, I agree with DavidW that it's a choice or a decision a modder makes. However, I beleive that there are other factors which influence the rationality of either choice:

Authors of smaller mods need to give higher prioirty to compatibility issues, because no one will play their mods if they prove to be incompatible with a big number of other mods. Moreover, the small size of their mods will make the whole process easier for them.

Authors of big mods, on the other hand, can use their time in more optimal ways by adding more and more new content to their mods, testing, bugfixing, etc.

For example, consider Improved Anvil. There are many players who play IA virtually with no other mods installed (even without mods which are fully compatible with IA). Why? Are they crazy? Of course, not! Improved Anvil adds so much new content to the game that the player not only doesn't feel the need of installing other mods, but also is not willing to break IA's overall atmosphere by installing even those mods which are completely compatible with IA.

Now, assume that I have (say) 15 days of free time to work on IA's next version. Is it an optimal use of time for me to spend these 15 days creating complicated codes to make IA compatible with a few other random mods? Or is it a more rational use of time to spend the time to add (say) two other big quests to the mod and test them? For me, the second choice is the rational decision.

And it's not merely a matter of limited time we have to spare. Even if we multiply by 3 the number of days in the previous example and assume that I have 45 days of free time to work on the mod, is it better to to spare that time on making the mod compatible with more smaller mods or will it be a better use of time to spare that time to add (say) 6 other big quests and adventures to the mod, again the second choice is the rational one for me.

They are interrelated to a certain extent (dependency and compatibility problems are usually the result of bad decisions and egoistic principles), but you are right, let's restrict the scope of the discussion to technical dependencies. (By the way, I think I criticize FP as a project in more than three aspects... For example, the attitude of its developers -- the enormous campaign to convince all players to use it, even via unacceptable statements such as "otherwise your game will crash more". This always reminds of someone who seems to be a big supporter of FP while -- earlier -- admitted a funny thing. But enough of this, it's offtopic.)


If its developers didn't force several very problematic things into FP as "fixes", there would be less dependency problems. A proper change on a broken resource is indeed a fix, but modifications such as "the developers meant that NPC to be neutral good" or consumed keys aren't. On top of it all, such "fixes" cause dependency violations with a much higher probability than real fixes, due to their nature. To sum up, it's not designed to a be a fixpack, rather a "comfort" pack. Such a thing is very nice, but it's simply not a fixpack.

So this mod (I don't call it a fixpack) isn't ideal for beginners (and for those who have little time to learn new things), as you've said. This is quite a big problem. In ideal case, the modder doesn't have to adjust too much on his or her code to make it work with a fixpack. The worst thing is, the fixpack introduces a lot of questioned stuff and modders who don't need those must edit their own code to negate a fixpack's changes. So adjusting code for compatibility is one thing, but negating changes of a fixpack (!) is quite ridiculous. If it was a real fixpack (I detailed this point in the previous paragraph), it would be much easier to support it.

I agree that it's reasonable to assume that a modder who wants to make his or her mod compatibility-friendly should have enough coding skills, but:

(1) Why to give even more work for him/her by forcing him/her to study a "fixpack" and negate its changes if needed

(2) Not all mods fit into the category of "many-mod-installations" (I don't say "megamod" because it would mean a different thing in "common" parlance). For example, (high-quality) "monolithic" mods also have their advantages (I won't list those here, the point is: there are players who prefer them), and they don't fit to the aforementioned category. They have so many interrelations and possible dependencies that such a "fixpack" isn't an option for them. It's sad that authors of such mods are often accused of various things, and somehow such mods are always mentioned as "black sheeps" on certain forums, by certain people. Think of NEJ, Improved Anvil, Tortured Souls.

So this "many-mod-installation" is a nice and definitely popular concept (i.e. a lot of players support it too), but it's unacceptable and arrogant to spread rumours about other (e.g. monolithic or similar) mods and their authors in order to increase the popularity of "many-mod" concepts. Statements such as "Tortured Souls is old, and shouldn't be used" to discourage players (let alone the lies about Improved Anvil, etc.) aren't successful, fortunately -- players are clever enough to choose mods that satisfy their needs. (I'm not sure about the motivations of rumours and lies, I guess it's often the fact that the "many-mods" modder is afraid that the player might choose the bigger mod -- hoping for more content -- instead of the many-mods setup.)

All in all, many of the representatives and supporters of "many-mod-installations" show no tolerance to mods that don't fit into the "many-(small)-mod" concept. I understand that most mods fit to that category and it can be considered as some sort of "mainstream", but there are other mods as well, with proper documentation. If that documentation is properly written (or even if it just warns that this mod should be installed alone or with a few other stated mods), there is no problem. Unfortunately, some of these "mainstream" modders feel their concept so superior that they are daring to judge other authors' work and design, often without actual knowledge on the specific topic.

It's a specific case, indeed. I know little about its architecture, but I'm quite sure SCSII doesn't have strong coupling to most resource types of the game (except those which are related to AI). Improved Anvil, on the other hand, is completely different in this respect.

Of course, it's also important to note that beginners have even more problems to build many types of mods (including those types which fit into the "many-mods" category). Several enthusiastic players don't want to start IE modding -- despite their big interest -- exactly because of these problems. I plan to help on this problem in the long run, but the solution isn't precisely outlined yet , so I won't share anything about it.


The general principle (and any technology based on it) is called reflection, and it exists in modern software platforms. Unfortunately, in WeiDU, it requires much coding and relatively advanced knowledge of file structures etc. (i.e. we implement it in the code, for each specific case).

Okay, so I seriously don't want to get into discussions of what's a fix, of who has what attitude, etc. (For the record, I don't agree, but I haven't anything new to bring to the debate.) On the specific topic of dependencies, we're probably approaching the point when it's sensible to agree to differ. But to end on a constructive note: I'm not convinced there's as much time cost to compatibility as might be thought. The cost is largely front-loaded: it takes a bit of time to get the hang of using WEIDU that way, and a bit of time to write the various macros you need to (say) take as input a particular ARE file and output that same file with an extra copy of one of the exists, but once you're in the swing of it, I don't actually think it takes much longer than non-compatibility-friendly coding. So I'd recommend it - though, sure, there's no moral requirement for it.

Almost forgot:



More than you might think. If you want to write good targetting AI, for instance, you've got a coupling (if I understand the way you're using the terminology) to every item in the game that gives immunity to an effect. If you want to edit the "generic" mage AI scripts, you've got a coupling to a couple of hundred CRE files.

Then the coupling of SCS2 is stronger than I thought, sure. Still, it allows quite a systematic approach (because you're making changes of same/similar nature, so it's about loops and such programming constructs), unlike e.g. Improved Anvil, where we're talking about a collection of versatile, multi-dimensional changes.


Coupling characterizes a mod as a whole, it's about how strongly (or loosely) it connects to the game and other mods. Of course, you got it right, it's determined by the number of affected resources (such as third-party ITM, CRE etc. files) and the type & number of changes made on these resources.

I recently came across this issue as I was working on my npc mod. I have a character that moves to the Crooked Crane at one point in the mod. I automatically assumed that ar0021.are would have ar0021.bcs as it's script and coded accordingly. Now I want to have compatibility with UB because there is another quest within UB that my npc wishes to talk about (provided that component has been installed). However, in my testing (prior to installing UB) my character never appeared in the Crooked Crane. It took a while, but I found out that the area script is actually assigned as ar0004.bcs. So what was I to do? Copy UB's method because I wanted compatibility. But I found out about ToD and possibly some others that use the ar0004.bcs instead. So I've devised a solution. Yes, I have a simple update that UB can use and still achieve the results they like. True, mods installed after that ASSUME ar004.bcs to be the area script wouldn't work right. Yet, this is one of those situations that we will never agree on so we should code for both possibilities.

For UB to achieve what they want they can use this exact code (it contains all the tp2 commands to do their component)

CODE

////////////////////////////////
////////////////////////////////
// Restored Crooked Crane Inn //
////////////////////////////////
////////////////////////////////

BEGIN @28

COPY ~ub/ubnull.itm~ ~override/ubcrane.xxx~ //null file to identify this component

COPY_EXISTING ~ar0021.are~ ~override/ar0021.are~
READ_ASCII   ~0x94~       ~area_script~

ACTION_IF (FILE_EXISTS_IN_GAME ~%area_script%.bcs~) THEN BEGIN
COPY_EXISTING ~%area_script%.bcs~ ~override/ar0021.bcs~
END

COPY_EXISTING ~ar0021.are~ ~override/ar0021.are~
WRITE_ASCII   ~0x94~       ~ar0021~

COMPILE ~ub/crane/u!ccrane.d~
USING   ~ub/tra/%s/ubdialog.tra~

EXTEND_BOTTOM ~ar0022.bcs~ ~ub/crane/u!0022.baf~  /* Crooked Crane, Level Two */
EXTEND_TOP    ~AR0021.bcs~ ~ub/crane/AR0021.BAF~

Everybody else could use this code before or after UB and their stuff will be included no matter what script file is used for this area.


True this requires ALL mods that use this area's script to update. Isn't that better than everybody saying 'You update.' 'No, you update.' type of arguments? Let's all update and put this behind us. Then we can post in every forums modders resource threads that when working on ar0021 it is best to read the file for the script reference rather than assuming it is one way or another.

A visual example in text of what happens if above codes are use:

Mod A reads ref and happens to write to ar0004
Mod B comes along (with above code) reads ref copies ar0004 to ar0021 and adds to ar0021
Mod C comes along read ref and happens to write to ar0021

Mod A reads and writes to ar0004
Mod C reads and writes to ar0004
Mod B reads copies ar0004 to ar0021 and adds to ar0021

Mod B reads finds no ar0004 and writes to ar0021
Mod C reads and writes to ar0021
Mod A reads and writes to ar0021

BTW I will link this to the UB forum so that they can use it in the next version. I truly believe they want to be compatible, but not while breaking whatever morals/ethics/feelings they may have on this subject. As you can see, the above code will allow them to re-assign the area script to a matching reference.

No flamewar intended. It's meant to be a solution that we can all agree on.

My piece has been said and until such time as this gets worked out. I will continue to extend my script to the bottom of both ar0021 and ar0004 because I will never know for sure which one will be active on another persons install. I'll probably also read the ref just in case someone decides to be strange and assigns a customized area script with a different name...

Nice solution, plainab. It's "intelligent" code, because it detects the script's name.

However, it's still a reactive solution. It has been done only after a few mods have been broken. And it's a solution to a specific problem. On the other hand, my point was meant to be general, so let me clarify it in such an aspect.

One could argue that this could be made proactive by systematically applying such intelligent codes in mods, but it wouldn't be a widely usable solution (at least without the support of additional tools).

When a mod is tested and its quality is verified, the author and the testers experience certain things (expected and unexpected events, bugs and flaws, certain behaviour and AI of creatures, etc.) in the game. These help the author to develop and refine the mod to a state which meets his or her expectations. The public release of the mod will work according to these expectations.

It's natural to consider the original game as a basis when creating a mod. The files of the game, the dependencies of the game are primarily taken into account when creating a mod. When developing a (bigger) mod and finalizing it, you assume "too" many given things about the game. For example, the intelligent code you presented is for scripts, but similar code could be written for practically all other resource types as well. Let's see an example.

Certain alignment changes of G3's BG2 Fixpack may break Improved Anvil's scripts (note that it isn't a practical threat, as Improved Anvil doesn't support the installation of G3 Fixpack). I remember that Sikret was advised to set the alignments of the creatures in question to the alignments required by scripts. In other words, Improved Anvil would have overridden (overwritten) any previous changes -- including G3 Fixpack's changes -- on the alignments it requires for its scripts. It seems to be a working solution, but there is a problem:

What about the other thousand (or more) dependencies required or modified by Improved Anvil? Should all of them be checked by intelligent codes during the installation or enforced through some sort of "patching" code? This would practically mean overwriting half of the game with "patching" code.

One could argue that you should only enforce those changes which are modified/overwritten by other mods. But what mods? If the installation order isn't fixed, the player might install any mods before the mod in question, so there is no way to know what will be changed in the game by other mods. But let's assume we only want to build on G3's BG2 Fixpack. It's still not an option: G3 Fixpack changes all the time, and even most of its existing modifications are unverified (or even untested). How can you prepare your mod to something which will happen in the future?

In other words, enforcing expected dependencies and using intelligent codes to detect other mods' changes on the game cannot be applied proactively, because bigger mods would have to overwrite half of the game and scan several hundreds of fields to detect changes. So the reactive solution remains: mods crash, mods trigger bugs, mods cause problems -- developers find the problems, and apply specific fixes on their mods to work with each other. Then it's starts from the beginning again.

To cut a long story short, the approach favoured by certain groups of mod developers strongly relies on reactive modding. Again, let's see an example.

G3's BG2 Fixpack applies a huge amount of changes to the game (and very many changes aren't strict fixes). These changes tend to break mods, or at least, they cause mods to work in an unexpected or undesired way. So the developers suggest you to remove the fix through the installation code of your own mod. That is, the G3 BG2 Fixpack requires mods to negate its changes, if those changes cause problems for a third-party mod. This is how its developers imagine it should work:

1. G3 BG2 Fixpack is installed as a base mod.
2. A third-party mod is always developed and tested with G3 Fixpack installed.
3. The undesired or problematic "fixes" of G3 Fixpack are negated by the third-party mod's code.

One of the problems is that negating/removing changes isn't so easy. The changes can form a forest of dependencies with recursive relationships, and without knowing G3 Fixpack in details, your changes might be unsuccessful (and problems might appear in a future combination of mods) or even introduce a bug.

Another big disadvantage of this type of reactive approach is that the third-party mod becomes dependendant from the mod it was based on (e.g. in this case, G3's BG2 Fixpack), so any future changes on the base mod will affect (possibly break) the third party mod as well. The author of the third-party mod has no other choice than checking the base mod's news and events, and revise/extend his or her own work when the base mod has been changed. He or she can never say "At last, I've finished with the most of it, now it will be just minor fixes once per year". On the other hand, the original game is a static system, it doesn't change and thus it won't break mods that are based on it.

In case of our example, G3 Fixpack, one could argue that the third party mod author only have to deal with the changes of the Core component of G3 Fixpack. Apart from the fact the Core component is huge too, there is another problem: while the other parts are optional indeed, most players usually choose "Yes" when the installer asks them about it (why would they skip components with tempting, cool-sounding content). The consequence is obvious: all optional components will be installed too, and the third-party mod isn't prepared to their changes.

The third problem of this solution is that it expects the author of the third party mod to study the base mod (e.g. G3 BG2 Fixpack), and negate/remove certain changes of it that cause problems for the third-party mod. It makes the life of new mod developers even more difficult. Let's see how these things changed with time (in case of a simple or medium-simple mod):

1. At the beginning, you could create a reliable and stable mod (even a serious quest mod) by creating a bunch of item, spell, store, creature, script, area etc. files and adding them to a TeamBG IAP/SFX pack. Such a mod isn't compatible with other mods that change the same files, but it works in the game.
2. Now, we expect an IE mod developer to learn the basics of the WeiDU system, and install these changes and additions to the game via WeiDU. This code is still relatively easy, and even if the mod developer doesn't understand its computer science aspects, he or she can still use a sample code from somewhere else.
3. In the present topic, we've been talking about intelligent codes and mods that enforce their required dependencies by using code; I've been talking about the developers of certain mods (such as G3 Bg2 fixpack) expecting third-party mod authors to ensure compatibility with the G3 Fixpack... It isn't so easy any more, is it? Is there a difference e.g. between the code you've pasted and the complexity of creating an IAP pack?

Don't get me wrong (and before anyone would try to twist my words: no need for it), I'm not saying that IE mod developers should use IAP. I'm merely trying to express that the expectations (demands) towards an IE mod developer have increased a lot. It's not enough to thoroughly test the mod, certain mod developers would expect others to understand data types, bitwise manipulation, variables, programming language structures etc.

For example, let's see our previous example again, G3 BG2 Fixpack. I ask it, why can't it work in the following way:

1. G3 BG2 Fixpack is one mod, with the strict, unambigious fixes. Most mod developers could easily support this fixpack without having to study its code or negate/remove its changes via their own mods' code.
2. There is another mod which includes all the questionable, subjective fixes. This would be a bigger mod, with a lot of changes, so those who couldn't support it (e.g. authors of big or complex mods) could still rely on the aforementioned "strict" Fixpack.

This is a big question: why aren't the questionable, subjective "fixes" put to a different mod? I have never got a reasonable answer to it.

Why IE mod development has to be the privilege of those who understand data types, bitwise manipulation, variables, programming language structures etc.? One could argue that there is sample code available, but in the hands of those who don't understand the code they use, it just becomes the source of bugs. And adjusting, extending sample code isn't possible without the understanding of certain fields of computer science.

One could say that someone who wants to be an IE mod developer should learn these things or forget about modding. It's indeed reasonable to expect a certain level of knowledge and user skills for modding, but they are far from what a WeiDU programmer needs to understand and use in the practice.

In the light of the fact WeiDU is a very useful and versatile system which -- on the other hand -- lacks high abstraction and certain important services, my conclusion is as follows:

• Developers of mods such as G3 BG2 Fixpack should reconsider their viewpoint, and think about splitting, revising and thoroughly testing their mod, instead of waiting for players to report bugs (which isn't a problem -- most G3 Fixpack fans gladly do so), and instead of expecting third-party mod developers to use their monolithic fixpack and adjust their mods to it after learning advanced WeiDU skills.
• IE mod development could be made much more reliable and easy. The current system isn't user-friendly enough, so IE modding is currently the privilege of those who devote very much time and effort to learn, and remain active to constantly support and adjust their mod according to the newer and increasing expectations of the "mainstream" of the IE modding community.

He likes the code and that makes me happy. I'm not being sarcastic here.

As to the rest of the post, I take it you have a problem with G3's BG2 Fixpack? (Now I might be a bit sarcastic)

I can understand the concern about changes that make changes to other things. I and a group of others are working on what will become the G3 BG1 Fixpack. There are already things that I plan to offer as a "fix" because they make sense, but they may affect other things within the game. True if an existing mod expects it to be a certain way and I "fixed" it to be different then we have something that's incompatible or workable but not ideal. Was this not true back in the old days, when baldurdash and dudleyville came out with their respective fixpacks?

At that time, if something conflicted, a list of files would have to be made to show what could or couldn't be installed to have limited compatibility with each other. Until one or the other relented and changed their files to play nice with the other. The third party mod usually lost out and had to update their files to go with one or the other of the available fixpacks. Now that something new has come along that attempts to do what both the previous fixpacks tried, we are in the same position. We must learn to accept the G3 BG2 Fixpack for what it is, an attempt to fix bugs (granted some perceived bugs) within the game. Sure this would be easier if every file adjusted or every type of fix had its own component to be decided upon at install time. They have chosen to install the majority in a single component for the convenience of the installer. That leaves it to the rest of us to accept and work with or to deny and use
in our mods.

If you want to have a proactive solution, to a reactive problem that is fine with me. Tell me what problems I will face when making the BG1 fixpack and I'll do my best to fix them before they get there. Sorry. That's not possible. I wouldn't fix a thing and there is no way to know what the problems will be until they arise. If we don't try we'd be left with a smattering of mods that try to do this and that here and there with no consistency rhyme or reason when taken as a whole. Be glad some people have stepped up to the plate to bring these fixes together in one install for each of the respected games. Yes, some things will break that is a given even in the most proactive situation. Yet, they could have said, "Here are the fixes! We're done. You're screwed. Change your mods to fit ours." They didn't and we won't. Some issues have been resolved by adjusting the fixpack others by updating some older code in the third party mods. It's a two way street to solve issues when proactive becomes reactive.

Now I don't normally like to post this long (unless it's code or something that I'm posting for review) so I'm going to wrap it up and say that you are entitled to your opinion. You're entitled to share that opinion as well. What I don't think you should do is drudge up past issues regarding something that is making widespread acceptance within the community for its efforts to squash the many bugs left behind by BioWare. I've already known that you've had issues with G3 BG2 Fixpack and don't need to hear it again (link to one of the other times you've had something to say along these lines would have been sufficient).

What I find appalling is that a simple posted solution to an issue between ToD, UB, SCSII, my NPC mod, and maybe others none of which was the G3 BG2 Fixpack brought on an entire bash (I use the word loosely) of the BG2 Fixpack. It's one thing to mention them as an example, once or twice. But to mention only them for all the issues you have, you seriously need to get some new material.

I guess, I was wrong. I am posting a bit longer....

You (or someone on your behalf) said that as a new modder someone might have looked at the area script reference and said, "Odd naming convention, but what the hey, I'll use it." First off, if someone is able to look at the file and see what the area script is, they've probably looked at several other areas and saw that the file names matched. But since WeiDu might not have been up to the task yet, they didn't want to overwrite an area file that just needed a script block, the existing one was used. WeiDu comes along and we update. It's the nature of the programming industry of any industry really. You work with what you can and make it work. Then as things get better, you incorporate it into your existing processes until the older methods can be completely phased out. This I fear is one of those times, we all need to get on board and work with these new processes to bring older things up to date and new things in line.

I came onto the IE modding scene in 2006, you've had this chip on your shoulder about the G3 BG2 Fixpack ever since then. It's not helping the community, when relatively new modders/players come along with questions and suggestions, to rehash an old issue that will probably always be ongoing rather than to simply answer the question.

I'll boil your post down for myself.
"The code is good. It solves the problem, but it doesn't solve the problem before it starts. Because the problem didn't know it was a problem until the problem become a problem. But my problem is G3 BG2 Fixpack." And that has nothing to do with this problem.

Let me ask you this, would it have been a problem if Bioware had created another expansion with additional quests and included an area file called AR0004.are that had a script reference of AR0004.bcs but no actual script? According to you no, because someone would have made a mod for the game without the expansion and had no clue of the problem in the first place. So the solution then for everyone else is the use AR0021.bcs for the AR0004.are file. No that's stupid, you ask the mod(s) made for the non-expansion to adjust theirs accordingly. They would because it makes sense. Your files are no more important than anyone else's. They are important to you, but not to everyone else. We just want a good game that we can play. If you choose not to be compatible with something, that is your choice. Players will just have to decide which route they want to take. We know you don't like the fixpack and certain components of several mods, just put it in your readmes that it's not compatible, forbid the components in your tp2 and go on. Quit bringing it up. It only brings others down.

Once again, thank you for the compliment on the code. It didn't take that long to come up with. But nobody could have foreseen the problem until it came up (except for maybe the first modder to use the ar0004.bcs instead of changing it to ar0021.bcs).

@plainab:

This is exactly why I gave up any attempts of cooperation with those who you seem to agree with. You're convinced of your own viewpoint so amazingly strongly that you simply completely ignore the arguments of the other side. You don't want to hear (acknowledge) what the other says. You state things such as that the other one is making judgement based on personal preference ("You don't like the G3 Fixpack"), and not based on actual technical arguments. Furthermore, despite the fact I repeatedly emphasized that I've been describing a general phenomenon (which best example is indeed the G3 BG2 Fixpack), you seem to strongly believe that I'm going off-topic, going far from the actual specific subject. You seem to believe (or pretend) that the G3 BG2 Fixpack case is a different issue.

You're so much convinced about the superiority of your viewpoint, that you automatically consider any counter-arguments (especially from Baronius) as void.

When I was reading your words, I had the impression I'm reading CamDawg's words, or SimDing0's words. Completely the same things, repeated again and again.

After the recent discussions with some people (including DavidW), I started to believe that perhaps it's me who wasn't detailed enough or patient enough in the past when I've shared my arguments with you. Now I see that my hope was baseless, and I have never been wrong: no matter how accurately I list my arguments and how strongly I emphasize that it's a general technical and not a personal/subjective issue for me, you simply ignore my arguments or pretend that they don't exist.

I was open in the past when hlidskialfTeamBG taught me some basic WeiDU skills. I was open in the past when I finally decided support the possibility of compatibility with BGTutu as well (partly based on CamDawg's arguments) in my released BG1 mods. I was open to the advice of others several other times. Even if I disagreed in more cases, I've never immediately buried others' arguments by believing that my viewpoint is superior, no matter what the others say. On the other hand, you've never been not open. You are 100% convinced about the superiority of your own viewpoint, and the superiority of your own knowledge in it -- instead of giving a 1% chance to the other's arguments before finding an easy and simple reason to refuse them all. In my country, we call this "considering the other one to be an idiot".

I don't think any more that there will be a miracle and my above words will ever get disproved, so I suppose I'm soon completely finished with you; but as a last attempt of hope, let me repeat some of the arguments I had in a different form, as an answer to a restricted selection of your statements.


As I've emphasized, the G3's BG2 Fixpack is a (very extreme, definite) example of a general phenomenon I've introduced. One of the most importants points was that mod developers should make a careful examination before overriding/overwriting original, non-faulty conditions provided by the original game. This is particularly true to mods which are supposed to be standard parts of each game installation (hence the G3 BG2 Fixpack the best example, again).




If this was true, your operating system and installed software wouldn't run for 5 minutes before producing a bug or malfunctioning. If the approach you described was used in software technology, we would still be in the ancient ages, i.e. where we was before the software engineering conference of NATO in 1968.

One of the magic words is planning, preparing. Justifying the presence of all problems by saying "we can't the predict the future problems" isn't correct. Sure, many problems cannot be predicted, but many others can be. Many issues can be avoided before they would appear.

Your thinking seems to be excessively focused around the concept of code. As far as I can see, you're saying that you presented a solution to a problem, and somehow my answer was generalized, and it brought up G3's BG2 fixpack. Have you ever considered why (apart from your obvious and unified viewpoint "Baronius doesn't like the Fixpack")? Have you ever considered that after approving your code, I wanted to express that it's the solution of a specific problem, and it doesn't help on general problems (and I used G3 BG2 Fixpack as an example to introduce the general problem)?

I'm sorry to repeat it again, but this again proves that you're 100% convinced in your viewpoint, and base all of your other claims on this fact. The first modder to use ar0004 instead of changing it to ar0021?! How can you be so sure that everyone thinks in the same way as you and automatically changes the script to ar0021? Have you ever considered that other modders might consider the game's conditions as a base and wouldn't try to "change" everything to more "reasonable"? Don't get me wrong, I'm not saying that your arguing (consistent naming) has no good points -- I'm just saying that you automatically assume everyone thinks about in the same way as you.

For example, even jcompton (who you can really can't say to be BWL's biased member) believed that we may have a point in what we say about the UB issue (bold and italics added by me):

Again, I don't say he necessarily agrees with us, but he found our suggestion reasonable, and used the word 'doubtless'. Just see the bold and italic parts: he doesn't seem to be think that it's obvious everyone finds it so natural to replace the script name just because it's more reasonable. He might feel his viewpoint closer to your solution (consistent naming all the time) and not to ours (I don't know what he thinks), but he did consider our arguments from a technical point of view, unlike what you guys (practically at G3) do all the time: "our solution is superior, you just don't like our mod/work/method etc.".

Why do you assume that everyone interprets the rules or possibilities (e.g. of the IE game, or of mod development) in the same way as you? Because there were 9 or 10 people supporting your viewpoint on a forum, or because a few hundred players downloaded your mod and provided positive feedback? Or because you have seen it working correctly and seamlessly for yourself, so you assume than anything that works differently is bad? It is like assuming that since you know "X" to be 'true' (= you see it working correctly etc.), all other possibly unknown solutions are automatically 'false' (~ "closed world" concept, DavidW could probably tell much about it). In this case, perhaps not 'false', but 'worse', 'inferior'.

To me, your approach and arguing often seems to be based on influence and the power of majority, and not on technical facts and discussions. You only consider those technical discussions as valid which interest you and aren't opposed to your strong belief about the superiority of your solutions. Others discussions are simply ignored by you. This "the majority rules" is confirmed by this statement too (bold added by me):


And again, another sequence of assumptions:

How can you be so sure that all or most modders looked at it (and look at it) like that? Many mod developers even don't care about how reasonable a naming convention is, they just build a mod based on the game, and then e.g. use WeiDU to build a package that is compatible with the mods it can be compatible with.

Again, I don't state that your assumptions there are wrong. I just emphasize that you can't generalize, and shouldn't base all your statements and decision on the assumption that since "it looks obvious to me, others certainly think about in the same way", and "I've seen it working perfectly in my environment, so other solutions can't be better or seamless" (on a side note, this seems to be a typical American and Western European mentality as well, as far as I've noticed; it isn't surprising, but let this remain a side note).

To cut a long story short, I think you guys (as far as I've noticed, you too plainab, and most of the others too who pretend not to see my technical points) base your arguments on the belief of superiority in your own solutions, in the influence and power of majority, the majority's confirmation -- instead of considering others' arguments even to a minimal degree (like, for example, Jason Compton, Luan, Ymarsakar, lroumen did), and instead of considering even a little bit what others say (Wounded Lion, Blucher, Wounded Lion (again) ).

I don't ask you to agree different viewpoints, just at least acknowledge and consider them a little bit. To stop pretending that each issue is completely specific and isolated from others. For example, you plainab say that my generalization and G3 Fixpack example is irrelevant, because it was only about a problem your code specifically fixes; similarly, Blucher posted something very general in the "Keys Being Used By Doors" topic (link above), and that issue was also treated as "specific issue"; the fact G3 Fixpack's alignment changes can break Improved Anvil's scripts is also considered by you guys as a "specific" issue and Improved Anvil should enforce its necessary creature alignments on its own etc. etc. etc.

Unfortunately, you guys don't give the least credit or even respect to viewpoints other than yours, no matter how technically estabilished they are. Instead, you are content with the fact that hundreds of players and the majority of the active, loud modders follows what you dictate. You've never considered that perhaps there could be a compromise which would be accepted by practically all modders and all players, and perhaps there would be less bugs and problems if you listened to what others say, because those others aren't idiots either. But it would require effort and work, and would somewhat risk the current situation and level of reputation you're satisfied with, so it's much easier to just pretend that what others say is baseless, or based on personal preferences and taste.

I haven't said anything in these fixpack, etc., debates before, but I thought I point out something here.


I believe that is called the trial and error method. Change something, load it up and see if it works. If it doesn't, go back and change it and try again. Is that the way the Fixpack was made? Wouldn't it be better to check to see if the change really needs to be made first, then do it? And while doing it, actually test it? If trial and error is to be used, the developers have to be willing to spend an enormous amount of time to fix any errors that may crop up. But, from the looks of it, the G3FP developers have no intention of doing so. Instead, they have defined a new way of trial and error:

"We make the errors. You do the trials." *

Alright, maybe that's being a bit cutting, but after reading countless threads about this, that's the impression I have gotten.


* ^{Since I came up with this line, if anyone wants to use it for the fixpack, I get royalties!}

I need to calm down. 10...9...8...7...6...5...4...3...2...1...0

What you said about me believing that my viewpoint is better than yours is the very same way you come across in your post(s). The one I responded to and again the one following that. I never said my viewpoint was better, I tried to show that both viewpoints are valid. It depends on what approach you take. Some, like me, need order and would change a script reference to match an area file if it was within our power to do so. We are fortunate that I also like compatibility. I personally would avoid doing something orderly if I knew it would be a downfall to compatibility. I may even move my one character to a different place or leave him where he starts out. But that would just be running away from the problem and that's never good.

The main thing I wanted to get across and failed at doing so was that bickering about how things should or should not be done is wrong. We ALL need to grow up and work together.(I include me in that statement, hence the capitals) Let's not get stuck on technical issues and philosophical debates about whose approach is better and why it is better. When we get defensive we'll never agree on anything. Rome was not built in a day. It took them stone by stone with plans and cooperation, but some problems had to be overcome as they arose. It's a fact of life that we can't code for everything. We code for what we can, we code for what we know. We adjust what we need to when unforeseen problems arise.

I felt like I had to defend the designers of the BG2 Fixpack, even though I'm not part of that group. It sounded like you were ripping them a new arse simply because you didn't agree with their methods. I'm sorry, I must have misunderstood your intentions. Just as I feel you misunderstood mine. It didn't help that for me I was up late on a long day making that response. I should have waited till I was rested and had a clearer mind. I've regretted it all day. I was just waiting for the e-mail that said you'd responded, I knew you'd not like it. I was right. You did not like it.

The overall issue can't be solved overnight. It's going to take teamwork and cooperation to do that. I tried. I shared code that would help. But I was told that it wouldn't help. That there is a bigger problem to be solved. Fine, a bigger problem, let's get it resolved. Get everyone together whose had a public mod release, and make these decisions. Get the results posted at every forum so we can all follow them. Until such consensus takes place, the community will remain fractured over this, you will continue to share with everyone why we are fractured, and some of us who try to help will become discouraged by it all.

I'm a limited breed. I'm left out by many mods, because I don't have ToTSC. That's their choice. I can choose to look at it as a problem that needs to be solved by them modding for the vanilla game. But ya know, it's better if I try to save the money to buy the expansion myself. Then again, maybe I don't want it because ToTSC breaks/changes just about as much stuff as they add/correct. One of the big ones is the end of Chapter 4, the chapter change happens right when Daveron is dead in ToTSC and it has caused issues for some people. Vanilla uses floor triggers near the exits to increase the chapter. It's cleaner, nicer and no reported issues that I've seen. I've fixed it, reverted it I should say. The patching was hard, but it's been done and done in such a way that even with added mods it still works (especially those that modify that area and it's scripts). I know because the issue is present even in a non-ToTSC EasyTuTu installation, that's where it's been fixed and has had some limited testing (that's why you probably haven't heard about it yet - we won't publish until it's ready and has proven itself). From there the code was easy to modify for standard ToTSC. If that doesn't show you that I'm not quite in the same camp as the BG2 Fixpack and UB people and whomever else, I don't know what will.

You have your opinions and I can't change that. I've shared mine. I hope this post has cleared things up a bit. If it hasn't, I'm sorry. Communication has never been my strong point, at least, I'm trying to communicate and solve some of these issues that are part of the larger whole. The redwood is mighty, but a single axe can cut it down with single persistent cuts. Maybe if we work together on these little issues and get some consensus for the future, we will find the bigger problems become more manageable until they are all gone....

Like my mother always said, "Pick your room up one thing at a time. Don't look at the big mess, just do one thing at a time and before you know it, it'll be clean." Let's take that one step, get together and solve this one issue. We can then tackle the next one. I hope that those of us who are serious about modding can come to an agreeable solution if we just try.

Keep it cool...
ab

Priceless!

It's even better than my well-known description of them (= "Mistaking players for testers").

Okay, so I'm kind of unclear about the rules here (and I accept they might vary from person to person; there doesn't need to be an Official BWL Line any more than an Official Any Other Site Line).

Are people interested in a serious intellectual discussion of the topic, or is it just a point-scoring exercise? I'm not terribly interested in the latter (though I don't mind having a conversation with people who are and blanking people who aren't.)

The fact that the developers of BG2 fixpack don't test their mod before releasing it doesn't need any further arguments (intellectual or not); it's the bare truth which has been settled and proven countless times before. I have also offered strong arguments for this fact which have never been replied by anyone. They have actually admitted it in the past.

Furthermore, my post was not addressed to you or anyone else; I was talking to Sir-Carnifex. And it was not intended to contain an argument, because there was nothing I wanted to prove to Sir-Carnifex. We were in full agreement.

And the last point: if you are ready to object against posts which don't contain an intellectual argument (even if they are not intended to contain one and even if they are not addressed to you), I'm sure that you will find A LOT more cases in G3 forums to protest against.

Oh, I don't object to such posts, wherever they're posted (I think it's usually a bit unconstructive, but it's a free country). But sometimes it's unclear which is which, or what kind of conversation one's in.

DavidW, I'm sure Sikret has even less hope than myself that those certain G3 Fixpack developers will ever consider that their viewpoint isn't superior to others'. Sikret knows it very well what it means when your thorough work is broken due to the mistake and pride of others, and instead of correcting their mistakes, those others deny their mistakes and start to attack & ridicule your work.

@plainab:

Thank you for your post, and for the clarification. You seem to be completely different from those (= certain G3 FP developers) who I tried to cooperate with in the past. They ignored my advice and keep ignoring my arguments, because they're convinced about the superiority of their methods. So I do have a reason when I'm being harsh in my statements regarding their attitude.

To tell the truth, I've lost all my hope in any cooperation with them.


If the G3 FP developers don't intend to split, revise and test their mod and will keep manipulating the players and dictating mod developers by abusing the popularity of BG2 Fixpack (which popularity was gained through powerful marketing and advertisements, and not exclusively with the quality of the work), then I will keep encouraging mod developers to boycott the use of G3 Fixpack.

They are the only one who can help on this situation, because they are responsible for the problems, not the authors of publicly released mods (and future mods). Are you wondering why they have never addressed any of my technical arguments? Because they have no valid counter-arguments, and pretend as if my arguments didn't exist, or simply spread the usual lie that "Baronius doesn't like the G3 Fixpack".

The reason they don't want to revise/split the mod is that it might decrease the popularity of the G3 Fixpack, because it wouldn't be possible to advertise it with the current populist slogans ("Baldurdash plus a few hundred fixes more"). If G3 Fixpack actually contained a few hundred real fixes, the original game would have probably been unplayable and would have been a huge and spectacular failure for Bioware.

The reason they didn't/don't want to devote more effort for its quality assurance (including proper testing) is that it would have made (it would make) the integration of new "fixes" slower, which again would decrease the popularity of G3 Fixpack.

I'm sorry if all this negative tone is discouraging for you plainab, but I've always been in favour of crying out the truth instead of staying silent. It would be hypocricy for myself, and I never do that. I am in favour of diplomacy, but it requires a minimal intention from the other side as well, and they don't have this intention.

So again, if you feel all this as negative and fruitless, then please just ignore it, and do what you enjoy doing -- modding. That is what we all do, because we like it. And good luck for BG1 Fixpack! I'm sure you won't make the same mistakes as the G3 BG2 Fixpack developers did and do. Test your work thoroughly, and don't advertise it with populist slogans -- tell no more and no less about it than what it actually is. Make detailed documentation of your fixes, and don't let yourself influenced by others. Consider suggestions and criticism, but don't let yourself to be influenced when you feel you're right. Always know what your goals are.

Theres something I still dont get though, Baronius and Sikret.

No one is forcing you to use BG2 Fixpack at all. No one. Not CamDawg, not me, not DavidW, not George Bush, not Nelson Mandela. You can explicitly state in any mod you like that Fixpack is not supported, anyone who wants to use your mod should remove it from their computer and never use it again if they plan to use your mod.

Is there a big problem with that? Is there a problem with letting Fixpack do what Fixpack does, and then you just do what you do? Why do you have to keep on attacking it? IA is explicitly incompatible with it, so why bother attacking it?

If you relied on Fixpack, and needed Fixpack, and depended on Fixpack, then perhaps you would, as a stakeholder, have a say in how it should be run. But because you obviously never use it, then perhaps just leave it alone? I think Apple products are overpriced and too restrictive, but I dont go telling my colleague his iPod was a big waste of money. I let him do what he wants, it doesnt affect me. How does Fixpack affect you?

I'm well aware that Fixpack makes some changes that you disagree with. But lets set out some facts:

1. Baldurs Gate 2 has problems that need fixing.
2. To fix those problems, some changes are needed.
3. Because of those changes, some mods that depend on things being broken, or at least different, may no longer work correctly.

Fixpack then, as I see it, has several options. They can

1. Do nothing.
2. Fix things as they see fit.
3. Fix things as you see fit (which, some might argue, is very similar to 1.).

Now, I prefer 2. I understand that, as BG2 can be a heated issue for some, some changes can be controversial. But surely Camdawg et al have the right to decide what goes into their mod, and what doesnt? It is their mod after all. It may be used by the public at large, but at the end of the day it is still produced by people who have a right to do what they like. Conversely, BG2 players have a right to NOT use it, or use it if they will. Also, mod makers have the right to support it, or not support it. Given that, I dont see why you have a problem. They could, if they wanted to, turn Irenicus into a 18/22 Mage/Cleric. Doesnt mean anybody is forced to use their mod, doesnt mean anybody is forced to play with Irenicus as a Mage/Cleric.

The thing to remember is that, despite its stated purpose (to fix things), it is still a mod. Thus, it is NOT compulsory for anyone to use. Should I rip on IA, even though I dont use it? Would you think that was fair? Should I criticize IA for not being compatible with my favourite mods, for "breaking" things? I dont see any difference in the two activities.

As for testing... Sikret, are you volunteering to donate the much needed hours to testing? Camdawg et al dont work for free, its unreasonable to expect testing, just as its unreasonable to expect everyone to use it. If you dont like it, dont use it. Testing is definitely worth doing in a software development environment, but it takes a lot of time, something that these guys, who give their time for free, dont have too much of. If you dont like the fact that it is not tested before being released, are you willing to do anything about it? Or are you just going to complain about it and not use it?

We are not attacking it, we are stating plain facts. Since the developers of BG2 fixpack use their propaganda/brainwashing machine to deceive players, it's our duty to enlighten players that what they say is not true.



Yes, I do that for my own mod. They should do so for theirs, but they don't. Players have the right to play tested and relatively bugfree mods. This is a difference between two modding philosophies. We respect the players' right to play tested and bugfree mods; they don't. For us, there is a well-defined difference between a tester and a player.

Moreover, since their mod is supposed to be a fixpack, they should give even a more serious attention to testing it than other mods. A fixpack should not add so many new bugs to the game. At its current status, the Bg2 fixpack is best be called a "bugpack" rather than a "fixpack".

Ba ha ha ha ha! Yes, you are attacking it. You are attacking its authors and their methodologies, and again I ask you WHY? WHY?

Answer me this honestly - does it affect you if someone uses BG2 Fixpack?

Really, your choice of words - "brainwash" and "deceive" - quite clearly displays this is more than just professional disagreement for you. Releasing a buggy fixpack is one thing, but claiming they practice "propaganda" and "brainwashing" is something even a 13 year old couldnt say he honestly believed with a straight face. Do you not like the fact that their mod is popular? Is that what gets you? Of all the things to be angry about...



Actually no, players who use free mods have no rights at all, because they havent paid for it. They can make requests, but not demand. Do you think that users of IA should have a right to complain if something is too hard? You dont seem to have been too accepting of criticism in the past.

Ancalagon_UK, I would suggest to you to study the problem more thoroughly, because you've oversimplified several matters in your post, which reflects that you're not familiar with the topic, especially in a technical, scientific respect.

Nonetheless, here are some answers:

1. For example, we get constant attacks why we don't support it. On a certain gaming forum, if someone recommends G3 FP and say we prefer Baldurdash to it because G3 FP may break other mods, some supporters of them (like you) who believed all their propaganda suddenly starts to question us.

2. Supporters or sympathizers of G3 Fixpack were spreading (and some of them still probably spreads) lies about Improved Anvil and our other works. We wouldn't care about it, but many players arrive here with similar misbeliefs, which they read somewhere on a different forum.

3. BWL has a good credibility as far as technical problems and modding solutions are concerned, and it would be against the spirit of our core team to allow players and mod developers to be misled and misinformed by some populists who want to increase their mod's (and site's) reputation at any cost. As you can see, my initial train of thought about G3 Fixpack is always of technical nature, but after those arguments are ignored and lies are spread that "it's a rant, Baronius doesn't like the Fixpack", I have no other choice than to clarify that it's all about propaganda. So, it belongs to our modding activity to provide credible technical, "scientific" information about mods to all mod developers and players interested in it -- we don't allow populist and other modding 'politics' interests to interfere (yes, the authors of G3 FP spread various untrue things about modding, such as that "patching is always superior to overwriting", "all mods can be made technically compatible without changing their concept" etc.)


It isn't, but:
1. Thanks to their propaganda, most players believe it IS compulsory to use it, and we tend to get players all the time who install G3 Fixpack even for Improved Anvil, and when we enlighten them, they are surprised. One of them, a new player, believed -- after reading the Improved Anvil readme -- that Baldurdash is actually the BG2 Fixpack, so he installed the BG2 Fixpack. No wonder, as it's advertised everywhere as pinned topics, and they convinced/misled everyone that it's a fixpack with crucial, essential fixes, and its name also implies the same: "BG2 Fixpack", the ultimate fixpack (let alone the misleading slogan "Baldurdash and a few hundred fixes more" -- they even abuse the name of Baldurdash).
2. Thanks to their propaganda, most players believe lies such as that serious bugs are unavoidable (and e.g. they even influenced plainab, who said "there is no way to know what the problems will be until they arise"). Most players don't realize that a high number of bugs which third-party mods seems to have while G3 Fixpack is installed are actually caused by G3 Fixpack. They believe that the bugs that appear are third-party mod bugs (because they seem to appear in third-party mods indeed, but caused by the G3 Fixpack), or if they are G3 Fixpack's bugs, then it's natural ("because every mod has bugs, and it's only Baronius who doesn't like the G3FP and tells that there are too many bugs").
3. They blackmail mod developers to use the G3 Fixpack and learn how to remove its fixes if the third-party mod would be broken or negatively affected by a fix. If you dare not to use the G3 Fixpack, you can expect retaliation and harassment. This is what happened with Improved Anvil V1 as well.


They abuse a simple fact to keep their supporter base (i.e. players like you) in terms of modding 'politics' as well: most players don't understand the technical bases of my trains of thought (mod dependencies, game interfaces, compatibility theory), so they just understand that for "some reason" I don't recommend it. After this point, it's easy to convince them "Baronius' post is just a rant, he doesn't the Fixpack [due to personal preferences]". And players -- including you -- and many mod developers believe this.

You've addressed the following statements/questions to Sikret, but since they're general questions, and I agree with all of Sikret's claims, and this is a public forum, I would like to give answers.

This is also a common misbelief what those certain G3 FP spread for players. "We have not enough free time". (It reminds of their other favourite justification for the bugs of their untested but over-advertised work: "bugs are natural, inevitable". Indeed they are, but it does matter how many and how serious.) So no, Ancalagon_UK, proper testing IS possible, if they allocate time for it. Yes, it significantly DELAYS the releases, but that's how it works. It results in slower development, but the released work will have quality. But they didn't want and don't want to delay releases, because it might be disadvantageous to their visitor count and popularity. The industry must be running with a high performance!


If they advertise it as the standard base mod for all game installations for all players, and the standard base mod for third-party mods, then it IS reasonable to test your work before you give it out of your hands. (On a side note, in my culture, you're taught that you should do precise and accurate work, if you want your conscience to be clear.)

Yes, we keep informing players and mod developers about it, so they know they play/use an untested work, and the bugs they believe to belong to third-party mods (due to the propaganda they hear from G3 FP developers) are actually caused by G3 Fixpack.

If you imply that we should volunteer and test the G3 Fixpack, then no thanks -- even if we had the time, it would be hopeless because G3 FP has an incorrect architecture, and would have to be revised from scratch. They made the problem for themselves, they should be who correct it. However, they don't intend to, because they are content with the fact that they misled tons of players and mod developers that they do their best to ensure the quality of that mod, and that their methods are superior.


As I've said, it is a professional disagreement, but there is no way to fight with propaganda and manipulation with technical reasoning, because most players don't understand the technical reasons, while it's easy for them to believe the propaganda ("Baronius and Sikret don't like the Fixpack"). So when we say it's manipulation and propaganda, we say it because that's what is happening -- but we wouldn't emphasize it if they ever tried to answer our "professional" i.e. technical arguments, questions about their work. They ignore them, then mislead players that we criticize them for other reasons than technical disagreement. Admittedly very subtle.

Don't they even have the right to know that the mod they are going to install is full of bugs? We state the facts about Bg2 fixpack to let players know the facts and then decide freely.

Again, I emphasize that this is even a more important issue when we are talking about a mod which was supposed to be a fixpack. Many players install it just because of its misleading name and the fact that they don't know how bugged it is.

hey I'm a professional software developer with a BSc in Computer Science - but thanks for implying you know it all and everyone else understands nothing.

Even if you are right, if you resort to posting like you seem to always do - ie attacking Camdawg's character, accusing them of spreading propaganda - you completely destroy your own argument, and nobody takes you seriously. Besides which, if you have something important to say, say it once. The more often you repeat the same thing, the less likely people are to care. Because you repeat the same thing over and over, no matter what the truth value is of your initial statement, nobody listens. It becomes, "Oh look, Sikret and Baronius are wanting to start an argument about how they hate Fixpack, I wish they would drop it"

Nobody listens and your point is wasted. Look at how people respond to you when you do so, on both G3 and SP. They just about ignore you, or at the least deride you. And no, its not Camdawg's "propaganda". Its the fact that you wont shut up about it.

Your complaints about Fixpack are essentially identical to what people say about Microsoft whenever a new .NET or Windows comes out. Are you going to suggest that Microsoft should never change anything, and that backwards compatibility is more important than moving forward and fixing things? The same applies to Fixpack. Some things need to be changed, and some of those changes require an authors interpretation. You dont agree with their interpretation, but with the way you act towards them, I'm not surprised. You post with such venom towards them! No wonder they dont listen.

If you want to develop your mod on a base of Fixpack, it is your duty to either specify that users either use a particular version of Fixpack, or update your mod accordingly. The same applies to every single other piece of software - for instance, it is up to the author to decide whether to support Vista, if he doesnt want to, he can state "DOES NOT SUPPORT VISTA". And everybody is happy. He doesnt need to drag it down.

As for the bugs.....

As I see it, there are 2 kinds of "bugs" that you refer to.

The first is a bug caused by human error, eg Irenicus's race being set to Dragon erroneously. Thats a bug, and thats a bug that could cause problems in other mods. It should be fixed as soon as it is found.

The second is a change not caused by human error, but fixing what the Fixpack authors think needs fixing. A well worn example is the true neutral pirate who became Lawful Evil. That could break some mods, but that doesnt mean its a bug within the Fixpack itself. Indeed, if a mod claims Fixpack support, then it is a bug within the mod itself. If the mod does not support Fixpack, then its a compatibility problem.

From what I can see from your rantings, the second type is far more common, and thats mostly because you just dont agree with them. I'm aware that there are a few of the first type. But software development is an iterative process - I would state it is highly likely that Fixpack v6 has far fewer bugs than v1, simply because those discovered earlier will most likely have been fixed as part of the iterative process. yes, they could introduce new bugs, that is possible. I'm sure they have. Again, in that case, the onus rests with the mod maker to decide on a compatibility stance and then develop according. Either support it or dont support, the choice is yours.

I work for a company that makes real time graphics software for TV. Sometimes, we find bugs in drivers - Nvidia drivers, DVS drivers, bluefish drivers etc etc. We report those bugs, but because we cant really on them being fixed timeously, we often have to do something ourselves. But thats the price we pay for using those drivers. Likewise, if you want to develop for Fixpack, you need to be aware of its bugs, report any if you find them, and develop accordingly.

I'm replying to this with some trepidation as tempers seem to run high very easily... but I think you may be misinterpreting Nythrun's post. She says


Which I read as saying: use whatever bugfix you want. Don't even use the official bugfix if you don't want to (though the game will crash and lag more if you don't use the official bugfix). If you prefer any version of Baldurdash, use that. Of course if you don't use this mod, you'll miss out on its content and its authors will be less able to help you.

(I think it's aimed at players rather than developers, btw).

They're still manipulating, and the practice has always seemed to prove that (regardless who interprets what post and how). For example, in case of Improved Anvil V1, after the repeated "No" answers of Sikret (who also provided technical arguments to reason his viewpoint), they still kept bothering Sikret (and trolls also arrive), and when it finally ended, certain people -- including mod developers -- started to spread various false things about Improved Anvil ("it is built to deliberately break other mods"), because that was what they believed, or they simply lied. The G3 FP developers involved didn't clarify them, in fact kept manipulating everyone. Otherwise, why would a mod developer believe such things? It's OK that a player misreads something, but a mod developer is either not a modder if speaks like that, or simply believes all what the G3FP main developers say and advertise.

It's a question of definition, but I agree with you -- in this topic, I've never said it's a fixpack "bug" that it may break other mods. It's a severe problem, no matter how we define it. Exactly as you say: a compatibility problem: that is what I call "incompatibility risk". If you think it's acceptable to have tons of "compatibility problems" (which could be avoided with correct design and verification) in standard fixpack that is meant to be used by ALL game installs and that it's the duty of the third-party mod to correct these problems, then there is no need to say anything.


*sigh*
When the topic is brought up, I tend to repeat my arguments, perhaps in a different form than earlier, but the point is the same.
Look at those people whose post I linked in an earlier post (Ymarsakar, luan, etc.) -- do you think I bribed them?
Look at the person who is one of the BG1NPC project authors, Blucher. Do you think I bribed him? Yes, what he said is very similar to what I say, totally independently from me (yeah, I'm not saying I convinced him about anything -- we haven't ever communicated online).
Look at Wounded Lion, who also brought up at G3 that the G3 FP isn't correctly tested. Did I perhaps bribe him or influence him?
So, please allow me to decide on my own what I think readers may be interested in, or what I think they may not be interested in.

On a side note, mentioning the .NET framework is a poor analogy here. It's not something that is untested or tends to break software that is based on it. OK, it might have bugs here and there (I had the possibility of seeing an ExecutionEngineException caught by VS2008 in WPF), but it's not something that regularly causes problems.

Is this partly the issue? I don't and didn't get the impression that this is being said at all - certainly not in the documentation. (Indeed, I read Nythrun's post to be saying exactly the opposite.)

(Obviously it advertises what it does and presents itself positively, but what mod doesn't? - certainly not my mods, certainly not BWL mods.)

Well, I do. They have succeeded to advertise it everywhere and convince tons of players to use it -- which be OKAY until this point, don't get me wrong -- but then they abuse this popularity to manipulate players and mod developers (otherwise, for example, why would anyone believe the lies about Improved Anvil, Vlad's works and so on?). To cut a long story short, they believe their methods are superior, and instead of offering technical facts, they (ab)use their reputation to convince others about it.