EquipItem slot validation off by one — EquipmentSlot↔ItemEquipSlot ordinal cast mismatch #793

New Issue

2026-07-22T06:59:52Z

spikerj commented

2026-07-22 06:59:52 +00:00

Found by the coverage wave (spikersoft-backend PR #454) while testing BaseZone.ProcessEquipItemCommand.

PlayerEntity.EquipItem (SpikerSoft.Common IGameEntity.cs ~line 800) validates with:

if (definition.EquipSlot != (ItemEquipSlot)(int)equipSlot && definition.EquipSlot != ItemEquipSlot.None)
    return (false, null);

But the enums are misaligned by one:

EquipmentSlot (IGameCommand.cs): Weapon = 0, Armor = 1, HpPotion = 2, MpPotion = 3, ...
ItemEquipSlot (ItemDefinition.cs): None = 0, Weapon = 1, Armor = 2, HpPotion = 3, MpPotion = 4

So the cast maps EquipmentSlot.Weapon (0) → ItemEquipSlot.None (0), and every item equips only through the command slot one BELOW its real one:

EquipItemCommand { EquipmentSlot = Weapon } with a weapon (e.g. wooden_staff) → rejected
EquipItemCommand { EquipmentSlot = Armor } with that same weapon → accepted (equipment dict then stores the weapon under Armor)

Impact: clients sending the semantically correct slot can never equip anything; whatever works today works by accident of the off-by-one. Fix by mapping explicitly (switch) or aligning the enums — note EquipmentSlot.Armor is documented "Legacy - maps to Torso", so an explicit mapping function is probably the safe fix.

Until fixed, BaseZoneItemCommandTests pins the current off-by-one behavior as characterization tests referencing this issue — they will fail when the mapping is corrected (then flip the expectations).

Found by the coverage wave (spikersoft-backend PR #454) while testing `BaseZone.ProcessEquipItemCommand`. `PlayerEntity.EquipItem` (SpikerSoft.Common `IGameEntity.cs` ~line 800) validates with: ```csharp if (definition.EquipSlot != (ItemEquipSlot)(int)equipSlot && definition.EquipSlot != ItemEquipSlot.None) return (false, null); ``` But the enums are misaligned by one: - `EquipmentSlot` (IGameCommand.cs): `Weapon = 0, Armor = 1, HpPotion = 2, MpPotion = 3, ...` - `ItemEquipSlot` (ItemDefinition.cs): `None = 0, Weapon = 1, Armor = 2, HpPotion = 3, MpPotion = 4` So the cast maps `EquipmentSlot.Weapon (0)` → `ItemEquipSlot.None (0)`, and every item equips only through the command slot one BELOW its real one: - `EquipItemCommand { EquipmentSlot = Weapon }` with a weapon (e.g. `wooden_staff`) → **rejected** - `EquipItemCommand { EquipmentSlot = Armor }` with that same weapon → **accepted** (equipment dict then stores the weapon under `Armor`) Impact: clients sending the semantically correct slot can never equip anything; whatever works today works by accident of the off-by-one. Fix by mapping explicitly (switch) or aligning the enums — note `EquipmentSlot.Armor` is documented "Legacy - maps to Torso", so an explicit mapping function is probably the safe fix. Until fixed, `BaseZoneItemCommandTests` pins the current off-by-one behavior as characterization tests referencing this issue — they will fail when the mapping is corrected (then flip the expectations).

spikerj referenced this issue

2026-07-29 18:20:32 +00:00

wasm-voxel AES is broken — round function missing, keystream is input/IV-independent (not real AES) #811

spikerj referenced this issue

2026-07-29 18:20:46 +00:00

PathManager.GetCachedObstacles always empty — CollectObstaclesInPlace never fills _obstacleArrayBuffer #808

spikerj referenced this issue

2026-07-29 18:21:03 +00:00

ElementRegistry incompatibility lists reference unregistered elements (H→F/Cl, O→Na/K) #792

spikerj referenced this issue

2026-07-29 18:21:14 +00:00

shockwave_fire spell combo can never trigger — un-normalized case in GetComboType #794