sacred_k/docs/skill-slots.md

7 weapon sets and 7 combat-art slots

Goal (user request 2026-10-14): 7 weapon sets and 7 combat-art slots instead of 5 each; skills on 1-7, weapon sets on F1-F7. Inventories are saved as JSON in place of the binary block; vanilla saves are migrated on load. Saves do not need to stay loadable by the original game. Status: inventory data for slots 6-7 (src/mods/skillslots.cpp) and the JSON save (src/mods/inventory_save.cpp) done and tested (vanilla save migrated, JSON save reloads unchanged); taskbar with 7 + 7 slots (src/mods/skillbar.cpp), unlock levels 45 / 65 and keys 1-7 / F1-F7 done; tested in-game 2026-10-15 (drag & drop, casting, equipping set 6 changes the stats, save / reload).

Where the slots live

cInventoryEntry (one per player, no vtable)

All 32 inventories are one block from cInventoryManager::Instance (0x5deb80, 32 x 0x1180 + 8 bytes at *0xad23c8); GetInventory (0x5dec50) hardcodes the stride 0x1180. An inventory's index is therefore (inventory - block) / 0x1180.

Offset	Size	Content
+0x18	0x100 x 0xc	item grid
+0xc18	5 x 0x18	weapon sets: 2 hands x (item id, 2 dwords)
+0xc90	5 x 2 x 0x14	art slots: 2 variants (bit 2 of +0x1162, maybe mounted) x {u16 type 2/3/4, u16, id, 3 dwords}
+0xd58	2 x u16	selected slot: [0] weapon set, [1] art slot
+0xd5c	0x400	(next field, unrelated)
+0x115c / +0x115e	u16	grid width 0x14 / height 8
+0x1160	u16	player index
+0x1162	u16	flags

The three slot arrays are packed together, so there is no room for slots 6 and 7 in the object.

Methods (names in tools/names.txt): GetWeaponSetItem 0x5d86c0, SetWeaponSetItem 0x5d86f0, SetWeaponSet 0x5d8930, TakeWeaponSetItem 0x5d8be0, GetWeaponSetItemPos 0x5d8d00, GetArtSlotType 0x5d93e0, GetArtSlotRef 0x5d9420, SetArtSlot 0x5d9480, ClearArtSlot 0x5d9680, SelectSlot 0x5d9820, GetSelectedSlot 0x5d9b60, SetArtVariant 0x5d9200; loops over the 5 weapon sets in Clear 0x5d7d30, ReplaceItemId 0x5d80e0, FixInventory 0x5de8a0 and the load path of Serialize.

Accesses outside the class found so far: none to these offsets (searched +0xc18..+0xca0, +0xd58/+0xd5a, (x+0x102)*0xc, (x+0xa1)*0x14, (x*3+0x183)*8). The compiler also spells addresses in other ways, so the list is a lower bound until the callers of the accessors are checked.

Save format (cInventoryEntry::Serialize 0x5dd9f0)

(stream, write); stream vf04 read, vf08 write, vf14 position. Raw blocks in this order, no version field:

flags +0x1162 (2), +0x1164 (2), +0x1166 (2), width (2), height (2), +0xd5c (0x400), grid (0xc00), weapon sets (0x78), art slots (0xc8), selected (4), +0x1168 (4), quest items (count + 8 each), scrolls (count + 4 each).

Returns the number of bytes processed. Callers:

• hero save / load: ItemDataMgr::saveHero (0x6046f0: 0x604a26, 0x604a7d) and ItemDataMgr::loadHero (0x605900: 0x605cee);
• multiplayer: 0x5db670 and 0x5df1f0 serialize into a cFile_ram and send it as a network event; must keep the binary format;
• save games (GAME*.PAK, "AMS"): cInventoryManager::Serialize (0x5def60, thiscall (stream, write, x)), all 32 inventories behind 0xdeadc0de markers; called from 0x61ae26 / 0x61c0a8.

