I honestly don't know if item evolution is activated in emu server code because I haven't tested it.
Distinctions between (struct*) Item_Struct and (class*) ItemInst:
Item_Struct - All base items are loaded into memory. The identifier* of all 'items' point to these as they are a singular and immutable
reference.
ItemInst - Any 'real' occurrence of an ItemInst(ance) will point to an Item_Struct for identification and property definition. (An 'unreal'
occurrence is what you see in WorldObjects, such as forges, ovens, etc... These have a nullptr reference for identification.)
The current incarnation of 'EvoItems' creates a mutable (changeable) copy of the immutable one inside of the ItemInst class..so,
there are actually two ItemInst occurences of Item_Struct.
All we need to do is have the calling code check for evolutionary status and go from there. (A simple ItemInst->GetProperty() call can
be made to return a property from const Item_Struct* or Item_Struct*)
As far as opcodes, a working client is easy to test, if they are not already defined. The hard part is packet structure discovery.
All of the clients that I have tested allow a direct change of the equipment slots (0-22)..so, only an update packet need be sent when
an item 'evolves.' And since we're only updating the server-side instance, no additional work needs to be done other than a database
update.
The experience-per-kill-per-item-per-etc... will take some analysis of the packet collection data. I can't even speculate on that one...
__________________
Uleat of Bertoxxulous
Compilin' Dirty
|