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.

This post has been edited by Sikret: Mar 25 2008, 04:35 PM

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.

This post has been edited by Baronius: Mar 25 2008, 04:11 PM

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.