EMu Inventory Overhaul

[Uleat]

I had already started a proposal for reworking the way the inventory is structured, based on VoA concepts, prior to the Steam RoF offering.
Seeing as how there are now new features that need to be accounted for, and fixes to the old system that need to be accomplished, now is probably
the best time to bring this up.

Nomenclature							EQEMu Reference (New)						EQEMu Reference (Old)
Range		MainSlot		SubSlot			Range (uint16)	MainSlot (uint16)	SubSlot (uint16)	Slot (sint16)

Worn		Charm			Parent			1 << 0		0			0			0
Worn		Ear01			Parent			1 << 0		1			0			1
Worn		Head			Parent			1 << 0		2			0			2
Worn		Face			Parent			1 << 0		3			0			3
Worn		Ear02			Parent			1 << 0		4			0			4
Worn		Neck			Parent			1 << 0		5			0			5
Worn		Shoulders		Parent			1 << 0		6			0			6
Worn		Arms			Parent			1 << 0		7			0			7
Worn		Back			Parent			1 << 0		8			0			8
Worn		Bracer01		Parent			1 << 0		9			0			9
Worn		Bracer02		Parent			1 << 0		10			0			10
Worn		Range			Parent			1 << 0		11			0			11
Worn		Hands			Parent			1 << 0		12			0			12
Worn		Primary			Parent			1 << 0		13			0			13
Worn		Secondary		Parent			1 << 0		14			0			14
Worn		Ring01			Parent			1 << 0		15			0			15
Worn		Ring02			Parent			1 << 0		16			0			16
Worn		Chest			Parent			1 << 0		17			0			17
Worn		Legs			Parent			1 << 0		18			0			18
Worn		Feet			Parent			1 << 0		19			0			19
Worn		Waist			Parent			1 << 0		20			0			20
Worn		Power Source		Parent			1 << 0		21			0			9999
Worn		Ammo			Parent			1 << 0		22			0			21
Worn		<…>			Parent			1 << 0		<…>			0			{ DNE }
Worn		<Unknown>		Parent			1 << 0		65535			0			{ DNE }


Personal	Inventory 1		Parent (Child Range)	1 << 1		0			0 (1 - 65535)		22 (251 - 260)
Personal	Inventory 2		Parent (Child Range)	1 << 1		1			0 (1 - 65535)		23 (261 - 270)
Personal	Inventory 3		Parent (Child Range)	1 << 1		2			0 (1 - 65535)		24 (271 - 280)
Personal	Inventory 4		Parent (Child Range)	1 << 1		3			0 (1 - 65535)		25 (281 - 290)
Personal	Inventory 5		Parent (Child Range)	1 << 1		4			0 (1 - 65535)		26 (291 - 300)
Personal	Inventory 6		Parent (Child Range)	1 << 1		5			0 (1 - 65535)		27 (301 - 310)
Personal	Inventory 7		Parent (Child Range)	1 << 1		6			0 (1 - 65535)		28 (311 - 320)
Personal	Inventory 8		Parent (Child Range)	1 << 1		7			0 (1 - 65535)		29 (321 - 330)
Personal	Inventory 9		Parent (Child Range)	1 << 1		8			0 (1 - 65535)		{ DNE }
Personal	Inventory 10		Parent (Child Range)	1 << 1		9			0 (1 - 65535)		{ DNE }
Personal	Inventory <…>		Parent (Child Range)	1 << 1		<…>			0 (1 - 65535)		{ DNE }
Personal	Inventory 65536		Parent (Child Range)	1 << 1		65535			0 (1 - 65535)		{ DNE }


Cursor		Cusor			Parent (Child Range)	1 << 2		0			0 (1 - 65535)		30 (331 - 340)
								
								
Tribute		Tribute 1		Parent			1 << 3		0			0			400
Tribute		Tribute 2		Parent			1 << 3		1			0			401
Tribute		Tribute 3		Parent			1 << 3		2			0			402
Tribute		Tribute 4		Parent			1 << 3		3			0			403
Tribute		Tribute 5		Parent			1 << 3		4			0			404
Tribute		Tribute <…>		Parent			1 << 3		<…>			0			{ DNE }
Tribute		Tribute 65536		Parent			1 << 3		65535			0			{ DNE }
								

