Incorrect DataManager.GetSpellData Info

Is it possible to have DataManager looked at? I've noticed over the past few weeks that most of the information DataManager reports back is incorrect and it has become a roadblock in my CR development multiple times.

If anyone wants to check for themselves, all you need to do is type this into the Console:

Log(DataManager.GetSpellData("Spell Name").BaseCastTime);

Just change the "Spell Name" to the spell name (obviously) and the last bit (BaseCastTime) to whatever data you're trying to pull from DataManager (Cost, Range, etc.).

A couple examples:

Code:

[B][U]Ruin[/U][/B]
BaseCastTime 	 - 1
AdjustedCastTime - 0.963
BaseCooldown 	 - 3
AdjustedCooldown - 2.889
Cost 		 - 0
Range 		 - 25

The only correct information is the Range. Everything else is wrong.

Code:

[B][U]Miasma[/U][/B]
BaseCastTime 	 - 2.5
AdjustedCastTime - 2.407
BaseCooldown 	 - 2.5
AdjustedCooldown - 2.407
Cost 		 - 5
Range 		 - 25

Now most of this is actually correct. The only incorrect information is the Cost.

I've been able to work around some of the inaccuracies up until this point, but the fact that CastTime is incorrect means that even Kupo's DoubleCastProtection (which depends on AdjustedCastTime) isn't functioning properly anymore.

 

Thanks for the response. If I have to go the dictionary route then is there any performance difference between DataManager and Actionmanager (is one preferable to use over the other)?

Code:

Actionmanager.CurrentActions.TryGetValue(spellName, out spellData);

vs

Code:

DataManager.SpellsWithJobsCache.TryGetValue(spellName, out spellData);

 

Although (I assume) it doesn't have to pull the entire dictionary for every spell we call, I ran a little test and:

DataManager.SpellsWithJobsCache took 700ms to pull
Actionmanager.CurrentActions took 20ms to pull

(due to the fact SpellsWithJobsCache is like 3000 spells and CurrentActions is like 30 lol)

So just in case, in the name of performance, I'll try to stick with CurrentActions when possible.

Thanks again.

 

If you're enumerating over the dictionary's values then that'll be slower since there are more, but if you're just getting a single value using the key it's an O(1) operation for both, as fast as it gets, irregardless of how many entries there is in the dictionary.