Hero file chunks (saveHero / loadHero)

0x100-byte header (magic "AMH" at +0x?, chunk count), then a table of (type, offset, size) entries, 12 bytes each, 0xc0 bytes = 16 entries, written last (saveHero seeks back to 0x100). loadHero seeks to each chunk and switches on its type; unknown types appear to be skipped (to confirm).

Type	Content
0xc0	hero record (0x5ac)
0xc1	the hero's inventory (Serialize, inventory index = hero id)
0xc6	inventory #0x11 (Serialize; what it is: not checked)
0xc2, 0xc3 (0x22c), 0xc4 (0x40), 0xcc, 0xce, 199, 200	other hero data
0xca / 0xcb / 0xcd	variants of 0xc1 / 0xc6 / 0xcc with a preceding 0x6076a0 step

Decision (2026-10-14): the inventory chunks are written as JSON (new chunk type) instead of 0xc1/0xc6; reading 0xc1/0xc6 remains as the migration from vanilla saves. The multiplayer cFile_ram path keeps the binary format.

Slot count by level

SlotCountForLevel (0x57f750): table at 0x95503c, (level, count) u16 pairs: 0 -> 1, 2 -> 2, 8 -> 3, 16 -> 4, 30 -> 5. Used by the taskbar (+0x15c).

Taskbar (cUI_Taskbar2)

Slot controls (0x7c-byte UI_STATIC controls, created in the layout function 0x6e4ba0): weapon sets at +0x164 (5), art slots at +0x178 (5); selection highlight written into the controls (+0x54..+0x60, +0x78) from 0x9ed058. The object's fields are packed behind the arrays (+0x18c ...).

Layout in the 1024 frame, slot width 0x42 (66 px), y = 0xf:

• weapon sets on the left, growing leftwards from the centre: x = 0x18a + (i - n) * 0x42 (n = active slots);
• art slots on the right, growing rightwards: x = 0x280 + i * 0x42;
• SetSlotCount (0x6dffa0, clamps n to 1..5): shows the first n controls of both rows, moves the weapon row, re-selects if the selection is >= n, and rebuilds the decorative fill tiles (UI_STATIC, random variants from 0x9eb0b0 / 0x9eb104 / 0x9eb1ac / 0x9eb200) between the rows and the centre (left from 0x16a - n * 0x42, right from 0x23a + n * 0x40).

With 7 slots the rows reach x = -68 on the left and 1102 on the right, past the 1024 frame (66-78 px each side). In the widened view the centred bar has room for that (16:9: 1365 wide, 170 px each side). Decision 2026-10-14: keep the original spacing; 4:3 is not a target (cut off there).

Art slots without selection (2026-10-15)

Decision: art slots are no longer selected. Slot 0 (leftmost) is always the right mouse button's art; left click stays the normal attack. Keys 0-6 cast slots 0-6 directly (src/mods/skillkeys.cpp): key 0 presses the right button, keys 1-6 select their slot for as long as the key is held and press the right button. Without a held skill key the selection returns to slot 0 (engine tick). cUI_Taskbar2::SelectSkillSlot turns every other request (clicks on the bar, wheel, COMBINE_SLOTS, slot count check) into slot 0; slots on the bar are only filled by drag & drop. Weapon sets are still selected (F1-F7, clicks).

How a slot is drawn (RenderArtSlots 0x6e31e0): each slot is a UI_STATIC control drawn by its vf14; the function swaps the control's atlas entry and rect, draws, and restores them. An art has 3 icons (indices into g_uiAtlasEntries 0x9eaee0, 0x54 each): ready + selected slot uses the third, otherwise the first; while recharging, the slot is drawn twice, split vertically by the ready fraction (first icon above, second below). Icons 0x276-0x278 replace them when the art cannot be used mounted and 0x54fa90 holds (fill from creature +0x4e8 / +0x4ec). Over the icon a frame is drawn: g_uiTaskbarArtFrameSelected 0x9f4be4 / g_uiTaskbarArtFrame 0x9f7f14, 0x9f5d9c as a drop target, 0x9f696c with creature flag 0x2000. UpdateSlotHighlight (0x6df9a0) sets the slot backgrounds (0x9ed084 selected / 0x9ed030). Patched (kTaskbarSkillSelectionLook): frame and background test "slot 0" instead of "selected slot", and every ready art uses its third icon. Slots 1-6 are moved right by half a slot (0x21) after the layout, and the decorative strip right of the centre starts that much further right (add ecx, 23Ah at 0x6e01cc).

