Closed Th3MadHatter closed 7 years ago
Cant be done.
The full answer is here: https://wowlazymacros.com/forums/topic/fyi-attempt-at-a-proc-watching-macro-result-interface-action-blocked/
The short answer is that while you can watch for procs in a mod you cant act on them. This has been the state of the world since WoW 2.0
Ok that's clear, you can't work around procs but if you read the rest of what I wrote, you CAN work on with power monitors to help decide the best next course of action for example
Cast Rockbiter if under 80 Maelstrom to build a resource buffer. Cast Lava Lash when you have more than 80 Maelstrom.
If Maelstrom < 80 /cast Rockbiter Else /cast Lava Lash
Very oversimplified, but that would still work am I right?
No it's the exact same limitation.
Once you determine the value of Maelstrom you can't use that to determine what spell to cast. You can't use an If Then Else construct in a macro for the same reason you can't check for Procs. It's a tainted execution path that is explicitly blocked by Blizzard. You can watch how much Maelstrom you have and put an alert up that you should cast Lava Lash but GSE can't use that to change the button to be Lava Lash instead of Rockbiter. (The alert thing is what WeakAuras etc do.)
Blizzard wants you the player making the decision on how much Maelstrom you have and which spell to cast in that space and has blocked those kinds of actions from mods during combat.
TimothyLuke
On 29 May 2017, at 1:31 am, Th3MadHatter notifications@github.com wrote:
Ok that's clear, you can't work around procs but if you read the rest of what I wrote, you CAN work on with power monitors to help decide the best next course of action for example
Cast Rockbiter if under 80 Maelstrom to build a resource buffer. Cast Lava Lash when you have more than 80 Maelstrom.
If Maelstrom < 80 /cast Rockbiter Else /cast Lava Lash
Very oversimplified, but that would still work am I right?
— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub, or mute the thread.
I got a feature request that I think you'd ( @TimothyLuke or anyone who would want to write this and pull request it) be able to implement pretty easily.
So to obtain perfect rotations a lot of classes have to watch for procs which is hard to manage with an addon, but not impossible, however I'm aiming more at the rotations where people should use skill A if their "power" is below xx points or skill B if it's above xx points. as a quick example let me pull enh shammy's priority from icy veins
Checking this just made me realize how heavy proc based this actually is but It's not as bad as ele shammy so I can still use as an example
Can this be made into a working cast sequence... it might, after a lot of trial and error it could be made into a near perfect sequence that almost always pops every proc and casts the right thing at the right time, but if your haste suddenly changes or you switch targets or another variable because something changes your rotation is broken.
So to take the example
If a new box is added where certain abilities can be specified (or spellID) added with a manual entered value (or predefined if you want to manage it but either way in this case it's < 80 and => 80) which is monitored in the background based on readings from your amount of maelstrom a new command can be made leaving GSE as the virtual machine to interpenetrate the new command and quickly run the line of code. This new box could be named RBorLL and could be added in anyway you would think suits it best, it could pick up RBorLL as a valid spell and run the code after being triggered by a normal /cast or it could be added as a new click command like /click <1> for box 1, really anything you would think is easiest.
This shouldn't be too much of an overhaul, it shouldn't leave a major cpu footprint and should be very light weight, it would however make GSE much more dynamic and much easier to build HP rotations with that don't break every time you gear up.
Note that this could be done for proc based spells too but that would be easier in an "if xx.., else xx.." kind of way but it could still be monitored silently in the background and register a proc pop and add it as a valid or invalid variable for its casting choice.
It's a rough idea I came up with reading through rotations, priorities and messing around with new rotations but maybe you could have a look at it and see if it is something you could do. It does not break the ToS, you still have to click a button manually, it just helps you decide priority.