item type Difficulty understanding some slots in slot.IDS

[Incrementis]

Good evening,

I tested the slot reference numbers found in slot.ids by creating a new type in itemtype.2DA.

To do this, I used a modified katana weapon and used the new item type created in itemtype.2DA while iteratively changing the item type slot number per test.

These are the results so far:

Spoiler

BG(2)EE and IWDEE

NOTE: The table could also apply to other IE games. 
It has only been tested for BG(2)EE and IWDEE.

A rudimentary information can be found in slots.IDS. It can be watched with the help of Near Infinity. The numbers are used in itemtype.2DA(last column). Further sources: * https://gibberlings3.github.io/iesdp/file_formats/ie_formats/itm_v1.ht #Header_ItemType * https://gibberlings3.github.io/iesdp/files/ids/bgee/slots.htm * https://gibberlings3.github.io/iesdp/file_formats/ie_formats/cre_v1.htm#CREV1_0_ItemSlots

ID	Slot-Name	Description
0	SLOT_AMULET	Self-explanatory
1	SLOT_ARMOR	Self-explanatory
2	SLOT_BELT	Self-explanatory
3	SLOT_BOOTS	Self-explanatory
4	SLOT_CLOAK	Self-explanatory
5	SLOT_GAUNTLETS	Self-explanatory
6	SLOT_HELMET	Self-explanatory
7	SLOT_RING_LEFT	Self-explanatory Although both ring slots are highlighted, only the left ring slot accepts item.
8	SLOT_RING_RIGHT	Self-explanatory Although both ring slots are highlighted, only the right ring slot accepts item.
9	SLOT_SHIELD	Self-explanatory(also slot for offhand and slot is not highlighted)
10	SLOT_FIST	NOT AVAILABLE (possibly hardcoded)
11	SLOT_AMMO	All ammo slots (slots are not highlighted)
15	SLOT_MISC	First(left) quick-item slot (slot is not highlighted)
35	SLOT_WEAPON	All Mainhand slots only (slots are not highlighted)
11	SLOT_AMMO0	All ammo slots (slots are not highlighted)
12	SLOT_AMMO1	NOT AVAILABLE (possibly hardcoded)
13	SLOT_AMMO2	NOT AVAILABLE (possibly hardcoded)
14	SLOT_AMMO3	NOT AVAILABLE (possibly hardcoded)
15	SLOT_MISC0	First(left) quick-item slot (slot is not highlighted)
16	SLOT_MISC1	NOT AVAILABLE – Game crashes
17	SLOT_MISC2	NOT AVAILABLE – Game crashes
18	SLOT_MISC3	NOT AVAILABLE – Game crashes
19	SLOT_MISC4	NOT AVAILABLE – Game crashes
20	SLOT_MISC5	NOT AVAILABLE – Game crashes
21	SLOT_MISC6	NOT AVAILABLE – Game crashes
22	SLOT_MISC7	NOT AVAILABLE – Game crashes
23	SLOT_MISC8	NOT AVAILABLE – Game crashes
24	SLOT_MISC9	NOT AVAILABLE – Game crashes
25	SLOT_MISC10	NOT AVAILABLE – Game crashes
26	SLOT_MISC11	NOT AVAILABLE – Game crashes
27	SLOT_MISC12	NOT AVAILABLE – Game crashes
28	SLOT_MISC13	NOT AVAILABLE – Game crashes
29	SLOT_MISC14	NOT AVAILABLE – Game crashes
30	SLOT_MISC15	NOT AVAILABLE – Game crashes
31	SLOT_MISC16	NOT AVAILABLE – Game crashes
32	SLOT_MISC17	NOT AVAILABLE – Game crashes
33	SLOT_MISC18	NOT AVAILABLE – Game crashes
34	SLOT_MISC19	NOT AVAILABLE – Game crashes (Magically Created Weapon Slot (i.e. Flame Blade))
35	SLOT_WEAPON0	All Mainhand slots only (slots are not highlighted)
36	SLOT_WEAPON1	NOT AVAILABLE (possibly hardcoded and depending on the class)
37	SLOT_WEAPON2	NOT AVAILABLE (possibly hardcoded and depending on the class)
38	SLOT_WEAPON3	NOT AVAILABLE (possibly hardcoded and depending on the class)
-1	NOT A SLOT ID	Itemtype.2da treats it as "use hardcoded default", not an actual SLOT ID.
(-65 535, -1 048 576) = x and x > 38 (39, 5000,10000, 65538, 2^18, 2^20)	EMPTY SLOTS / NOT A SLOT ID	NOT AVAILABLE  (There aren't negative item slots nor negative item types, since they're stored unsigned.)
-65536, 2^22, 10 000 000	EMPTY SLOTS / NOT A SLOT ID	NOT AVAILABLE – Game crashes (There aren't negative item slots nor negative item types, Since they're stored unsigned.)

The PDF, which also includes an image of the inventory with inventory slots marked, can be found here.

Does anyone have an idea how to get the other slots (marked with red and orange writing) to work, or does anyone have any information about what they are and why they don't work? Any insight could be helpful, even if it's just a suggestion.

Thank you for taking the time to read this comment.

Edited August 11 by Incrementis
table update

[kjeron]