Bank		Bank 1			Parent (Child Range)	1 << 4		0			0 (1 - 65535)		2000 (2031 - 2040)
Bank		Bank 2			Parent (Child Range)	1 << 4		1			0 (1 - 65535)		2001 (2041 - 2050)
Bank		Bank 3			Parent (Child Range)	1 << 4		2			0 (1 - 65535)		2002 (2051 - 2060)
Bank		Bank 4			Parent (Child Range)	1 << 4		3			0 (1 - 65535)		2003 (2061 - 2070)
Bank		Bank 5			Parent (Child Range)	1 << 4		4			0 (1 - 65535)		2004 (2071 - 2080)
Bank		Bank 6			Parent (Child Range)	1 << 4		5			0 (1 - 65535)		2005 (2081 - 2090)
Bank		Bank 7			Parent (Child Range)	1 << 4		6			0 (1 - 65535)		2006 (2091 - 2100)
Bank		Bank 8			Parent (Child Range)	1 << 4		7			0 (1 - 65535)		2007 (2101 - 2110)
Bank		Bank 9			Parent (Child Range)	1 << 4		8			0 (1 - 65535)		2008 (2111 - 2120)
Bank		Bank 10			Parent (Child Range)	1 << 4		9			0 (1 - 65535)		2009 (2121 - 2130)
Bank		Bank 11			Parent (Child Range)	1 << 4		10			0 (1 - 65535)		2010 (2131 - 2140)
Bank		Bank 12			Parent (Child Range)	1 << 4		11			0 (1 - 65535)		2011 (2141 - 2150)
Bank		Bank 13			Parent (Child Range)	1 << 4		12			0 (1 - 65535)		2012 (2151 - 2160)
Bank		Bank 14			Parent (Child Range)	1 << 4		13			0 (1 - 65535)		2013 (2161 - 2170)
Bank		Bank 15			Parent (Child Range)	1 << 4		14			0 (1 - 65535)		2014 (2171 - 2180)
Bank		Bank 16			Parent (Child Range)	1 << 4		15			0 (1 - 65535)		2015 (2181 - 2190)
Bank		Bank 17			Parent (Child Range)	1 << 4		16			0 (1 - 65535)		2016 (2191 - 2200)
Bank		Bank 18			Parent (Child Range)	1 << 4		17			0 (1 - 65535)		2017 (2201 - 2210)
Bank		Bank 19			Parent (Child Range)	1 << 4		18			0 (1 - 65535)		2018 (2211 - 2220)
Bank		Bank 20			Parent (Child Range)	1 << 4		19			0 (1 - 65535)		2019 (2221 - 2230)
Bank		Bank 21			Parent (Child Range)	1 << 4		20			0 (1 - 65535)		2020 (2231 - 2240)
Bank		Bank 22			Parent (Child Range)	1 << 4		21			0 (1 - 65535)		2021 (2241 - 2250)
Bank		Bank 23			Parent (Child Range)	1 << 4		22			0 (1 - 65535)		2022 (2251 - 2260)
Bank		Bank 24			Parent (Child Range)	1 << 4		23			0 (1 - 65535)		2023 (2261 - 2270)
Bank		Bank <…>		Parent (Child Range)	1 << 4		<…>			0 (1 - 65535)		{ DNE }
Bank		Bank 65536		Parent (Child Range)	1 << 4		65535			0 (1 - 65535)		{ DNE }


Shared Bank	Shared Bank 1		Parent (Child Range)	1 << 5		0			0 (1 - 65535)		2500 (2531 - 2540)
Shared Bank	Shared Bank 2		Parent (Child Range)	1 << 5		1			0 (1 - 65535)		2501 (2541 - 2550)
Shared Bank	Shared Bank <…>		Parent (Child Range)	1 << 5		<…>			0 (1 - 65535)		{ DNE }
Shared Bank	Shared Bank 65536	Parent (Child Range)	1 << 5		65535			0 (1 - 65535)		{ DNE }


