[Roadmap] DOL to 1.115 Client Support and Fix Merge

[Tolakram]

Here it is: http://www.dolserver.net/viewtopic.php?f=64&t=22154

[Leodagan]

I can't log with 1.115c to Storm RvR, what SVN revision is it using ?

[Tolakram]

It's always on the latest version. Last restart was this morning.

Thanks for looking into the ability icon issue!

[Leodagan]

Workaround committed to DOL SVN revision 3360

I put every skill in the game on the same "Spell Logic" a Skill have an ID (which is brought from DB unique key ideally) to track it through the game, they have an InternalID which is more permissive than strong ID key, used to reference Client Hardcoded values (if needed)

So now Ability use DBAbility.AbilityID (PK AutoInc) as a Skill.ID to uniquely reference them (Needed for Skill disable check !!)
Ability constructor fill Skill.InternalID with DBAbility.InternalID, this is only sent to client for tooltip displaying, if it's not recorded in database the default "0" value will be used and will mostly prevent any tooltip displaying on these abilities...

Styles use Style.ID to fill both values (from what I know Style don't use hardcoded ID and their ID are unique enough)

Specialization use DBSpec.Icon to fill Skill.ID, Skill.Icon, Skill.InternalID, some specs displays icon like "Stealth" but I don't know if there is any tooltip need around this, well it would be easy enough to update the DataObject and simply change the DBSpec properties used in defaut constructor !

SpellLine is always 0, I didn't not find any easy reference to DataObject to think about using some kind of primary key, it's working like that, I have no knowledge about specific spellLine ID being used (no tooltip, no icon, no Action Button ?)

Anyway I update All packet code for sending skills to properly get "Icon", "InternalID" or "TooltipID" where needed, and not rely on sending "ID" by knowing that it's the Icon ID filled in !!

Most Object that need to be manipulated by Network packet should offer "interface" matching the packet shape, this would allow to change how GameObject are sent just by overriding these methods, and not letting the Packet Code handling weird workaround to send value (Well for now we're far from that !!)

// TODO : InternalID or TooltipID should need to be set "virtual" for overriding...

[Leodagan]

Mark, I was tired of Merging and made something for you

I'm finishing some testing and will provide a full Commit with news !

[Leodagan]

New Feature I'm working on : Spell can get Arbitrary Params

Even if the spell table is big enough and some value can be disturbing, I'm adding a new Column, but with the target to reduce all other

I'm ok with having most "common" or "technical" spell values in fixed columns, but some column are used for "internal behavior" and most are used for totally custom value other than what the field name says !!

Example : AmnesiaChance, ResurrectHealth, ResurrectMana, LifeDrainReturn, SubSpellID (annoying because default is to not CHAIN off of this !! to prevent DB chaining errors), IsPrimary, IsSecondary.

These are definitely not used for every spell, and some spellhandler try to handle other values in there !!

These values are also not in need of any indexing or search purpose so even if it's less "database" oriented I would like to add a "Serialized" Params Field to Spells...

This way spells needing special values can handle them in there, it could use descriptive name for key, and it can handle "arrays" for subspell or even property listing for buffs/debuff !!

A lot of objects customizations through DOL could require that a database field allow to init them with proper values, I'm starting with spell because I already put some code in DBSpell, and that this is my major upgrade incoming, 1.110+ tooltip system showed that everything in DAOC that displays a buff/debuff icon is linked to a SPELL !

Well enough talk, here is a short example on how this params field can be used

Code: Select all

var paramsObject = new Dictionary<string, List<string>>(); paramsObject.Add("ResurrectHealth", new List<string>()); paramsObject.Add("ResurrectMana", new List<string>()); paramsObject.Add("SubspellID", new List<string>()); paramsObject["ResurrectHealth"].Add("100"); paramsObject["ResurrectMana"].Add("30"); paramsObject["SubspellID"].Add("65000"); paramsObject["SubspellID"].Add("65001"); paramsObject["SubspellID"].Add("65002"); paramsObject; {{ "ResurrectHealth", { "100" } }, { "ResurrectMana", { "30" } }, { "SubspellID", { "65000", "65001", "65002" } }} var ser = new System.Web.Script.Serialization.JavaScriptSerializer(); ser.Serialize(paramsObject); {"ResurrectHealth":["100"],"ResurrectMana":["30"],"SubspellID":["65000","65001","65002"]} string sParams = "{\"ResurrectHealth\":[\"100\"],\"ResurrectMana\":[\"30\"],\"SubspellID\":[\"65000\",\"65001\",\"65002\"]}"; var dictParams = ser.Deserialize<Dictionary<string, List<string>>>(sParams); dictParams.GetType(); System.Collections.Generic.Dictionary`2[System.String,System.Collections.Generic.List`1[System.String]] dictParams; {{ "ResurrectHealth", { "100" } }, { "ResurrectMana", { "30" } }, { "SubspellID", { "65000", "65001", "65002" } }}

This is typically solving trouble with Heretic Monster Rez, you have the resurrect value used because it's a rez spell, but then you need some subspell id to cast the player to a monster (some kind of shapechange ?) then link some kind of "Plague Pulse", and you need to change its stats to be more tough but can't do anything... And all of this is starting only if the player is pushing "Accept" button, so it's not a basic subspell launching at end of cast or spell landing (Any other arbitrary values needed could have been added here...)

typical getter for single value :

In Any spellHandler

Code: Select all

public byte LifeDrainReturn { get { return Spell.GetParamValue<byte>("LifeDrainReturn"); } }

Code: Select all

/// <summary> /// Parse Params String to Extract the Value identified by Key. /// Expected Format : {"key":["value"#, "value", ...#]#, "key2":[...], ...#} /// From Dictionary<stringKey, List<stringValue>> (List<stringValue>.First() Casted to T) /// </summary> /// <param name="key">Param Key</param> /// <returns>Param Value</returns> public T GetParamValue<T>(string key) { // is key valid ? if (key != null && key.Length > 0) { try { System.Web.Script.Serialization.JavaScriptSerializer ser = new System.Web.Script.Serialization.JavaScriptSerializer(); Dictionary<string, List<string>> dict = ser.Deserialize<Dictionary<string, List<string>>>(m_params); // Is key existing ? if (dict.ContainsKey(key) && dict[key].Count > 0) { try { return (T)Convert.ChangeType(dict[key].First(), typeof(T)); } catch { return default(T); } } } catch { return default(T); } } return default(T); }

Edit : commited to DOL SVN 3362 http://www.dolserver.net/viewtopic.php?f=6&p=152994

[Leodagan]

DOL SVN Revision 3363 Spell Params now use cache for Deserialized params.

[Graveen]

Would it not be better to use a table for handling extra fields ?
ie ExtendedSpell with fields name, spellid, value ? or eventually classname instead of name.

At the instanciation, we could add a Dictionnary<name, value>() to the spell, and handle this according your need through specialized (or existing) handlers.
In addition, we could break spell table in 2: SpellGeneric, and SpellEffect with 1:N relation, while SpellEffect would also not break compatibility.

What do you think ?

[Leodagan]

Well if I was going for an extended table what column would I have there ?

Custom1 Custom2 etc... ? or each specialized field "Resurrect Value" "LifeDrain" "Amnesia" and extend the table each time there is a new field needed ? Or other table ?

Or a Value / Relation Table, ex => SpellXValue {Ref "SpellID", "KeyName", "Value"} ?

The last one is more into database logic, but it needs to handle relation, it can be used to create "arrays" of values by using multiple time the same "KeyName" for a specific SpellID so it can bring the same feature as a param field with serialized dictionary...

I think you're expecting some kind of new spell build that would handle spell like a collection of "SpellEffect" that would allow to simply build composite spell from basic objects (LifeTap = DD + Lifedrain, OmniTap = LifeDrain + ManaDrain + EndDrain) ?

honestly I don't think even live server use anything like this, and when each spell will be made as collection of spelleffect we will end with the same trouble as now...

The simplest way to imagine your relation between spell and their effect would be to add a table "SpellType" that link Spell Class with their current "Spells" Implementations, we would need all current field from Spell to describe each effect, so grouping spell for now will not help


So that brings us to : Even a SpellEffect Table will need custom values


The Serialized string was the easiest way to prevent from creating new table, or relation, and it perfectly handles missing value in there returning default(T) so that's not breaking compatibility for now, if a spellhandler try to get a custom serialized field that doesn't exist it will return 0/null/string.empty until the Params field is filled with a valid JSON content...

I can use a new table for custom field if you think it's better, but for handling spell like composite effects objects it's a whole different work

[Leodagan]

Ok I'm a bit impatient, I have a lot of free time these days and want to go forward on this

The Serialized string has a lot of "Con" :

- Users need to know the format as there isn't any tool to manipulate this for now (using a C# shell like I did...)
- Dynamically migrating database field will need to use a lot of string methods to insert value into existing serialized string (or maybe use some kind of SQL method to Parse them, I know PostGreSQL is able to handle this serialized as table field/object)
- No easy way to "Store" a value in custom properties this is more read-only oriented, some SpellHandler would change custom values during casting (not in Spell object itself but in handlers property mimicing spell properties...)
- Can't be indexed in database...

My previous reply at least show that the Table Spell <> CustomValue relation, could be easily implemented and will allow easier database handling, I'm gonna work in this way.

Edit : got a working version of table oriented custom values.

[Graveen]

I personnally dislike the serialization, for the drawbakcs you mention. I'm more in the mood of using relationnal tools allowing 1:n.

For DOL i simply think you should ensure compatibility, at this point. I won't formerly say 'this is a bad idea, don't put it in the core' at an involved coder like you

Related to composition of spell, I don't think the building would be so complex. As you point it, some simples actions such as drain could have more parameters and be composed by 2 actions (damage, heal), although in this case i don't think it is a good idea. But even if it is not standing this way in the database, it is standing right in the code - understand Drain is Heal(Damage(x)*modifier)).