SLOT #15 covers SLOT_MISC0-18 (Quick-item and Backpack slots).  You cannot assign an item type to a specific backpack or quick-item slot.  Similarly:

• SLOT #35 covers WEAPON0-3. Everyone has 4 weapon slots, some just aren't access-able through the inventory based on class.
• SLOT #11 covers AMMO0-3. Everyone has 4 ammo slots, you just can't access the 4th through the inventory.

SLOT #10 and SLOT #19 do not have interact-able inventory slots, one is for the "Fist" item, the other is the Magically Created Weapon Slot (i.e. Flame Blade).  Assigning an item these types is pointless, since you cannot access them through the inventory.

There are no other inventory slots to add.  PSTEE has externalized this partially, but it never made it into the other games.

The default Weapon item types (up to #30/HALBERD) are hardcoded to have access to both #35 and #9, it cannot be duplicated with added item types.  The Rings item type (#10) has similar hardcoded access to both ring slots.

That last one is likely an overflow, the value probably crashes starting at 32768/65536 (anything > 2  bytes, signed/unsigned).

[Incrementis]

@kjeron, thank you for your answers!

I'll look into this further when I find time and then adjust the table.

 

[Incrementis]

19 hours ago, kjeron said:

That last one is likely an overflow, the value probably crashes starting at 32768/65536 (anything > 2  bytes, signed/unsigned).

It may be an integer overflow with wrap-around, since e.g. the reference value -1 048 576 does not result in an error and the value -65 536 results in an error. It's not clear how many bytes are available, which honestly would be good to know.

I have updated the table and it should improve readability and contain more useful information.

[lynx]

The CRE item slots take up a word each.

[Incrementis]

8 hours ago, lynx said:

The CRE item slots take up a word each.

Thanks for the reply.

I'm not entirely sure how many bytes 1 word is. I would assume 2 bytes, but that could depend on the system (that could also mean 4-8 bytes)?

For 2 bytes this might mean values from -32 768 to 32 767.

Could you please elaborate on how you came to this conclusion? It might help to understand things a little better.

[lynx]

2 bytes. You can look at the format description or even the code of various tools.

[Incrementis]

4 hours ago, lynx said:

2 bytes. You can look at the format description or even the code of various tools.

Thanks for the tip. I found: "Selected weapon is a word value indicating which weapon slot is currently selected." and one of the many cells can be filtered to be the same size as 2 bytes for a word.

With this knowledge, I updated the table.

 

Another perhaps trivial question arises that would be helpful if someone could lead to a solution. The table now contains the information for the Slot.ids, which applies primarily to BG(2)EE, although I can't see any difference for IWD:EE.

Additionally, iesdp does not list Slot.ids for IWD:EE(see here). I find it difficult to say whether the results in the table also apply to IWD:EE.

[lynx]

All the games store them as words. Only pst and iwd2 are different when it comes to slot handling. The latter has weapon sets, so there are more shield slots, the former is exotic to put it mildly.

[Incrementis]

8 hours ago, lynx said:

All the games store them as words.

I checked the games all the Enhanced Edition and original version of the IE games wit NI and it turned out that it is true that it is 2 bytes.

I didn't expect this, since for example iesdp writes:  "Selected is a dword indicating which weapon slot us currently selected." for PST. And if I am not mistaken dword is 4 bytes size.

Thank you for pointing this out. I needed this information for plausibility checks regarding a dimorphic function in WeiDU.

 

For anyone else interested in adding a new item type while maintaining compatibility with other mods, you can find the code here:

 

I would like to thank everyone who helped me and if anyone finds a mistake, please don't hesitate to point it out.

[lynx]

Other fields can have a mismatch, yes. And IESDP might still have some field widths documented poorly. Plus, it's hard to care if a field is a dword or not if you know half of it is unused, padding etc.

Anyway, in this case it's just needlessly confusing, since those last two fields are not slot types.

EDIT: Why do you allow negative slot types? Relying on underflow is bad.

Edited August 7 by lynx

[Incrementis]

30 minutes ago, lynx said:

EDIT: Why do you allow negative slot types? Relying on underflow is bad.

For purely technical reasons -1 can be found as a slot value in itemtype.2da.

The game system allows negative values and is in the range of a signed integer with a size of 2 bytes and works without problems.

Why are negative numbers a bad idea in this case?

[lynx]

I wouldn't say that's a slot value, just an unrestricted marker. It's special in some other functions as well; I don't know if you could trigger that accidentally. Anyway, it looks dumb and you'd have to prepend to itemcat.ids, instead of just appending, to maintain order.

[Incrementis]

12 minutes ago, lynx said:

I wouldn't say that's a slot value, just an unrestricted marker. It's special in some other functions as well; I don't know if you could trigger that accidentally. Anyway, it looks dumb and you'd have to prepend to itemcat.ids, instead of just appending, to maintain order.

Thanks for the hint. I'll have to look into this further as I'm not entirely sure why "you'd have to prepend to itemcat.ids, instead of just appending, to maintain order" might be the case (I might find time on the weekend). If you could help me with any further pointers or detailed information that would be great.

"...it looks dumb..." is a category I don’t care about as it is very subjective.

[kjeron]

20 hours ago, Incrementis said:

For purely technical reasons -1 can be found as a slot value in itemtype.2da.

Itemtype.2da treats it as "use hardcoded default", not an actual SLOT ID.