Trade		Trade 1			Parent (Child Range)	1 << 6		0			0 (1 - 65535)		3000 (3100 - 3109)
Trade		Trade 2			Parent (Child Range)	1 << 6		1			0 (1 - 65535)		3001 (3110 - 3119)
Trade		Trade 3			Parent (Child Range)	1 << 6		2			0 (1 - 65535)		3002 (3120 - 3129)
Trade		Trade 4			Parent (Child Range)	1 << 6		3			0 (1 - 65535)		3003 (3130 - 3139)
Trade		Trade 5			Parent (Child Range)	1 << 6		4			0 (1 - 65535)		3004 (3140 - 3149)
Trade		Trade 6			Parent (Child Range)	1 << 6		5			0 (1 - 65535)		3005 (3150 - 3159)
Trade		Trade 7			Parent (Child Range)	1 << 6		6			0 (1 - 65535)		3006 (3160 - 3169)
Trade		Trade 8			Parent (Child Range)	1 << 6		7			0 (1 - 65535)		3007 (3170 - 3179)
Trade		Trade <…>		Parent (Child Range)	1 << 6		<…>			0 (1 - 65535)		{ DNE }
Trade		Trade 65536		Parent (Child Range)	1 << 6		65535			0 (1 - 65535)		{ DNE }


World Container	World Container 1	Parent			1 << 7		0			0			4000
World Container	World Container 2	Parent			1 << 7		1			0			4001
World Container	World Container 3	Parent			1 << 7		2			0			4002
World Container	World Container 4	Parent			1 << 7		3			0			4003
World Container	World Container 5	Parent			1 << 7		4			0			4004
World Container	World Container 6	Parent			1 << 7		5			0			4005
World Container	World Container 7	Parent			1 << 7		6			0			4006
World Container	World Container 8	Parent			1 << 7		7			0			4007
World Container	World Container 9	Parent			1 << 7		8			0			4008
World Container	World Container 10	Parent			1 << 7		9			0			4009
World Container	World Container <…>	Parent			1 << 7		<…>			0			{ DNE }
World Container	World Container 65536	Parent			1 << 7		65535			0			{ DNE }


Cursor Buffer	Cursor Buffer		Parent			1 << 8		(0 - 36 { client max })	0			8000 - 8101 { db max: 8999 }


Overload Items	Overload Items		Parent			1 << 9		(0 - 65535)		0			{ DNE }


Buy Back	Buy Back		Parent			1 << 10		(0 - 65535)		0			{ DNE }

- Each range would essentially be unlimited, as would the number of bag slots.
- The 'Overload Items' range would contain items that are pushed to cursor when the cursor buffer is full.
- The 'Buy Back' range accomodates the RoF client's merchant buy back of deleted items.
- { DNE } - 'Does Not Exist'


Some mild conversions will be needed for all clients, more for older ones. This probably doesn't match what the RoF client uses, but is
likely closer than the existing if it uses anything resembling the VoA.

This also gives us the flexibility we need for parsing range functions.

[trevius]

Starting the discussion back up on this since it is basically required to implement RoF completely for EQEmu.

I think your system looks pretty good for the most part. Though, the "range" stuff could probably just be changed to match the RoF slot type system. That should leave no conversions needed for RoF slots. The only issue I see with following the RoF slot system exactly is the possibility that another slot could be added to the worn inventory, which would push the main inventory slots up by 1 (or whatever number) for future clients (which would be a simple conversion in the patch files). If the types get changed up, that would mean another conversion would be needed as well, but I don't think it would require any major work at all.

I think the benefits of using the RoF slot system probably outweigh the cons. It would mean less confusion about which slot is which when looking at the slot stuff between what is stored in the DB and what is used by the client. There would be no need to have to look up what slot type 20 (buy back for example) for RoF is in the DB, they would just match. Their system is already very flexible and is very similar to what you put together minus splitting up worn and main inventory.

We already know most of the slot types from RoF are as follows:
0 - Worn and Main Inventory Slots
1 - Bank Slots
2 - Shared Bank Slots
3 - Trade Slots
4 - Tradeskill Container Slots
5 - Cursor Buffer
6 - Tribute Slots
20 - Buy Back/Reclaim Slots
21 - Parcel Slots

We also have the conversion functions in RoF.cpp that would be needed for the older clients to use the Titanium system.

