NO_RACE / NO_CLASS

[Luke]

A recent discussion about blanking the CLASS value of Shambling Mounds made me realize that there are two ways to achieve that:

• CLASS=0
• CLASS=0xFF (255)

But that is bad because as kjeron said, 0 is an hardcoded value that stands for 'Any CLASS value' (i.e., no particular class)... So why adding a new entry in the first place...?

On top of that, this new entry is not referenced in any scripts/dialogues/op318/324/326. The same holds for "NO_RACE".

As a result, I suggest changing

• all RACE=(255|NO_RACE) CRE files to RACE=0
• all CLASS=(255|NO_CLASS) CRE files to CLASS=0

After that, the "NO_CLASS" and "NO_RACE" entries should be removed to free up space.

Edited June 22, 2022 by Luke

[lynx]

Surely this would break IDS targetting ...

[Luke]

2 hours ago, lynx said:

Surely this would break IDS targetting ...

The key point is that it should be the other way round, i.e.: 255 => 0 (I fixed my previous post based on kjeron's comment...)

Edited June 22, 2022 by Luke

[DavidW]

What bug is this fixing? Hundreds of creatures are assigned NO_CLASS; there's absolutely no reason to think this is unintentional on the developers' part; changing it fixes no bug that I can see, and risks disrupting some script. It's somewhat more plausible that the assignments of CLASS=0 are errors, but there too I don't see any actual bug being fixed, and there too there is a risk of disrupting a script.

Freeing up space in class.ids might be helpful for some megamod install, but that doesn't make it a bug.

[Luke]

On 6/22/2022 at 1:24 PM, DavidW said:

Freeing up space in class.ids might be helpful for some megamod install, but that doesn't make it a bug.

Yes, this would be the main reason...

I mean, it's not really a bug, but they're certainly kinda misleading, aren't they...?

As I said (and unless I'm missing something), they are not referenced in any scripts/dialogues/op318/324/326, so why are there in the first place?

According to the IESDP, the old bg1/bg2/iwd list them as well... Though I doubt they are actually used in scripts/dialogs (cannot check...)

So my question is: is it possible that whoever added them did not know that 0 already stands for 'any RACE/CLASS'...? Otherwise why calling them NO_RACE / NO_CLASS...?

[DavidW]

20 minutes ago, Luke said:

I mean, it's not really a bug

For a fixpack - i.e., a mod whose sole purpose is to fix bugs - that's surely a decisive reason not to change it.

It's not as if any modder who wants to free up space for their vast array of class.ids entries can't do it themselves with one line of code.

Worth noting: just because something isn't used in the unmodded game doesn't mean it doesn't get used by some mod. (And even if someone isn't using it actively, many mods probably copy over .cre files that have NO_CLASS/NO_RACE set.) One reason not to change things that don't actually need to change is that it reduces the chance of breaking someone's mod. (Another is just general safety-first coding. Another still is that it would create unnecessary QA work for BD if they incorporate FP into 2.7.)

[Luke]

21 minutes ago, DavidW said:

It's not as if any modder who wants to free up space for their vast array of class.ids entries can't do it themselves with one line of code.

Worth noting: just because something isn't used in the unmodded game doesn't mean it doesn't get used by some mod. (And even if someone isn't using it actively, many mods probably copy over .cre files that have NO_CLASS/NO_RACE set.) One reason not to change things that don't actually need to change is that it reduces the chance of breaking someone's mod. (Another is just general safety-first coding. Another still is that it would create unnecessary QA work for BD if they incorporate FP into 2.7.)

Fair enough.

In any event, I would use 0 (instead of 255) to blank the CLASS value of Shambling Mounds...

[subtledoctor]

On 6/22/2022 at 7:24 AM, DavidW said:

What bug is this fixing? Hundreds of creatures are assigned NO_CLASS; there's absolutely no reason to think this is unintentional on the developers' part

FWIW I think the idea is: if hundreds of creatures are assigned 255 for this value, and hundreds of other creatures are assigned 0, and all of those creatures are intended to behave identically… then they should have identical values. Maybe having different values doesn’t currently cause any discernible bugs, but it certainly could. 

An analogue is the kit field: most trueclass NPCs have 0x4000 but a few have 0x0000, and it ended up causing bugs that were hard to pin down when mods affected that field. I think I recall seeing that one made it to a fix list for 2.6 or 2.7. If that one is worth fixing, and if part of the point here is to present ready-to-go fixes for a future patch, and if the assumptions above are true (files with different values are intended to behave identically) then IMHO this might be worth making consistent, even if it is an edge case.