Using the current map schema:
[map<int16, ItemInst> m_name]
Inventory::m_worn {slottype 0, mainslots 0 - 22, subslot -1} [slottype 0 is still split to avoid unnecessary range checks]
Inventory::m_inv {slottype 0, mainslots 23 - 33, subslot -1} [visible cursor is treated the same as inventory slots]
Inventory::m_bank {slottype 1, mainslots 0 - 23, subslot -1}
Inventory::m_shbank {slottype 2, mainslots 0 - 1, subslot -1}
Inventory::m_trade {slottype 3, mainslots 0 - 7, subslot -1}
Inventory::m_tradesk {slottype 4, mainslots 0 - 9, subslot -1}
Inventory::m_buffer {slottype 5, mainslots 0 - 35, subslot -1} [36 matches legacy client buffer size..need to test/buffer is managed]
Inventory::m_tribute {slottype 6, mainslots 0 - 4, subslot -1}
[add more as needed]
Bag (sub) slots will be accessed through Client::m_inv[{slottype, mainslot, subslot}]::m_contents accessors.
[bagsize property is 8-bit, so imposed limit will be 256..server max is 65536]
Here are a few thoughts on where I stand:
- Do away with transferring items out of ItemInst::m_contents into Inventory::m_inv and just use accessors to retrieve the information directly. This will allow the use of 'unlimited' slot containers without having inventory ranges assigned to them.
- Implement a managed cursor buffer to handle cursor 'pushes.' I have a partial one developed, but can't test it until I can send RoF slot_structs directly.
- Use the 6x int16 RoF slot_struct as the basis for slot operations server-side. We can use an abbreviated one (3x int16, or less) where the full isn't needed.
- For the time being, I think we can get away with using the abbreviated (type, main, sub) version for database assignment.
- Item slot allowance bits 21 and 22 need to be swapped in the database.
I have a little more info stewing, but nothing worth reporting.
__________________
Uleat of Bertoxxulous
Compilin' Dirty
|