Get Spell handlers clean !
This is way easier to say than to do
But actually I had quite some work done, mostly tested, not up to the quality I wanted it, but now with Career implementation I can have a new view on this matter !
So Here what I'm expecting to do around spells :
- Sort all existing spell handlers out, a lot of them are having duplicate effects or similar effects, a lot of them could inherit other spell handler to obtain the expected behavior
- Remove "Hardcoded" Spell Handler, Sorry for the guys who did all this "Astral Work" or this "Master Level" implementation, or even some specific class like Heretic, Bainshee, Necromancer, Bonedancer, and Warlock spell handler... most of them could inherit "base" existing spell handler and obtain the desired effect will only small override, this is a whole mess actually, some Subclass are just meant to hardcode some specific values, some spell handler are totally copy/paste from other file to mimic the spell effect with small differences...
- Update most Spell Handler to extend "DOL Event Handlers", actually a lot of spell use hardcoded checks in Living or Player class to match the desired effect if the spell handler can be found on the game object... I admit there are some trouble with DOL event Handler that are not "predictive" you don't know if an other event will garbage the data your listening to or do anything based on the result of the data that your handler will change !
There is still a wide range of use for these handler, listening to spell casting to change target with specific ML spells, handle chambers as "spell effects" instead of having it all hardcoded in player code...
Bladeturn are the best example of the spells that could use this behavior, and the best example to show the need of having precise event that could occur before or after any action taken (bladeturn could mess with health buffer if no order is enforced !!) - Improve the actual base SpellHandler Implementation to be more generic and handle nicely even specific spell handler (Focus Handling is a mess actually and can't handle an AOE focus effect, Song Handling is not great it's targeted to beneficial group buff effect and is a mess when used for Flute Mezz which must be implemented as a spell most of the time !)
Most of my code improvements rely on this strong review of the Spell Handler object, more than 60% of the code changed, this allow for pretty easier implementation of most specific spells like Heretics, or Bainshee, or Vampiir, and even allow for easier implementation of recent poisons. - Unfortunately these updates will come with strong revision of "fighting rules" from GameLiving and GamePlayer code, this also come with a huge update of Summoning Code and GamePet subclasses, which will have some effect on "StandardBrain" to work correctly, the Spell data table will need a lot of updates to take care of all effect change, even if some "synonyms" can be kept for some time, Summoning will need some NPCTemplate update, behavior of pets are supposed to be mostly configured through this table to reduce the need of custom summoning spell handlers...
So to take advantage of these updates a lot of work must be done by shards admins, I expect to use the new "SpellProperties" Table to add spell some custom values instead of using weird fields like "LifeDrainReturn, ResurrectHealth, ResurrectMana etc..." (default should be handled to prevent any errors)
I'm building a new branch for the time I will need to Merge and finish this work :
https://svn.code.sf.net/p/dolserver/cod ... lerRevamp/
I'm starting by getting rid of "class specific" Spell Handlers, sorting Spell by their Type (Damage, CC, Debuff, Buff, Summon etc...) and changing folder tree to match this.
Then I will try to match the file that need changes from the point I stopped, but I can't Merge all this blindly... Even if I've done a lot of work these last months, there are new ideas that spotted since, so I will rather try to work this carefully, starting by revamping the Base "Spell Handler" implementation so every spell handler that subclass it can change the behavior in the way they need.
To make things clear about the purpose of this update :
Latest Tooltip update from DAOC Live showed that most rules of the game are tied to spells !!
Abilities Effects, Realm Abilities Effect, Spells Effects, Styles Effects, Terrains Effects, ML effects, ANY Skills effect is a SPELL !
In fact this make pretty much sense, spells are made able to change so much properties of the game, they are meant to BEND rules around players actions !
We don't need any other "Behavior" handlers than spell handlers, even for weird effects... Actually the "Spell Casting Ability" (for some RA's) is pretty much implemented like this, it's just a special container that will run it's own "CheckCast()" method before using Spell Methods that shouldn't be used like this for casting sequences !! Then it will mostly cap damage calc to work even if no spell lines or Specializations are attached...
New Career System changed some of this, now we can always connect any "used skill" to a given Spec and may find some data about attached spell line or default levels for "skills"...
So when we need to implement more and more special effects, we shouldn't try to customize GameLiving, GameNPC or GamePlayer Classes except if we need more fine-grained event handler, all the code should be in Spell Handlers using massively these events !
I want to get rid of Bersker specific defense malus code, I want to get rid of Body guard Specific checks, I want to get rid of Intercept, Guard, BladeTurn, Advanced Evade, and EVEN Parry and Block code !! Without even talking of the Last and Final Step :
Getting rid of Stealth Code !
All these can AND should be handled by "modifier" and not need specific method in Game Objects, Specialization could give the according abilities, that would act as a passive ability for some effect needing it, with the level computed from spec level or character level...
Yes I think Blocking could be an "hidden" spell effect, there is pretty much no weapon skill computing in there, all that matter are shield spec level / dex property, Attackers amount, Attacker/Defender Level difference, Size of the shield...
I may be wrong but I don't think any parameter from the "close-combat damage calc" are used for Blocking matter ! Maybe previous-Style Bonus/Malus... But guess what, these are more like buffs ! I Think it should only need some "AttackData" with an attack resulting in a hit to try blocking it...
This kind of coding should apply to most of other "hardcoded" Effects ! (Berserk Malus, Hero transform, QuickCast !!)
I'll keep you update