* [Skills] Exponential Decay Skill Up Formula
Added an exponential decay skill up formula option.
The current, linear, formula results in negative chances to skill up, which
have been mitigated via a multiplier and minimum of 1%
* [Skills]Configurable Exponential Decay Formala for Skill Up
What this fixes:
The existing formula for determining whether or not to skill up could result
in negative chances, and made an assumption around the number 252.
This would ultimately result in an override that would set the chance to 1.
My fix:
I created 2 new rules:
Character:SkillUpMaximumChancePercentage
Character:SkillUpMinimumChancePercentage
I changed the forumla to:
chance = ((max - min + skill_modification) * (.99^skill)) + min
This results in an exponential decay that starts at skill-modified maximum
and approaches minimum.
I decided that max-min+skill_modification should never be less than min
I also decided to continue to apply the Character:SkillUpModifier rule
post-calculation. I do not really think this is necessary anymore, given
this new formula, but we can discuss removing it.
I chose 25 and 2 as default maximum and minimum based on feel.
Related method signature fix:
Client::mod_increase_skill_chance was changed to return a double and
accept a double as an input for chance. This matches the actual data types
provided while calling the method and eliminates some type coersion and
resultant truncation. Right now, this method doesn't do anything, but in the
future we could implement skill-specific training dummies that accelerate
skill ups. I deduce that this is the purpose of this method call.
* [Skills]Configurable Exponential Decay Formula for Skill Up
What this fixes:
The existing formula for determining whether or not to skill up could result
in negative chances, and made an assumption around the number 252.
This would ultimately result in an override that would set the chance to 1.
My fix:
I created 2 new rules:
Character:SkillUpMaximumChancePercentage
Character:SkillUpMinimumChancePercentage
I changed the forumla to:
chance = ((max - min + skill_modification) * (.99^skill)) + min
This results in an exponential decay that starts at skill-modified maximum
and approaches minimum.
I decided that max-min+skill_modification should never be less than min
I also decided to continue to apply the Character:SkillUpModifier rule
post-calculation. I do not really think this is necessary anymore, given
this new formula, but we can discuss removing it.
I chose 25 and 2 as default maximum and minimum based on feel.
Related method signature fix:
Client::mod_increase_skill_chance was changed to return a double and
accept a double as an input for chance. This matches the actual data types
provided while calling the method and eliminates some type coersion and
resultant truncation. Right now, this method doesn't do anything, but in the
future we could implement skill-specific training dummies that accelerate
skill ups. I deduce that this is the purpose of this method call.
* fixup! [Skills]Configurable Exponential Decay Formula for Skill Up
* fixup! [Skills]Configurable Exponential Decay Formula for Skill Up
Removed a conditional that was rendered obsolete by moving the addition of a
mob to the auto haters list to fire after an IsValidXTarget check. This
made an entity_list call unnecessary. [zone/client.cpp]
Removed said unnecessary entity_list call. [zone/client.cpp]
Removed a superfluous call to ProcessXTargetAutoHaters [zone/attack.cpp]
* [XTarget] Disallow Corpses in XTarget Auto Slots
Why:
There exists an odd state where corpses will fill up your XTarget window.
This is reproducable using a combination of a pet to kill a mob
and timely feign death to wipe the owner's aggro.
What:
Added an IsCorpse check to IsXTarget.
Added a block to mark corpse XTargets as dirty to ProcessXTargetAutoHaters
* fixup! [XTarget] Disallow Corpses in XTarget Auto Slots
* fixup! [XTarget] Disallow Corpses in XTarget Auto Slots
* [XTarget] Disallow Corpses Code Cleanup
Added some safety, performance, and code readability changes per PR request.
Why:
Heal Over Time spells honor the Spells:IgnoreSpellDmgLvlRestriction rule,
shouldn't instant heals honor this rule too?
The fix:
Added a check for Spells:IgnoreSpellDmgLvlRestriction in the GetActSpellHealing
method.
* [Shared Tasks] Cross Zone Remove Fix
Why:
The cross_zone_remove_task quest methods were not removing from
shared_task_members database table and were not clearing shared task
cache. This resulted in a situation where a character could not
request other shared tasks.
What:
Shamelessly copied shared task logic from ClientTaskState::CancelTask
into ClientTaskState::RemoveTaskByTaskID
* What:
Instead of copying code from CancelTask into RemoveTaskByTaskID, it is better
for code maintenance to simply call CancelTask from RemoveTaskByTaskID.
This is cleaner.
Note: I chose to be explicit with the remove_from_db parameter, despite true
being the default. I tend to do this to protect from the default value
changing in the future.
* [Shared Tasks] RemoveTaskByTaskID Cleanup
Removed unused variables.
Distinguished log messages for Shared Tasks from regular Tasks.
Added 1 rule per class that defines tracking distance multiplier for that class
Kept the defaults of 12 for ranger, 10 for druid, and 7 for bard
Created 1 method for determining class tracking distance multiplier
Created 1 method for determining if a class can track, based on multiplier
Updated tracking logic to use these methods to determine whether a tracking
packet should and can be sent or not.
What:
Add toggle for compounding bonuses for lifetap heals.
Why:
When spell damage and heal amount bonuses are scaled to ludicrous
levels, this double dip results in very high heals from
relatively weak lifetaps.
Created new rule: Spells:CompoundLifetapHeals
If true (default):
Apply spell damage bonuses to lifetap damage
Pass that amount through heal bonuses
Heal for this resulting amount
If false:
Apply spell damage bonuses to lifetap damage
Heal for this resulting amount
mmcgarvey