Usability of Stats values > 255.

kjeron

For some reason I had always presumed that the stats.ids entries were limited to storing values 0-255. Many certainly are, as crashes and/or the creature file structure would indicate, but others (MAXHITPOINTS, XP) obviously had a higher limit, or we would never reach level 2.

So I did some testing with the proficiency stats, since they are always stored as effects and thus have no fixed place/size in the creature file, and aside from #99(Halberd), which consistently crashed, the other proficiency stats were accurately detected both by scripts and SPLPROT when using values >255. I was even able to create a learn as you go proficiency system, incrementing the 2nd/3rd byte of the stat as the weapon was used, then increasing the 1st byte at certain thresholds, granting/incrementing actual proficiency.
The proficiency system itself ignored these higher values entirely, even when dual-classing, probably due to how it separates active/original class values, meaning there could effectively be an extra 100 stats to assign values, provided they are checked bitwise through SPLPROT.

Most importantly, are these values used internally anywhere that will cause conflict? If not, is there any known information on which stats can have 2-4 byte values?

[Deleted User]

The user and all related content has been deleted.

kjeron

Opcode 233, Modify Proficiency. Parameter1 is 4 bytes long no matter the opcode, its just displayed in editor's in a manner meaningful to the opcode.

[Deleted User]

The user and all related content has been deleted.

kjeron

Weidu & NI. I wouldn't know about DLTCEP.
If you want to edit it in NI, just Rightclick -> Edit as hex/number/anythingelse.

Galactygon

This could certainly be useful for a psionics-type points-based system where you may go higher than 255 and you use a bunch of SPLPROT.2da conditions to "decrement" a stat by a set amount.

Mimicking SPLSTATE.ids by compressing several states into one stat is a different story because there is no bitwise operator for opcode 233 (like ToBEx does for its own stat mod opcode). You are only be able to set them in EE as far as I know and settle for a staggered bunch of SPLPROT.2da conditions for each possible current stat point. You also have to worry about resetting them to correct values once the duration runs out.

kjeron

Galactygon said:

You are only be able to set them in EE as far as I know and settle for a staggered bunch of SPLPROT.2da conditions for each possible current stat point. You also have to worry about resetting them to correct values once the duration runs out.

Opcode 233 offers an "Increment" option in the EE's, which is sufficient.

I wasn't suggesting using it for additional spellstates(boolean), just stats(values).

Really every scripting stat that is used for boolean values should be completely relocated to using spellstates, to free up those stats for something that actually needs to store a numerical value.

Galactygon

Can you increment proficiencies in EE? The latest version of the IESDP which specifically mentions for opcode 233 that

NB: The Proficiency Modifier effect cannot increment proficiency points, it can only SET them.
NB. The Proficiency Modifier cannot decrement the proficiency points.

I am genuinely curious since there are some hidden gems in engine functionality that are not in the IESDP.

[Deleted User]

The user and all related content has been deleted.

kjeron

@subtledoctor I suspect those problems were likely the effect getting erroneously applied too many times, resulting in an original class proficiency instead of active class. And the game still doesn't like mixing level-up proficiency and other-source proficiency anyway, even though the original & EE game still does it in places. But that's all using multiple sources for the first byte, so far I haven't had issues with the latter bytes being set during levelup/dualclass.

To exclude the other bytes from the check, the increment value and true checks just need to be shifted, the false check needs redoing though:

shift = (8 * (byte# - 1))
0, 8, 16, 24

Mod1 sets EP20 +(1 << shift). Checks bit1 true/false.
SPLPROT: "# 134 -1 8"
param1 = (1 << shift), true
SPLPROT: "# 134 -1 6"
param1 = [0xffffffff - (1 << shift)], false

Mod2 sets EP20 +(2 << shift) per hand equipped. Checks bit 3 true/false.
SPLPROT: "# 134 -1 8"
param1 = (4 << shift), both
param1 = (2 << shift), just one
SPLPROT: "# 134 -1 6"
param1 = [0xffffffff - (2 << shift) - (4 << shift)], niether

Mod3 sets EP20 +(8 << shift) per hand equipped. Checks bit 5 true/false.
SPLPROT: "# 134 -1 8"
param1 = (0x10 << shift), both
param1 = (8 << shift), just one
SPLPROT: "# 134 -1 6"
param1 = [0xffffffff - (8 << shift) - (0x10 << shift)], niether

Mod4 sets EP20 +(0x20 << shift) per hand equipped. Checks bit 7 true/false.
SPLPROT: "# 134 -1 8"
param1 = (0x40 << shift), both
param1 = (0x20 << shift), just one
SPLPROT: "# 134 -1 6"
param1 = [0xffffffff - (0x20 << shift) - (0x40 << shift)], niether</div>

[Deleted User]

The user and all related content has been deleted.

Aquadrizzt

This is really awesome info, @kjeron. Plenty of cool ways that this could be utilized.

[Deleted User]

The user and all related content has been deleted.

kjeron

No reason I remember, they are the same, though I do often omit the 0x from single digit numbers, so that may have been why.

[Deleted User]

The user and all related content has been deleted.

Aquadrizzt

Okay here's a question: is it possible to somehow display the (bit shifted) stats somewhere on the character record?

Like if I have byte2 of a proficiency equal to 3, could I some how show that on the character sheet?

kjeron

Aquadrizzt said:

Okay here's a question: is it possible to somehow display the (bit shifted) stats somewhere on the character record?

Like if I have byte2 of a proficiency equal to 3, could I some how show that on the character sheet?

Not as far as I know. As with most of the text areas in the record screen, the information for both weapon and style proficiency that is called by the UI is stored as just plain text, not actual values.