Weapon set clicks (2026-10-15): with an empty cursor, the taskbar's mouse handling jumps to 0x6e10d8 (je at 0x6e0ca7; taskbar in esi, inventory in ebp, set at [esp+0B8h], hand at [esp+0BCh]), which takes the set's weapon onto the cursor (TakeWeaponSetItem) and re-selects the selected set. That jump now goes through WeaponSetClickThunk: a click on a set that is not selected only selects it (exit 0x6e124d, al = 1); dragging starts from the selected set only.

Negative x (2026-10-15): with 7 slots the leftmost weapon set (set 1, F1) lies at x = -68..-2 of the layout. The taskbar's own hit test accepts it, but every place that asks the slot controls (vf1c, signed compares) passes the position as and reg, 0FFFFh, so -43 became 65493 and the set could not be clicked. kTaskbarSignedHitTests sign-extends them (slot lookups 0x6dfcfe/0x6dfd5e, the click loops 0x6e1a0c/0x6e1a5c, drop and drag 0x6e1e8e.. 0x6e20f2).

The two 5 x 0xbc blocks at +0x258 / +0x604 are the belt (3D item views), not slots. Still to map: rendering of the slot contents (icons, cooldowns, Render 0x6e3ac0), drag & drop onto slots (HandleEvent mouse branch, 0x5d9480 / 0x5d9680 calls), and whether the UI manager routes mouse events outside 0..1024 to the bar.

Network

Slot changes send network events 299 (SetWeaponSetItem), 300 (SetWeaponSet), 0x129 (SetArtSlot), 0x12a (ClearArtSlot), 0x130 (SelectSlot), 0x123 (SetArtVariant) with the slot index. A server or client running the original only knows 5 slots: slots 6-7 are single player only (or disabled in multiplayer).

Plan

1. Slots 6-7 in a DLL table per inventory index (2 weapon sets, 2 x 2 art slot variants); the original object keeps slots 1-5 unchanged.
2. Hook the accessors above: index >= 5 goes to the table. Extend the 5-slot loops (Clear, ReplaceItemId, FixInventory, load fix-up).
3. Save: saveHero writes the inventories as a JSON chunk (versioned) instead of 0xc1 / 0xc6; loadHero reads the JSON chunk, or migrates a vanilla 0xc1 / 0xc6 chunk through the original reader (slots 6-7 empty).
4. Slot count table: 7 entries; slot 6 at level 45, slot 7 at level 65 (agreed 2026-10-14).
5. Taskbar: 7 controls each (arrays inside the object are fixed at 5: own table for the extra controls), layout, rendering, hit tests, drag & drop.
6. Keys: 0-6 cast art slots (since 2026-10-15; before: 1-7 select and cast), F1-F7 select weapon sets.

Hero files: items of sets 6-7 (2026-10-25)

Reported: the Gladiator lost the weapons of sets 6/7 on Silber. saveHero collects the items it writes (chunk 0xc2) from the weapon sets with GetWeaponSetItem over sets 0..4 (cmp esi, 5 at 0x605046), so sets 6-7 kept ids of items that were never in the hero file; a world that takes its hero from the hero file (Silber without its own hero inventory) had nothing there. The loop bound is patched to 7 (inventory_save.cpp); loadHero's id replacement already covers the shadow slots. Confirmed 2026-10-25.