View Single Post
  #2  
Old 03-13-2014, 03:33 PM
Uleat's Avatar
Uleat
Developer
 
Join Date: Apr 2012
Location: North Carolina
Posts: 2,815
Default

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
Reply With Quote