Since it is a pretty big project to move to a new slot system, I was thinking we might be able to break it up a bit and just use conversion functions that can be moved to different parts of code as we progress. For example, we could start off by providing SQL that will convert the slots in the inventory system to the new slot system, and then use conversion functions to convert to Titanium slots after it loads them from the DB (as well as when it saves to the DB) until further support is in place. Then work through all of the code that deals with slot stuff and finally put in conversions in the patch files for each of the older clients that will need it and change all of the related structs in eq_packet_structs.h.

One issue with converting the inventory table will be that I think augments will need to be stored in their own rows instead of in the same row as the item they are augmenting. This should allow for more flexibility anyway, but will require a bit more thought on making sure the SQL is correct to convert them all. Basically, augments will be loaded the same way as items inside a bag.

Also, I am sure we will need to review how these changes will affect corpse blobs with items in them, as that thing is always messy to deal with. Ideally that blob should go away at some point and be replaced with separate tables for player_corpses and player_corpse_inventory or something like that.

More thoughts to come as time permits...

[Uleat]

I've learned a lot more of the current inventory and RoF inventory since making that.

Let me post a revamp, albeit truncated, version of where I stand with it.

I do agree with what you say though.

(I can hear Sorvani now: 'Did he just say truncated, as in shorter?')

[Uleat]

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.

[trevius]

Noting a few pieces of code here for possible reference with the new slot system implementation. This is based on some recent info from the client itself that probably needs to be explored a bit more.

// Used for the new slot system
struct SlotStruct {
/*000*/ int16 SlotType;		// Worn and Normal inventory = 0, Bank = 1, Shared Bank = 2, Delete Item = -1
/*002*/ int16 MainSlot;
/*004*/ int16 SubSlot;		// Slot inside a bag or an aug slot of an item
/*006*/
};

enum {
	SLOT_TYPE_MAIN = 0,			// Worn items and main inventory
	SLOT_TYPE_BANK = 1,
	SLOT_TYPE_SHARED_BANK = 2,
	SLOT_TYPE_TRADE = 3,
	SLOT_TYPE_WORLD = 4,
	SLOT_TYPE_LIMBO = 5,		// Cursor Buffer
	SLOT_TYPE_TRIBUTE = 6,
	SLOT_TYPE_TROPHY_TRIBUTE = 7,
	SLOT_TYPE_GUILD_TRIBUTE = 8,
	SLOT_TYPE_MERCHANT = 9,
	SLOT_TYPE_DELETED = 10,
	SLOT_TYPE_CORPSE = 11,
	SLOT_TYPE_BAZAAR = 12,
	SLOT_TYPE_INSPECT = 13,
	SLOT_TYPE_REAL_ESTATE = 14,
	SLOT_TYPE_VIEWMOD_PC = 15,
	SLOT_TYPE_VIEWMOD_BANK = 16,
	SLOT_TYPE_VIEWMOD_SHARED_BANK = 17,
	SLOT_TYPE_VIEWMOD_LIMBO = 18,
	SLOT_TYPE_ALT_STORAGE = 19,
	SLOT_TYPE_ARCHIVED = 20,	// Reclaimable Items
	SLOT_TYPE_MAIL = 21,		// Parcel Items
	SLOT_TYPE_GUILD_TROPHY_TRIBUTE = 22,
	SLOT_TYPE_OTHER = 23
};