On a quick note, imho, the two major drawback would finally be:
- using a generic field for value is strictly.. a problem we have with big spell table. But we don't have dozens of dummy fields
- some like drain could need to handle 2 values (damage & % returned) so 2 generic fields.. As discussed before, you could handle it in 2 actions (damage & heal), but somehow you must define the correct relation between 2, and that's not easy. One solution 'd be to handle draindamage & drainheal actions, where you explicitely know the drainheal is in % of draindamage, hrmmm.... not sure if the best.

[Leodagan]

If we go through a composition of effects, like you say the first trouble will be to know the previous state...

And the specific lifetap spell is known to be a composite spell on live DAOC that also cause trouble to double resists check (well I still think this could be false, but that would explain why some classes lifetap have a way higher dps than standard nukes...) so if it can double check resists (spell miss) that means the "heal" effect is more a "lifedrain" effect which is targeted at an enemy ! (a heal couldn't miss !!)

I still don't really understand if the spell should be totally missed if any of effects resists, or if there is some "order" in effect checks, does lifedrain runs its own "damage" calc without removing health to not rely on previous results ? can a lifetap resist the damage part but not the lifedrain part ?

The other example is the Nearsight+debuff spell, I don't remember on live, but on current DOL implementation there is 2 icons displaying, 1 debuff effect for Nearsight, 1 debuff effect for resist debuff, any of them can fail on landing I think, subspell is triggered at end of cast even if the first spell miss.

And the final "VIEW" we have into official server spell algorithms is this fracking Warlock, the composition of spell it use is definitely a BIG hint on how DAOC handle composite spells ! If they made this class this way it's obviously because of an easy implementation on their side...

For all this we can still use a simple relation between spells record to make a "grouped" spell, thus not breaking compatibility with actual system !

To handle "previous state" the best is still to use a "master spell handler" launching "subspell" which could order the spell cast sequence to its convenience (easily overriding the castsubspell() methods...) the master spell still needs to reference cast times, power cost, range, every property that is meant for the "full cast sequence" !

But the actual downside of chaining subspell is that the Core doesn't allow chain-linking (probably to prevent any infinite loop, I really don't know how the core behave to this !! detecting it would be a nightmare !), and even if it looks stupid I'm pretty ok with preventing a "data" oriented infinite loop

