UB bug still present in v16, [split by Baronius] Options

[Baronius]

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

[This topic was split from this]

[Baronius]

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.

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.)

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.

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.

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.

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.

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[..]

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).

[DavidW]

Almost forgot:

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.

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).

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.