This does not work correctly. If rampage is off cooldown and my innate resource is below the 450 it will spam rampage. It won't spam any builders until my innate resource is 0. if (Me.InnateResource > 45 && IsSpellProcReady("Rampage") && await Cast("Rampage")) return true; Thanks
Ok, please don't post two threads for the same thing. SpellInformation.IsSpellReady catches most procs, however there's also another field (which I think is related to procs). Possibly IsOnCooldown or IsOnCooldown2. See if any of those are related to Rampage. Unfortunately, I can't test, as I'm in the process of moving to my new house. I should be back full-time Monday. (Sunday if we hurry )
IsonCooldown doesn't seem to work. It doesn't seem to be catching its proc correctly. It will spam the ability even though we don't have enough "Kinetic Energy" to use it. I am using the correct synax since I know it works for other classes. Thanks
Alright, so Rampage is a "special snowflake" case. I just did some further digging into it. In the data tables (.tbl files inside the archives), there is an "innate resource" requirement set for the ability. You can see these values here: https://www.dropbox.com/s/4u8uouug4...ha)_DB-139.795.5_2015-01-12_14-40-13.png?dl=0 casterInnateRequirement0: 6 (InnateResource, or specifically to the client, "Resource1") casterInnateRequirementValue0: 250 (250 Kinetic Energy) casterInnateRequirementEval0: 2 (greater than or equal) These are "alive and well" in the data files. However, when I read this information from the client itself, these values are all "zero". (You can see how the game initializes this info from the following decompiler output: https://gist.github.com/6e00f4b981b29fea62d9 . These are the same structures the bot uses to read the information) I'm not entirely sure why this is happening, it is quite possible that there's a bugged cache going on somewhere related to reading the spell cache info. And finally, Rampage is a "charges" spell. So once the initial requirement is met (250 KE), it is castable, and after the first cast, there are n charges left for x seconds. This is handled correctly (I think!). There is no "proc", so that route will go nowhere. I'll do some more digging to figure out if there's just a bug in reading the spell cache info, or if the client does something totally different. (I've also spent time today wrapping "proper" prerequisites for things, as well as better "CanCast" logic.)
