Snare taking no effect

[Cisyouc]

...on mobs. As of pre-augments 0.6.0-DR2. Was this fixed or is this still a bug?

[fathernitwit]

it takes effect... but the code dosent listen correctly...

if you look at npcstats, their movement speeds do actually get decreased (perhapse they are not being decreased enough?)... but as far as I can tell, the code isnt properly using those values or something...

I have looked at the code and cant figure it out... all the code factors in the speeds, but it dosent seem to do much anyways.

[Cutter]

I tested this yesterday..

mob attacked with out snare.. mob runs.. after me of course
mob attacked with snare.. or darkness lines
same speed..

does the code say to change run speed and walk speed?

make the run speed and walk speed to 1 until a timer goes off .. i dont know. i dont know much about coding.. but seems like thats the answer..

i dont guess fear will ever get fixed wil it?

[cofruben]

I'm going to add the code tonight...as I seen,it is not where it should be.

[Cisyouc]

I'm going to add the code tonight...as I seen,it is not where it should be.Still not in :D

[garim12]

I looked at this today and found two problems with the code. Here's what I did on my server. I hope it makes sense to someone other than me, heh.


1) Snare and root are supposed to stack. This was a change that was made to EQLive way back in the Kunark-is-still-new days.

in spell_effects.cpp (Zone project), look for this:

case SE_Root:
{
#ifdef SPELL_EFFECT_SPAM
snprintf(effect_desc, _EDLEN, "Root: %+i", effect_value);
#endif
//BuffFadeByEffect(SE_MovementSpeed);
rooted = true;
break;
}


Notice that I simply commented out the line that was forcing all movement buffs to fade. This includes snare as well as Sow, Wolf Form, etc. None of those fade when you get rooted on EQLive.


2) Snare wasn't making the mobs run slow enough. Ok, this problem took a bit to figure out exactly where the math was wrong, and I changed several lines of code (including other spell types) under the assumption that they were wrong as well. I haven't noticed anything odd due to this assumption yet, but just be aware that I may have changed more than I should have. My changes, however, will not affect buffs. All of these formulas were doing the correct calculations for positive value changes; the sign was just in the wrong place for debuffs.

The change for this was also in the same file as above, spell_effects.cpp (Zone project).

Look for the following function: CalcSpellEffectValue_formula
It should be around line #1886

The problem I found was in the switch statement that does the calculations on the spell formulas, specifically these lines:


case 101: // solar: confirmed 2/6/04
result = ubase + updownsign * (caster_level / 2); break;
case 102: // solar: confirmed 2/6/04
result = ubase + updownsign * caster_level; break;
case 103: // solar: confirmed 2/6/04
result = ubase + updownsign * (caster_level * 2); break;
case 104: // solar: confirmed 2/6/04
result = ubase + updownsign * (caster_level * 3); break;
case 105: // solar: confirmed 2/6/04
result = ubase + updownsign * (caster_level * 4); break;

case 107: // Shutting this thing up, this is wrong
result = ubase + updownsign * (caster_level * 4); break;

case 108:
result = ubase + updownsign * (caster_level / 3); break;
case 109: // solar: confirmed 2/6/04
result = ubase + updownsign * (caster_level / 4); break;


The formula for snare is type 102. I'll go over what's wrong with this one in particular. Like I said, I modified all of these cases (101 - 109) in the same way.

result = ubase + updownsign * caster_level; break;

ubase is a variable holding the unsigned value of the base effect. In the case of Ensnare, the base effect value would be -40 (decrease by 40%), so ubase will be 40.

updownsign will be -1 since the effect value is negative (because it's a debuff).

caster_level will be my test ranger, who is level 64.


The result in this case is
result = 40 + (-1 * 64) = -24

This is a 24% reduction in movement speed. This is why griffawns that have a base run speed of 1.25 were being slowed down to 0.95.

So I changed the formula to this:
result = updownsign * (ubase + caster_level);

What this now does is modify the base before applying the sign to make it negative. In this case, we would have:

result = -1 * (40 + 64) = -104

This result is capped by the spell's maximum movement reduction of -56, or 56%. The same griffawn now is correctly slowed down from 1.25 movement rate to 0.55.

----
Next, I wanted to verify the math with the regular Snare spell, which decreases movement rate from 41% (L1) to 55% (L15). For Snare, the base effect is -40.

Before at level 1:
result = 40 + (-1 * 1) = 39, or a 39% increase in speed (theoretically; it will get fixed later on in that function by multiplying by -1, so it will be a 39% decrease).

After:
result = -1 * (40 + 1) = -41, 41% decrease (correct).


Before at level 15:
result = 40 + (-1 * 15) = 25, or 25% increase in speed (also fixed as above)

After:
result = -1 * (40 + 15) = -55, or 55% decrease (correct).




Like I said, I'm not sure how well this applies to the other spell types. I just applied the change to all of the similar ones and am testing it. But I can already see that snare is working as well as it should.


The new code to replace the above section:

case 101: // solar: confirmed 2/6/04
result = updownsign * (ubase + (caster_level / 2)); break;
case 102: // solar: confirmed 2/6/04
result = updownsign * (ubase + caster_level); break;
case 103: // solar: confirmed 2/6/04
result = updownsign * (ubase + (caster_level * 2)); break;
case 104: // solar: confirmed 2/6/04
result = updownsign * (ubase + (caster_level * 3)); break;
case 105: // solar: confirmed 2/6/04
result = updownsign * (ubase + (caster_level * 4)); break;

case 107: // Shutting this thing up, this is wrong
result = updownsign * (ubase + (caster_level * 4)); break;

case 108:
result = updownsign * (ubase + (caster_level / 3)); break;
case 109: // solar: confirmed 2/6/04
result = updownsign * (ubase + (caster_level / 4)); break;

[hoppy02]

is there an easy way to do this without going into code, I dont know my way around that much.

[fathernitwit]

well,

once I get time/a chance to test it more, I will put this into eqemu. Until then, there is not an easier way.

If anybody wants to expediate the process, they can find me more examples of spells which might have updownsign set to -1

[RangerDown]

Movement speed debuffs?

* Darkness - Clinging Darkness, Engulfing Darkness, Cascading Darkness
* Torpor -- this is a short-term beneficial heal over time -- you'll only see player shamans casting it -- but it has the penalty of snaring the group member while it's in effect.

Debuffs in general:

- Malaise, Malaisement, Tashan, Tashani -- magic resist debuffs

- Torgor's Insects, Drowsy, Walking Sleep -- Attack speed debuffs

- SkunkSpray -- charisma debuff :P

- Weaken -- STR debuff (who woulda thought!)

Hope that helps :D