EQEmulator Forums - Evolving items revisited

EQEmulator Forums (https://www.eqemulator.org/forums/index.php)

- Development::Development (https://www.eqemulator.org/forums/forumdisplay.php?f=590)

- - Evolving items revisited (https://www.eqemulator.org/forums/showthread.php?t=37958)

Evolving items revisited

I know there's been a few threads relating to this, but they have tended to go OT so I thought I'd start a new one.

I've been looking at the source code to see if I can have a stab at implementing it as it's a really good mechanic that I feel is underutilised in live.
To resurrect this, I just want to summarise what I know about these from
https://www.everquest.com/news/imported-eq-enus-50566 (and http://www.everquest.fanra.info/wiki/Evolving_items) :-

Quote:

1. Evolving items were introduced with the Depths of Darkhallow expansion.
2. Evolving items gain experience of their own as your character earns experience. Some of these items will only earn experience from certain types of defeated enemies, while others earn experience from all types.
3. As an evolving item levels, its statistics, powers, and even appearance may change. An evolving item may even gain particle effects, or have current particle effects enhanced. Hidden abilities may also be unlocked as an item evolves. Some evolving items may even possess an "intelligence" that allows them to voice opinions and alerts in certain situations!
You can view your evolving items from your inventory window, under the Evolution tab.
4. Evolving items must be equipped and activated in order to gain experience. They have a "wake up" period after being equipped in which the item will not gain experience. This period occurs each time the item is unequipped and re-equipped.
5. You may control whether an item earns experience by using the checkbox in the evolving item's inspection window.
6. An evolving item's current level, experience toward next level, and stats can be viewed in the item inspection window.
7. The item's experience is stored in the item itself, and so retain its progress if transferred to a new owner (unless flagged as non-tradable).
8. Experience in an evolving item can sometimes be transferred to new evolving items; however, some item experience is lost in the process. The items that are transferable are only items from the Depths of Darkhollow expansion.
9. If you get an evolving item that is lore, you won't be able to have two of them in different states of evolving.

Notes on the above:-

1. September 13th, 2005 Patch.
2. For example, the Alaran Tear only gains xp if you kill *certain* mobs (Alarans+Undead Alarans). You can also evolve it by clicking on certain droppable items. We'd need to factor in making this customisable.
3. Items don't scale like charms do (they may scale in terms of recommended level, however). They are either one level or another.
- When an item levels, any augs are retained.
- When an item "dings", it stays in the equipped slot (i.e. doesn't return to your cursor).
- Intelligent items talk to the owner and are exceptionally irritating, so I'm told (see comments here:- http://everquest.allakhazam.com/db/item.html?item=44874 )
4. On live, you must have the item equipped when a mob dies for the item to gain xp.
- The wake up period appears to be approx 30 seconds. Unsure if it varies between items, but 30 seconds seems reasonable.
- (possibly hearsay as I can't find dev input on this). Evolving items share the experience gained - one of the reasons you can turn on/off evolving item exsperience in the UI. They don't "take" experience from normal/aa xp however.
- Normal task/quest xp does not evolve items (it is possible that a quest specific to that item *could*. The item clicks for the Alaran Tear, in our terms would be an evolving item specific SetExp())
- It is commonly thought that the xp gained is divided by the number of people in group, which is why solo'ing light blues appears to be the quickest way to level them. However look at this from June 13th 2006 patch notes:-

Quote:

- Increased the amount of experience that evolving items gain when you kill an NPC. In addition, you will now gain more experience toward your evolving item when you are in a group, similar to how normal experience works.
- Reduced the amount of experience required to level up intelligent items. If your items now have more experience than is required to level, they will evolve the next time they gain experience.
- Due to the changes to how fast you gain item XP, the amount of XP required to evolve the Cloak of the Spirit Tracker has been increased.
- Evolving an item should no longer cause occasional crashes.

This seems contrary to the previous statement, but it may well be that the xp is simply shared using the same mechanism as group xp (I don't know if having someone too high level in group affects it also), and previously they forgot to implement the group bonus.
- mixed reports on raid xp- some say the amount gained is so small due to the division factor (see obove) that people think it doesn't help, but it does. Others flatly say it doesn't count at all.
- XP modifers such as Lesson of the Devoted do NOT affect item evolution either solo or in group. People also say ZEM's don't affect it but that might be hard to prove.
6. In the 12/08/2010 patch on live the following note was made:-
- The inspect window will now show the final stage of evolving items when clicking on an item link.
8. There is a quest in Corathus Creep to do this http://everquest.allakhazam.com/db/q...tml?quest=3175

What we know from itemdata collects (just using one example for now, choosing one mentioned in one of the above patch notes) that the items are linked by a common id that *isn't* the lore group. For example- http://lucy.allakhazam.com/itemraw.html?id=85613 and http://lucy.allakhazam.com/itemraw.html?id=85612. Both have evoid=1211, both have the same lore group 85612. Both have evomax and evolvlevel (so presumably these are sent to the client to give the "Evolving: Level 2/3" text.) Presumably the server also sends the link to the final result which could be found by searching the item with that evoid and max level (no link sent if evomax==evolvlevel).
The actual experience levels may be a bit of trial and error.

So what I don't know is:-
1. When evolving xp is turned on/off what packets are sent by clients- and do we support them?
2. How to alter item structs so that we can send the % xp, evolving levels and final result to the client for display (again, I presume this will change per client).
3. Whether the server sends out a packet when an item dings- to initiate the swapping in of the new item (aug and all).
4. The actual XP amounts per item (we might have to make educated guesses on these although for the Alaran Tear we know the numbers for the levels https://forums.station.sony.com/eq/i...e-tear.201278/ but not the amount of xp given per kill/the forumal for that).

Obviosuly one my the main concerns is getting packet captures for the various parts of the system (reasonably easy for me to get them on "live", but of course that is probably not compatable with UF/Titanium or even RoF clients).

Anyway, testing the waters to see if current devs want/don't want the input. I don't think I will have issues doing the actual db/server coding (famous last words), just deciphering the packet structs (not that I have any to decipher yet).

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...

Always enjoyed evolving items :)

Well, I think I need to ken the code a bit more. I'm currently stepping through it trying to make sense of how it all hangs together. I haven't really "got" it yet, but I'm sure I will! I'm currently stuck on how the inventory is loaded for each Client. It's a decent sized codebase so should be fun to unpick :)

Don't become too attached to the current way of handling the inventory...

I've spent the last two years digging through just about every aspect of it and am trying to convert it to the new 'location'-based system
from the slot-based it currently uses.

Most of the basic methods and accessors will be changing and it should support all inventory restrictions on a per-client basis.

If you have any questions or issues with the current system, feel free to ask and I'll see if I can't provide a somewhat intelligible answer :P

Brilliant, thanks. Didn't take me too long to find where it's loaded (searched for "from inventory" to find the sql then worked my way up the different calls).

I think I would need to change a fair few things and there would need to be database changes too to support various aspects of the system - for example each item instance has it's own pool of experience that persists between players.

It'll take me quite a bit of time to hash all that out, so you may well have made those changes by the time I start on the code (particularly since I have family staying over for the next few weeks). Regardless, I'll post my ideas before starting the implementation so any dev interested can pitch in. I may well make the odd architectural mistake...

I'd like to keep this thread going..I'm working in the new item instance class right now and would like to try and finalize it before moving on...

I don't see how the client knows what is a base attribute versus what is an evolving attribute.

For instance:
Lucy shows item ID: 60810 as having five fill-able augment slots. The client only see 3 slots..but, the data fields have the augsvisible = false.

This is not even an evolving item..so, how do we know when to activate these?

Evolving items (on lucy) have an evolvl = x and maxevolvl = x. In this case, what attributes are active and not-active at lower levels?

Is there information that we're not reading properly yet, or do all of the repositories have incomplete data for levels 0 -> (x - 1)?

Take a look at the update history of item 60810 and you'll see what I mean...

Any ideas?

I think I have good news for you.. afaik evolving items are not scaling items at all (like charms, for example), but discrete entities (I could be wrong). The current code makes 2 false assumptions (I appreciate though it was never finished): dinging is based on number of kills rather than XP, and that the item scales like charms do.

A level 1 item with 99% XP is no more powerful than a level 1 item with 0% XP. But a level 2 items is a totally different item, with different stats. In other words, we don't need to worry about attribute scaling for evolving items, we just know they are linked by their evolving level and the "evoid", so we just go up the chain of levels when the item dings. Of course, any "recommended level" scaling is still applicable.

For the other slots on that cultural TS item, I couldn't comment. It may well be that there are reserved slots for future expansion (perhaps like the epic 2.5 aug).

If you're looking at item instances, there are some things I would want to implement specifically for evolving items as I don't believe the current support has quite hit the spot (I think the view was they work like charms, when I don't believe they do).

One is when they are equipped there needs to be a timestamp. When the items potentially earns xp, it needs to check that the item is worn, and that n amount of seconds has passed to allow the xp to be earnt (as a guide I think n=30 seconds). This should persist over zones as far as I'm concerned. Of course, if we have a few more item specific events (equip/unequip) we could maybe do this in a script instead (See below).

Secondly, is XP turned on or off for that item? Obviously if it is off then it would not earn xp. This might need to be accessible to scripts.

Thirdly, the item not only has a level but an XP amount - we would need to store this in the DB as it persists over time but also between players.

I haven't yet dived into how the scripting events are hooked up but it would be nice is to have item events triggered on equip and unequip, and when player xp is earnt. That way we could script the items that only gain xp when certain mobs are killed etc. It would be much more flexible than hard-coding it. The flip side is that it's quite nice to have an item 100% defined in the database, although I guess charms are already implemented by that.

In fact, eq live items have access to things like "when the wielder gets a killshot"- I'm not sure if this is currently possible in eqemu - and it's probably a phase two for evolving item implementation.

I don't recall the message you get when the item dings, I guess I will need to level someone up (pretty easy I have 15+ level 85+ characters on live), equip one and get it to ding. I could get packet captures but not sure how useful these would be given it would be for a different client. Any suggestions would be appreciated- it might at least be a good exercise in seeing how the client/server talk in this manner...

Do you have a branch on github so I can be nosey and see what you're up to? :)

Quote:

Originally Posted by Uleat (Post 228911)

For instance:
Lucy shows item ID: 60810 as having five fill-able augment slots. The client only see 3 slots..but, the data fields have the augsvisible = false.

This is not even an evolving item..so, how do we know when to activate these?

Any ideas?

I think the hidden augments are/should be used when you equip a power source?

Have power sources been properly implemented yet?

I played with a few power source items before I left the house and they 'currently' do not affect these hidden slots.

It could be that they are not fully implemented.

I'll have to dig around some more, especially since there was no item information available for those items in the RoF and UF clients.

Quick bump as I'm working on this at the packet level atm, and have opened a Github issue:-
https://github.com/EQEmu/Server/issues/155

Finding out what you need to do is the hard bit, actually doing it is more trivial.

Still a work in progress. I *think* the evo item structure is inserted at 82 judging from below (otherwise it will be the Ornament ID if present):-

Just a brain dump regarding ItemSerializationHeader, based on packet captures on COTF client. It should give *some* indication for earlier clients, although it could get painful trying to backport, esp. pre- ROF:-

Evo items (which have an unknown int32 NOT unint or byte at position 43 which is >0) have an extra 25 bytes in the header, I think at position 82.

If there is an ornament, the id file (IT12345 etc) for the ornament is placed BEFORE the item name (e.g. in ItemSerializationHeader) , 75 bytes away from the 1st "unkn_string". If it is an evo item, there is 25 bytes of extra info BEFORE ornament id, so it starts at 107.

Non evo item, no ornament= ItemSerializationHeader= 110 bytes
Non evo item, ornament= ItemSerializationHeader= 117 bytes. Ornament ID File @ 82
evo item, no ornament= ItemSerializationHeader= 135 bytes
evo item, ornament= ItemSerializationHeader= 142 bytes,Ornament ID File @ 107

For all evo items I have seen so far, regardless of ornamentation or not:-
Evo id (duplicate of Lore group Id, but only stored here for evo items) stored at 82
current evo level= 98 (byte)
evo level max= 99 (byte)
evo xp=94 (% expressed as single, luckily not the mad EQ19 thing)

Nice to hear of steady progress!

Actually it's hit a bit of a roadblock. The issue is that although I know how it is done *now*, it's a needle in a haystack to apply it to older clients. It probably involves either packet captures from those times with evolving items, or some disassembler magic that's currently beyond me.