Subject of the Week !
-
TOOLTIPS , They are driving me MAD !!!
Ok so here the story around tooltip :
Being implemented around version 1.110 they change the shape of some packet to handle an additional identifier (based on a ushort, 65535 Maximum value...) around 1.112 they "enforced" this behavior to handle other tooltip displays around skills pages, furthermore changing packet shape, but ALSO using previously "unhandled" value as TooltipID !!
Around 1.115/1.116 they're implementing this Tooltip ID inside ITEMS !! In 1.115 there is a new ID in item packet without having any effect, but as a recent update pointed out on Camelot Herald, they're improving their tooltips, so this explain what is this new field in Item packets !!
http://www.darkageofcamelot.com/article/picking-torch
A partial list of planned updates include:
Market Explorer Search Enhancements
A Map + Quest Journal combination and revamp
Tooltip Item Delves
Right-click to equip or swap inventory
Ability list management and Quickbar functionality
Guild and Social Management tools
In-game Mail
The other improvements also bothers me but for Tooltip this is a big trouble now, and I fear that if DOL doesn't lose some custom abilities around old clients it's gonna become unable to handle latests clients...
I don't want to start a discussion around "should we stick to some older version" or something like that, but honestly, people using actual mechanisms will have a HARD time getting up to date !
- How the TOOLTIP work actually ?
Different Game object have attached "unique id" which are sent to Game Client, when Game Client mouse hover or right click this "object" it asks the game server for the appropriate description coming with this tooltipID (and a "type" hint), and then cache the result for one hour !
For the following hour every time the client will go through the same tooltip ID it will get the description from its cache, once its expired it will ask it again from the server...
We can force a "tooltip" cache update by sending new delve packet even if the client didn't ask for it (some kind of "overwrite" packet), it can be used to overwrite cached delve when sending the player skills page or trainer window...
The tooltips delves have been made this way to prevent using too much bandwidth, they're not supposed to be "forced" at login but offered at "query", the ID are supposed to be identical through all the world in case you switch from character or realm or even SERVER !! (It shouldn't be hard to have a "common" tooltip database... for DAOC official servers), and I think that Any live player that could get "tooltip poisoning" will be easily accused of playing on A SHARD !!
- What is Involved with Tooltip ?
- GameEffect :
The "Buff" or "Effect" Bar that displays above your screen, each time a new "effect" is sent there is an "internal ID" attached, previously this was only an incremented id to allow the client to send back the value when asking for "Effect Cancel" now this is always attached to a "Spell" Tooltip, the Buff/Debuff bar doesn't handle anything else than Spell Effect, and when asking for "Effect Cancel" the client will send the tooltip ID to the server !!
This means we can't handle anymore "IGameEffect" that aren't "GameSpellEffect" I can't mix ID's from different world it will get into collisions !! and even if I could all the "Cache" behavior of the Tooltip will fail with Random numbers !!
This is some part where it will break some custom ability, actually all "IGameEffect" aren't cancel-able, each spell having some "colliding" tooltip ID will provoke bugs here...
- TrainerWindow
Here is the second one hard part !
The TrainerWindow, since version 1.105, allows to displays a summary of skill when you "pretend" to spec in a line, when sending the skill list it send "icons" with them and a "internalid", previously this internal ID was used for Delving the displayed "career" spells even if they weren't in your skill page, it was easy to match a "server-cached" collection with the id provided to the client and retrieve them when client ask for delves !
But it's OVER now, this "internalid" is used as tooltip ID too ! So you can't have skills colliding in their own "types" (types are Ability, Realm Ability, Spell, Song, Style) or the tooltip will go wrong, and this have to MATCH the other tooltip displayed in UI (or you'll be wasting bandwidth)
- Skills Page
The skill tree of your character that you use to set your quickbar, this one is easy, there is just a new field, fill it with "0" and get rid of tooltip, fill some "unique id" in your database and they'll match easily to display tooltip using current delve code...
Same as trainer window this is queried with a different type which allow collisions between song/spell/styles/RA/Ability
- Future Items... ??
Coming in next version, how is this going to work ???
I already have some packet log from 1.115 this is clearly an "ID" no "logic" in the numbers sent, I have already witness that some "Materials" for crafting share sometime the same ID... (please don't HARDCODE it !!)
I have no idea on how "Crafted" Item will be handled, I tested on Live crafting and even imbuing an item, the "Tooltip ID" stayed the same, so it's in "ItemTemplate" if we speak in DOL way... (and I don't really know what is expected to display from the Items Tooltips...)
- HOW ?
Tolakram started to propose some kind of "dynamic ID" in 1.115 code, allowing to register a new id with an attached "delve" each time a client needed a new description, there is a lot of chance it will take time to use the whole 65535 pool of ID in the "1 hour" expiry of a tooltip description...
But this break all logic behind cache, it was hard to use this without "forcing" tooltip updates, and we're mostly sure we're going to send duplicate description and waste bandwidth, without forcing tooltip update on a player he just need to log out and log in again to have the server offering "Poisoned Tooltip ID" compared to his own cache...
I tried something in between, trying to get some "value" from database for attaching to object, or use a "default" one or even try to keep uniqueness of ID during at least a server "Runtime" by incrementing static collections
But the truth is ...
DOL doesn't work like "LIVE" DAOC...
Each of our "Spell" doesn't really exists until it was "created" as a spellhandler with the according Spellline and Spell.level !! So sending basic "DBSpell" object to client always report "Level 1" we can't set the level of the spell because we don't know where it come from, or in which spellhandler it was used
Basically this means spells can't be shared, we should have the Level of the spell enforced in spell table, and not linked from linexspell...
That should force us to create a new Database Entry even if two spell are mostly identical but aren't used at the same level !
I know this is pretty bad compared to actual DOL behavior which allows mob to pick up any spell, change its level and cast it, but if we want to easily comply with "Tooltip ID" behavior we can't have as much "scripted" object as we had before, mostly everything must be in Database to track their unique tooltip...
For Mob spell it's not that hard, in theory we just need to build a custom "Spell Line" for mobs, allowing them to choose their spell according to their own Level into this line, it's pretty less permissive than previous DOL handling, but it's one of the only way to track each game effect used through player journey !! (similar in how Animist Shroom works...)
This Spell Effect must also be attached to EVERY Song / Ability / Realm Ability Handler (maybe even Style for the Proc Effects !!)
Song need the Spell Tooltip to display the according effect, it's just a reference tooltip...
Ability/Realm Ability, if they create an Effect that display in player buff/debuff, it must reference some Spell to display a tooltip, or to even handle the Effect Cancel requests...
Enforcing these kind of behavior means it could be the "END" of most user provided scripts...
And we have to think of the future too, Items will be next object to need tooltips and then ? NPC's ? Crafting Skills ? Recipes Pages ? QUEST (OMG
) ??!! Like Mark did with DataQuest, I think we really need to make the server more "data-oriented"