Bind System Oddity - Interrupts

[BlackSpectre]

As some of you may know, when I wrote my Advanced Bind Guide back in 2007, I analyzed the game's parsing of bind strings, and power activation sequences. To my surprise at least one thing is a little different now.

 

It used to be that if a click power was placed first (far left) in a bind string, that no other powers than the click power would activate. Now it's reversed! No other powers in a bind string will activate if the click power is the last command in the bind string (far right). More importantly, toggle_on powers will now interrupt a click power, and a click power will interrupt a toggle_on power. All toggle_on powers will activate, and once that's done the click power at the beginning of the bind string will activate.  

 

/bind K "powexec_name CLICK POWER$$powexec_toggle_on TOGGLE A$$powexec_toggle_on TOGGLE B$$powexec_toggle_on TOGGLE C"

 

In the above bind string, Toggle C will activate first. Toggle B will activate on the second key press, and Toggle A will activate on the third key press. Then on the fourth key press the Click Power will activate.

 

If this is an actual change and not just a bug, it's a good one. It treats all powers executed by powexec commands the same, as far as interrupting goes. 

 

Can anyone try this in their game to see if what I saw is true?

 

Does anyone know if this change was intentional or an unintended consequence of some other code? In other words, is this change here to stay?

Edited October 13 by BlackSpectre

[Digirium]

Well, that has always been my understanding of how a series of $$ separated commands work. It might be toggles or attacks but only the last actionable command in the series is executed. A series of TargetCustomNext commands also works the same way -- if your example were a series of these commands and only B was in view, B would be targeted. If C came in to view, it would be targeted. If neither B or C were in view, then A would be targeted.

 

What might lend you credence or acceptance, however, is if attacks are different.

 

If the series were attacks, only the last attack that was not on cool down would be executed. If, now, C is on cool down and is queued to be executed when the cool down finishes instead of attack B (which is not on cool down and available) being executed then something has changed between live and now.

 

I never used the attack trick in live (I preferred to know what attack I was using) but knew it was available.

 

To be very clear, I have never had the understanding that the "first or far left" command would execute and no others on the right.

 

I played 2004-2012 and 2019+.

 

 

 

Edited October 13 by Digirium

[Maelwys]

I may be misremembering; but my understanding of bind ordering was much the same - whenever two or more commands are submitted by the user to the game engine it's not a case of "left to right, only one valid command gets read and processed" but "left to right, all valid commands get read and processed". However since the server can only action one power activation command per tick; the last valid power activation to get processed (the rightmost one in the bind line) is the command that actually takes effect.

I still have a few keybind files on my current PC that are timestamped 23rd April 2006 and contain multiple power activations on the same line (in order to toggle the likes of Sprint and Fly and Hover on + off upon the same joypad button being pressed) and I distinctly remember there being cases where my toon often got mezzed enough to drop all their toggles simultaneously... and in those cases the *rightmost* power activation command in the bind was always the toggle that switched on first (and that's the main reason these files were named what they are instead of having them the other way around!)

e.g.
[hover.txt]
joy6 "powexec_name hover$$powexec_name fly$$bind_load_file c:\Games\coh\fly\fly.txt"
[fly.txt]
joy6 "powexec_name fly$$powexec_name hover$$bind_load_file c:\Games\coh\fly\hover.txt"
 

Edited October 13 by Maelwys

[BlackSpectre]

19 hours ago, Digirium said:

Well, that has always been my understanding of how a series of $$ separated commands work. It might be toggles or attacks but only the last actionable command in the series is executed. 

That has always been true for toggle powers. Click powers worked differently, especially if there were mixed click and toggle powers in the command string. But now, they appear to work the same when mixed. I do need to do more testing, though, to make sure what I've seen is not an anomaly. A click power with a very long activation/cast time, for example, might account for the ability of a toggle power to interrupt it, but... 

 

19 hours ago, Digirium said:

If the series were attacks, only the last attack that was not on cool down would be executed. If, now, C is on cool down and is queued to be executed when the cool down finishes instead of attack B (which is not on cool down and available) being executed then something has changed between live and now.

A string of click power commands will only activate the last (far right) click power, and nothing else, whether it's on cool down and queued or not. The first click activates the last power, the next click queues it while it's in cool down, and subsequent clicks simply refreshes the queue for the last power again. 

 

Toggle powers work a little differently. The last toggle power in the string activates first, but when the bound key is pressed again, the activated power is turned off, and the second to last toggle power is activated. And then it just cycles back and forth, on and off.

 

That said, what toggle power activates in the command string really depends on which power(s) in the string are in the ON state.  Turning off a toggle power takes the game almost no time to accomplish and if multiple toggle powers are ON, then all the toggle powers will be turned off, and the first toggle power in the OFF state (if any) from right to left will be toggled ON.

 

19 hours ago, Digirium said:

To be very clear, I have never had the understanding that the "first or far left" command would execute and no others on the right.

OK, thank you. In re-reading the click power section in my guide for a second time, I think I just got confused when I re-read it the first time. In my guide I often refer to the command on the far right as the "first" command because I am referring to its apparent activation (ON state) sequence, not its attempted execution sequence. If I ever rewrite the guide, I'll change that and always refer to the command on the far left as the "first" command in a string. Less confusing I think, especially if you're reading it quickly.