enum {
	invWhereWorn 				= 0x01,			// 1
	invWherePersonal			= 0x02,			// 2 - in the character's main inventory
	invWhereBank				= 0x04,			// 4
	invWhereSharedBank			= 0x08,			// 8
	invWhereTrading				= 0x10,			// 16
	invWhereCursor				= 0x20,			// 32
	invWhereWorld				= 0x40,			// 64
	invWhereLimbo				= 0x80,			// 128
	invWhereTribute				= 0x100,		// 256
	invWhereTrophyTribute		= 0x200,		// 512
	invWhereGuildTribute		= 0x400,		// 1024
	invWhereMerchant			= 0x800,		// 2048
	invWhereDeleted				= 0x1000,		// 4096
	invWhereCorpse				= 0x2000,		// 8192
	invWhereBazaar				= 0x4000,		// 16384
	invWhereInspect				= 0x8000,		// 32768
	invWhereRealEstate			= 0x10000,		// 65536
	invWhereViewModPC			= 0x20000,		// 131072
	invWhereViewModBank			= 0x40000,		// 262144
	invWhereViewModSharedBank	= 0x80000,		// 524288
	invWhereViewModLimbo		= 0x100000,		// 1048576
	invWhereAltStorage			= 0x200000,		// 2097152
	invWhereArchived			= 0x400000,		// 4194304
	invWhereMail				= 0x800000,		// 8388608
	invWhereGuildTrophyTribute	= 0x1000000,	// 16777216
	invWhereOther				= 0x2000000,	// 33554432
	invWhereAll					= 0x3FFFFFF		// 67108863
};

	// Player inventory
	map<int16, ItemInst*>	m_worn;				// Type: 0, Main: 0  to 22	- Items worn by Character
	map<int16, ItemInst*>	m_inv;				// Type: 0, Main: 23 to 33	- Items in Personal Inventory and Visible Cursor Item
	map<int16, ItemInst*>	m_bank;				// Type: 1, Main: 0  to 23	- Items in Bank
	map<int16, ItemInst*>	m_shbank;			// Type: 2, Main: 0  to 1	- Items in Shared Bank
	map<int16, ItemInst*>	m_trade;			// Type: 3, Main: 0  to 7	- Items in a Trade Session
	map<int16, ItemInst*>	m_world;			// Type: 4, Main: 0  to 10	- Items in World Containers
	map<int16, ItemInst*>	m_limbo;			// Type: 5, Main: 0  to 36	- Items in Cursor Buffer/Limbo
	//map<int16, ItemInst*>	m_tribute;			// Type: 6, Main: 0  to 4	- Items in Tribute (Handled by Bonuses?)
	//map<int16, ItemInst*>	m_trophytrib;		// Type: 7, Main: 0  to 4	- Items in Trophy Tribute (Handled by Bonuses?)
	//map<int16, ItemInst*>	m_guildtrib;		// Type: 8, Main: 0  to 4	- Items in Guild Tribute (Handled by Bonuses?)
	//map<int16, ItemInst*>	m_merchant;			// Type: 9, Main: 0  to 80	- Items in Merchant (sold?) (No need to store this?)
	map<int16, ItemInst*>	m_deleted;			// Type: 10, Main: 0  to X	- Items in Deleted Pool? Same as Archived/Reclaim?
	map<int16, ItemInst*>	m_corpse;			// Type: 11, Main: 0  to 33	- Items in Corpse(s)
	map<int16, ItemInst*>	m_bazaar;			// Type: 12, Main: 0  to 200	- Items in Bazaar
	//map<int16, ItemInst*>	m_inspect;			// Type: 13, Main: 0  to 22	- Items in Inspect Window (No need to store this?)
	map<int16, ItemInst*>	m_realestate;		// Type: 14, Main: 0  to X	- Items in Player Housing
	//map<int16, ItemInst*>	m_vmpc;				// Type: 15, Main: 0  to 23	- Items in View Mod Worn/Personal (No need to store this?)
	//map<int16, ItemInst*>	m_vmbank;			// Type: 16, Main: 0  to 23	- Items in View Mod Bank (No need to store this?)
	//map<int16, ItemInst*>	m_vmshbank;			// Type: 17, Main: 0  to 1	- Items in View Mod Shared Bank (No need to store this?)
	//map<int16, ItemInst*>	m_vmlimbo;			// Type: 18, Main: 0  to 36	- Items in View Mod Limbo (No need to store this?)
	map<int16, ItemInst*>	m_altstorage;		// Type: 19, Main: 0  to X	- Items in Alternate Storage
	map<int16, ItemInst*>	m_archived;			// Type: 20, Main: 0  to X	- Items in Reclaim Window
	map<int16, ItemInst*>	m_mail;				// Type: 21, Main: 0  to X	- Items in Mail/Parcels
	//map<int16, ItemInst*>	m_guildtrophytrib;	// Type: 22, Main: 0  to 4	- Items in Guild Trophy Tribute (Handled by Bonuses?)
	map<int16, ItemInst*>	m_other;			// Type: 23, Main: 0  to X	- Items in Other
	//ItemInstQueue			m_cursor;			// Type: 5, Main: 0  to 36	- Items on Cursor: FIFO - replaced by m_limbo

