What's new
  • Visit Rebornbuddy
  • Visit Panda Profiles
  • Visit LLamamMagic
  • Visit Resources
  • Visit Downloads
  • Visit Portal
RebornBuddy Forums

Register a free account today to become a member! Once signed in, you'll be able to participate on this site by adding your own topics and posts, as well as connect with other members through your own private inbox!

Incorrect DataManager.GetSpellData Info

Endus

Community Developer
Joined
Jul 9, 2012
Messages
458
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.
 
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.


Nope. Data is all correct. There are 3 or 4 spells called "Ruin". Either use DataManager.SpellsWithJobsCache or use Id's.
 
Nope. Data is all correct. There are 3 or 4 spells called "Ruin". Either use DataManager.SpellsWithJobsCache or use Id's.

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);
 
Last edited:
They are both dictionaries, no performance difference between the two. CurrentActions just has filtering done to make sure it only contains current skills.
 
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. :cool:
 
Last edited:
Run it multiple times. First time is probably the JIT compiling everything.
 
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.
 
Back
Top