DavidW

From this thread. Line 109 in splprot.2da does a bitwise equality check for kit ID. I'm reasonably sure (though I'll defer to Cam or someone else with inside info) that this is a mistake from IWDEE development: I can't think of any reason to check kit ID bitwise, and 109 occurs in the middle of a long list of generic checks and directly below a line that correctly uses a bitwise check. That splprot entry is not actually used by any spl, itm or eff file in any of BG2EE, SoD/BGEE or IWDEE. This is obviously a very low-stakes issue. The case for changing it is that the current entry is useless and wastes space in splprot.2da, it risks tripping up modders (it tripped up the OP in the thread I link to above) and it's probably technically a bug according to the dev-intent definition. The case against is that it's harmless in the unmodded game, space is not exactly at a premium in splprot.2da, and if you're using splprot in your mods you should probably know what you're doing. I have no very strong preference here; I'm listing it mostly out of curiosity, in case there's some very arcane reason to do a bitwise kitids check that I haven't been able to think of.

Good, but wrong. I've just had a look and that spellstate isn't used in any ITM, SPL or EFF file in IWDEE, BG2EE or SoD. And to be honest it's hard to think what the actual point would be - with a few very esoteric exceptions (which you probably know better than I do), kitids doesn't store information bitwise. To be honest, my guess is that it's just a mistake - it appears in the middle of a long list of splstate entries that have been put in in bulk to cover general checks, and it's directly below a row (alignment) where bitwise checking does make sense. I suspect someone in IWDEE development just coded up a bunch of general checks, got that one wrong, and it's never been an issue because it doesn't actually get used. (Note that the human-readable descriptors in splprot.2da were added later.) I'll report it at the EE fixpack forum, there's at least a case for fixing it. (And if I'm missing some subtle use case, someone there might know what it is.)

I think option #1 very clearly doesn’t match dev intent. I don’t see any room for doubt that it’s intentional that multiple creatures in BG2 get Boots of Speed; the issue is what to do about those items’ descriptions.

Oh, if item deduplication ends up in SCS I can do what the hell I feel like. I mention it just because it wouldn’t be wasteful to spend time figuring out this component even if it doesn’t end up in FP. My personal preferences do not coincide with my attempt to make an objective assessment of dev intent.

On the current logic we’re using for FP, fixes don’t need to be ‘for’ anyone. Something counts as a bug if it fits the developer-intent definition (see Cam’s other thread). Of course it’s open to anyone either to propose a different FP logic, or dispute whether it applies in this case.

On a concrete design point; I think it is much more sensible development protocol for this project to code proposed fixes as modular tph files in the master branch, where swapping them in or out is just a matter of an INCLUDE, rather then keeping them as a spiderweb of unresolved pull requests. Ironically, the GitHub branch model requires a much more hierarchical framework than I think Cam is aiming for.

This discussion is getting quite confused so I'd like to separate it out. In this thread we can discuss whether items should be deduplicated at all. In this thread we can discuss design issues of doing so.

Beamdog's license clearly does not prevent them from fixing bugs, and we are discussing bugs here.

I'd like to split the discussion of item duplication into two, since it's getting fairly confused. In the other thread, we can discuss whether de-duplicating items is a bug at all, and whether it should be included in the main EE fixpack, or made an optional component, or gated by an ini check, or just left out entirely for another mod. This thread is for discussing how to do item deduplication, on the assumptions that 1) we want to build a component that removes either all, or all but one, of each duplicated unique item and replaces it with a generic item 2) as much as possible that component wants to be guided by developer intent, but recognizing that a certain amount of intelligent guesswork may be required to discern that intent. Where that component goes can be separated out from how to design it. (If it absolutely shouldn't go in FP it can always go in SCS or Tweaks.)

I'd like to split the discussion of item duplication into two, since it's getting fairly confused. In this thread, we can discuss whether de-duplicating items is a bug at all, and whether it should be included in the main EE fixpack, or made an optional component, or gated by an ini check, or just left out entirely for another mod. The other thread is for discussion of the details of how to do item deduplication.

How surreal... Thanks for the report, definitely sounds like SCS. I'll see if I can replicate next time I do a bug run.

Just minimally on this (not ignoring the rest of the post, but I've got a limited time window right now): Since this is an EE fixpack, and since the developer team who built SoD are the same team who built *and are currently maintaining* BGEE and BG2EE, I think SoD is pretty good evidence for developer intent in BGEE and BG2EE.

All true. But it makes function-heavy code massively easier to write.

Can you say more about this? (I think you're right that I'm being slightly inconsistent.)

As I've explained several times in this thread, there is extremely good in-game evidence that things like this occur because people doing level design were using the item names (which are generic) and not noticing that the descriptions are unique. The developers of the games we're discussing are the EE developers. It's a reasonable default assumption that their intention is to implement the intentions of the original Bioware developers, but that assumption can be overridden where there's clear evidence of EE developer intent. (e.g. the Bioware designers obviously didn't intend for there to be a joinable wild mage, but Neera does not thereby become a bug.)

It's not a problem - both sets of kits are numbered perfectly legally. It's just that as it happens (I think as a legacy of oBG1) the wizard kits are numbered so that doing a bitwise-equality check (which, as SD says, is logically speaking wrong) happens to get the right number. Specifically, if x and y are both powers of 2 then they are bitwise equal if and only if they are equal, so you get away with it.

That's because wizard kits all have IDS that are exact powers of 2, but bard kits do not.

I am an academic. I promise you that I would not be surprised hearing that people write books on anything. However, I don't think guessing what QA would do is that salient, because they operate under constraints that don't apply here. Almost by definition, bugs being fixed by a FP released 20 years after the original game and 10 years after its EE version are not going to be sufficiently serious to have been prioritized in a pre-release bug triage exercise. (I should also have been clearer: I think 'developer intent' i the only really viable way to define a bug *in a community fixpack for Baldur's Gate*. It wasn't intended as a more systematic thesis.)

I don't understand - I'm not just being willfully annoying. I think 'developer intent' is the only* really viable way to define a bug, and there is really good evidence that by that standard, item duplication is clearly a bug: that is: there is really good evidence that the developers did not intend to duplicate items, and indeed that they actively intended to avoid duplication. BUT item deduplication is very modular and could perfectly well be separated off from the rest of the FP. I'm somewhat inclined to think we should do so, not because I think there's genuine reason to think deduplication does not meet the 'developer intent' standard but simply because it seems to be a bit controversial and so we might serve the community better by making it optional. *Well, 'game-breaking' is probably also definable, but it's much too narrow and virtually none of the bugs we're discussing here are game-breaking in that sense. (There are probably very few remaining game-breaking bugs in the EE games.)

To borrow an example from long ago FP discussions: if Irenicus were replaced by an upside-down pink ogre, it would not be game breaking, but it should probably still be fixed.

SCS reads the game files to determine what the proficiency system is; it doesn't make hardcoded assumptions about them. It will handle CDTweaks fine; indeed, it will be fine if you let wizards put four pips into proficiencies, fighters only one pip, and you rearrange the proficiency system alphabetically so that you can specialize in weapons A-D, E-G, H-M, N-R, S-V, and W-Z.

Strong disagree. Encapsulation isn't everything, but it's a huge advantage for avoiding and catching bugs.

If this is for FPEE, you don’t need to bother with the EVAL anyway: we’re using AUTO_EVAL_STRINGS.

That’s just my ignorance of what is or isn’t stealable. No need to do anything, then.

O sweet summer child, look back at the discussion threads for the original BG2fixpack sometime...