[Uleat]

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]

Ok, I have finally started an 'inventory_conversion' branch.

There is a huge learning curve going on here, so don't expect results over-night. But, I am finally past the basic hurdles that kept me from
posting git updates to this point.


As far as the content, people can check it out to see where it's going, but it will not be usable by the public until it is ready to be merged back into
'master.' (to wit: It is not compilable and will corrupt your current database until it is ready to be deployed.)


Progress, as of this posting, is limited to an 'alpha' InventoryLimits class and the script to swap 'ammo' and 'power source' bits in the database.

More to come as I implement and refine my notes from previous experimentation.

[wolfwalkereci]

Good news, keep us posted and thanks for doing this work.

[Uleat]

no worries

I think I'll be able to get more people on board once I can get the basic format ironed out. Then, it'll just be a matter of connecting the dots.


There's a lot of RoF features that we could currently support, but the work-arounds would kill the code..not to mention the wasted time in
doing so.

This conversion should allow a more simplistic implementation of those features, and allow us to un-cap some of the current inventory limitations.

[Uleat]

(Obviously, I haven't updated this in a while...)

Is anyone up to speed on ItemInst's that are used as world containers? (m_use_type == ItemUseWorldContainer and/or m_item == nullptr)


I'm wanting to drop the supporting code from ItemInst and either create a derived class or a smaller class with only what is required
for world containers..reducing the size of both.

I can find the initiators for world containers, but can't seem to locate any method calls associated with them.

If you can help, please post a reply or pm me.

Thanks!


(I've revamped the mapping schema a few times, but with the help of a few devs, I think it is final. I've updated the ItemInst and Inventory
class code for both previous schema, and am nearing completion of development stage on these. The next step will be to modify code
outside of Item.h/.cpp.)

[Drajor]

Most of the code dealing with world containers is in tradeskills.cpp

[Uleat]

Thanks! That did help


So, for Client::m_tradeskill_object:

1) I'm either dealing with a db zone entity object, with no Item_Struct reference, or..
2) an ItemInst instance of a valid Item_Struct container...

Are there any cases where either is not true, or there could be additional conditions?


I mean, I can always go back and modify as needed..but, I want to have a solid footing as I'm going down the path.

[Drajor]

I don't have access to the source here however iirc those are the only two cases supported by emu. If there are others on live, I do not know.

It may be too early to answer but will the changes to inventory be a 'drop in' replacement, i.e. same system interfaces, or will references to inventory need to be updated?

[Uleat]

I wouldn't exactly call it a drop-in system, but I hope to have it at least current with existing client support and perl/lua scripts.


I'm trying to pull item control back into Inventory and away from ItemInst. There's really no way to fully regulate client validity from ItemInst. The best
that can be done from ItemInst is server validity.

So, there will definitely be new accessors attached to higher classes and a removal of others in lower ones. I'll wiki it once it becomes mergeable.


We'll have scripts to convert existing databases..there will be changes all over... (mostly inventory slot-related, but a few item ones as well.)


I can't promise a timeline, or that this will ever even become live. But, I'll do what I can with it and see where it goes.

[Uleat]

Ok...

So, I have finally admitted defeat on pushing a full conversion. The scope of the project is just WAY too much for a single implementation - from me.

I stepped back and took a renewed look at what has to done and am plodding towards small, but doable, changes.


The first noticeable change will likely be a re-ordering of the worn/personal/cursor slots. The ordering will reflect that of the RoF+ clients. Looking at
the InventoryMainTypes enumeration in "../common/eq_constants.h" will indicate the order.

RoF general slots 9 & 10 will be added, as well as their bag slots in the 341 - 360 range. Greater than 10-slot bags will still have to wait for the
implementation of the new Location_Struct-based system.

Anyways..hopefully, I can start rolling out these changes a little faster than has been... I know the starting and end points..it's what's in-between
that's is hard