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]

[DavidW]

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:

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

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.