------

Anyway I removed the serialized field in favor of a 1:n table of custom fields, it's loaded through the same methods in game spell object, and the example I showed previously will still work the same, but now with some "JOIN" you can retrieve all attached spell data in your SQL browser

If you put nothing in this table, nothing will be added to your spell record, property getter will return default values, nothing rely on any data in this custom table for something critical actually. (Except song Icon Displaying ! 43 important records maybe...)

This doesn't prevent from going into "effect compositing", imagine you create a new SpellHandler "CompositeSpellHandler", that will need to find keys in the custom table "EffectsCollection" this will allow to build a new "BaseSpellHandler" using any field it needs, completely tracked trough it's master record in spell table that can be used right away with basic behavior using the spell field (cast time, power cost etc... always the same for full cast sequence) and use normalized custom field for all scripted composite effect !

ex : CompositeSpellHandler derives SpellHandler, and implement "IEffectComposition" methods, needing collection of "EffectType" described by strings in the Custom Value table, referencing classes implementing "ICompositeEffect", this way you can build your totally own spell logic without impacting other spells, slowly replacing all spell derived from SpellHandler to use Spell derived from CompositeSpellHandler and having a totally new namespace full of "basic spell effect implementation"

Honestly I won't go this way for now, I'll keep that in mind while designing new spells, I don't know what would be the feeling of seeing a "ClassType" "CompositeDebuffSpell" and have to read custom values to know what the spell is doing I don't think that most of the spell need composition, and that it should be used on "exception" basis, to prevent moving too far from actual code implementations !!

In fact I still think most Exceptions will be handled as basic subspell or as specific spellhandler that can handle a specific subspell collection or other custom values...

That's how it worked up until now, this is why AmnesiaChance can change a Charm Spell Handler Mob type (and nothing documents this without opening the Handler source !!) custom values can make this better and allow much higher level spellhandler implementation

[Graveen]

Good move

/worship !

[Leodagan]

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"

[Graveen]

Interesting.

Can't we simply ignore the tooltip, or implement it to always be valid ? ie always a known (and valid) item (to avoid tt cache poisonning) ?