View Single Post
  #6  
Old 03-23-2013, 07:56 PM
Uleat's Avatar
Uleat
Developer
 
Join Date: Apr 2012
Location: North Carolina
Posts: 2,815
Default

I'm starting a (new) list of functions that will need to be reworked to accommodate the shift to a RoF-compatible inventory system.

The following classes are what I'm currently looking at:

ItemInst::, Inventory::, Client::, Mob::, NPC::, Bot::, Merc::,[*]Database::


These are only the base functions. There will be more that are referred, I'm sure.

If you can think of any other massively affected classes, please post.

---

Not all slot types need mapping allocations. Some are simply channels, like type_corpse, type_inspect, type_bazaar, etc...
We still need to impose per-client limits for these. (i.e., RoF has 200 bazaar slots, VoA- has 80..Ti has 22 inspect slots,
SoF+ has 23, etc...)

Additionally, some slot type maps need limitations to avoid illegal slot usage. (Ti clients shouldn't be able to Auto-Equip
a power source item, nor should pre-RoF clients have access to personal slots 11, 12 and to bag slots over 10.)

[Option 1:]
Hard-code #define's and enum's to account for all clients and use client checks within all affected code.

[Option 2:]
Define an InventoryLimits:: class. Values will be assigned upon Client:: construction - determined by ClientVersion().
Inventory-related functions will use m_invlmts->property accessors to perform their operations.

[Option 3:]
Post your suggestions.

---

If implemented properly, there should be no real issues switching between clients. Older clients will simply not have access
to items stored in higher expansion slots.
__________________
Uleat of Bertoxxulous

Compilin' Dirty
Reply With Quote