Spell Haste and Client cap?

[jsr]

Hi all,

I've been experimenting with altering spell haste so that it works more like as melee haste. Standard emu code caps it at 50%, which matches a cap on live (from what I can see in old EQ posts). The cap is necessary, as the way it currently works all spell become instant cast once 100% spell haste is reached.

Changing the way it works required an updated calculation in Client::GetActSpellCasttime, and a data conversion for spell focus values so that cast times remain the same with existing focus effects. I've gotten both the calculation and data conversion completed without any real issues. However there is an issue with the client spell description still displaying as if it is capped at 50%. In addition, if a spell's casting time is reduced by more than 50% the spell cast timer starts no lower than 50% regardless of how high spell haste is (the timer will finish early instead).

The result is that with the new calculations spell cast times work as intended, but it's not pretty for the user once spell haste goes over 100%.

My assumption is now that the client is doing its own calculations and capping both the description and timer-start-point at 50%. However I'm keen to rule out any possibility that I've missed an update from the server to the client which is not calculated in the Client::GetActSpellCasttime function. If anyone knows more about this I'd be very grateful if you could share you findings.

-Jsr

[Tabasco]

I do my cast time stat bonuses in spells.cpp, Mob::DoCastSpell by hitting cast_time with the final haste percentage. For my purposes this is innate and would stack with existing hastes.
At that point you can just set a floor for cast time and the client doesn't seem to be bothered at all.

[jsr]

Sounds like a lead, I'll check it out... cheers!

[jsr]

Hmm.. I'm actually more confused by this.

Mob::DoCastSpell calls the function I modified to get the 'hasted' spell cast time. So this section of code is using the modified cast time value. But then it passes the original cast time to a struct which I assume is eventually going to the client... There is also a comment sayin gthe client does it's own cast time reduction calculation. But the client must be getting the output of GetActSpellCasttime at some point, otherwise I'd have cosmetic issues with ALL haste values rather than just those which reduce casting time by more than 50%.

When you say the client isn't bothered at all, have you been able to reduce the cast time of a spell by more than 50% without any cosmetic issues on the client? (i.e. Spell description shows accurate casting time, and timer starts at relevant %). It's really easy to test with a shaman and quick buff aa, as this provides 100% haste right off the bat (or a 50% reduction), so any focus on top of this will reduce casting time by more than 50% without the cap.

[Tabasco]

I guess I didn't read the problem thoroughly enough. When you you said it 'wasn't pretty', I was thinking that functionality broke. The cast bar on the client usually disappears a little early on mine as well, but you really only even notice it when you're looking for it. The client isn't bothered at all as in the spell casts with the appropriate timing and effects. Unless it's something very noticeable or significant I generally ignore little client quirks.

[jsr]

This is still helpful as it virtually confirms a client cap but not calculation based on the spell file's base cast time value.. If it was getting the haste value from the spell file, I'd be having client issues at 50%+ haste not 100%+. So there should be a way to trick the client into using the right value (at least for the description).

Thanks again.

[jsr]

Have this working well enough, but still hoping to find a way to trick the client so that it shows the correct casting times.

To do this I need to be able to call a spell haste value when a spell is cast. At the moment, GetActSpellCastTime performs all of the haste calculations and returns a a modified cast time. I want to split these out into two functions, one to return spell haste as a value, and then the original function will call that and return the modified cast time. Seems simple enough..

Apparently not! After re-writing the two functions the code compiles without any issues, but when it comes to build I get these link errors.

3>pets.obj : error LNK2001: unresolved external symbol "public: virtual int __thiscall Mob::GetCastReducer(unsigned short,int)" (?GetCastReducer@Mob@@UAEHGH@Z)
3>PlayerCorpse.obj : error LNK2001: unresolved external symbol "public: virtual int __thiscall Mob::GetCastReducer(unsigned short,int)" (?GetCastReducer@Mob@@UAEHGH@Z)
3>beacon.obj : error LNK2001: unresolved external symbol "public: virtual int __thiscall Mob::GetCastReducer(unsigned short,int)" (?GetCastReducer@Mob@@UAEHGH@Z)
3>horse.obj : error LNK2001: unresolved external symbol "public: virtual int __thiscall Mob::GetCastReducer(unsigned short,int)" (?GetCastReducer@Mob@@UAEHGH@Z)
3>mob.obj : error LNK2001: unresolved external symbol "public: virtual int __thiscall Mob::GetCastReducer(unsigned short,int)" (?GetCastReducer@Mob@@UAEHGH@Z)
3>npc.obj : error LNK2001: unresolved external symbol "public: virtual int __thiscall Mob::GetCastReducer(unsigned short,int)" (?GetCastReducer@Mob@@UAEHGH@Z)

I have no issues with a build using the original code, so clearly I've missed something obvious to a native C++ dev. Hoping someone might be able to outline the high level steps to complete when adding a new function?

Cheers,
-Jsr

[lerxst2112]

Step 1: Add function definition to class in header file
Step 2: Add function implementation in that classes cpp file

Make sure that the signature of the function matches in both places or you'll have issues.

Without actually seeing a diff it's hard to know where you might have gone wrong.

[jsr]

That's pretty much what I've done. I'll put a diff together..

and thanks

[jsr]

All fixed, thanks!