AUTORUN and UP in bind strings conflict

[Shenanigunner]

When AUTORUN 1 and +UP are combined in a bind string, the latter is interpreted as ++UP and a flying alt continues to rise. (And a running alt will continue to jump.)

 

I have done extensive testing of command ordering and combination, and it comes down to this pair, in any order or combination. Any attempt to have an alt "jump" and then start flying results in a continual rise from a latched UP command.

 

I hope a Dev has time to look at this and see if it's a simple parsing error that can be corrected. Thanks!

 

My example strings:

BUTTON4 "emote flypose1$$autorun 1$$powexectoggleon Fly$$+up"
BUTTON5 "autorun 0$$up 0$$powexectoggleoff Fly"

Clicking the mouse button 4 makes the alt jump into the air and then begin flying forward, a very useful travel-start. (It does require a second click to set the pose, but that has nothing to do with the problem—I've tested.) Button 5 cancels all motion and can drop the alt at a pinpoint location, also useful. However, the first button creates a "continual rise" problem that requires a very specific "UP" command, alone, to cancel without disturbing the auto-fly setup.

[Shenanigunner]

And an addendum: I don't know if it's just my client/setup or not, but +UP is bugged in several ways now.

 

I have used the following for years, both on Live and since first days on Homeecoming:

/bind MouseChord "+up"

... and it's terribly useful for one-handed zone travel, jumping or rising over obstacles.

 

Now, every time I zone (including mission entry./exit) my right mouse button, bound as default to CAMLOOK, triggers the bind and I jump until I at least click the left button.

So something has gone sideways in parsing +UP. A look-see would be appreciated...

[Shenanigunner]

And just another update, ALL of my alts now exhibit the "up on one mouse key" fault every time I zone. Something has changed/gone corkscrew with the parsing of up/+up in binds, and I think the fault was somewhat after the first I27 rollout.

[Jacke]

@Shenanigunner try this.  I think it will fix things.

 

BUTTON4 "emote flypose1$$autorun 1$$powexectoggleon Fly$$up 1"

You'll need to cancel the "up 1" during flight with another vertical motion.  A quick press-and-release of default X ("+down") or SPACE ("+up") works.

 

The short 2 warnings for binds and macros:

• Only use the prefix "+" on a single power, like in "+down" or "+up", not compounded with "$$" at all.
• Be careful using the prefix "++" on powers in compound commands put together with "$$" (no spaces either side of "$$" or some commands might be misinterpreted).

 

The long and winding analysis in the spoiler:

 

I was playing around with my toon who didn't have Fly but does have the power Jetpack.  Here's the movement portion of my bind file.
 

SHIFT+SPACE     "++up"
CTRL+SPACE      "++up$$++autorun"
BUTTON5         "+forward"
BUTTON4         "+backward"
W               "+left"
E               "+forward"
R               "+right"
D               "+backward"
SHIFT+E         "++autorun"
Q               "follow"
A               "targetenemynear$$follow"
S               "powexectray 9 3"
F               "powexectray 10 3"
Z               "powexec_abort"
X               "+down"
C               "+down"
H               "powexectray 8 6"
J               "powexectray 9 6"
K               "powexectray 10 6"

 

I use H, J, and K to hold travel powers and other special powers in Tray 6 Slots 8, 9, and 10, in my standard tray setup in the lower right of my screen.



I fiddled with my existing binds SHIFT+SPACE and CTRL+SPACE along with Jetpack via the J key.  Sometimes, after apparently turning off all powers, I couldn't jump.  I think I was in the inverse of your problem, a steady down motion (like a single activation of "++down").  I found I could fix it by turning on Jetpack, then off, which cleared the state for my toon, who could then jump again.

Then I tried your BUTTON4 bind, in a macro B4 I put into Tray 1 Slot 1 to test.

/macro B4 "emote flypose1$$autorun 1$$powexectoggleon Jetpack$$+up"

Got the same issue as before, couldn't jump, fixed with turning Jetpack back on.

Then after reading some more on the movement keys and the use of prefixing + and ++, as well as remembering stuff from my deep dark dank past in City, I recalled that using + and ++ can be fraught with peril, these sorts of issues.  At times they can work.  Normally a compound command with commands separated by "$$" can only have the right-most command that can be activated, be activated.  But the movement powers are a bit special and can have more than one or added to a single power execution.

Prefixes + (press down key to activate, release key to deactivate) and ++ (toggle on/off with a single key press and release) are best used when only one command is used, as in my binds above for BUTTON5, BUTTON4, WERD, SHIFT+E (my autorun toggle, usually cancelled with a press of E or D), and SHIFT+SPACE.  ++ can sometimes work in a compound commnad, as I do for CTRL+SPACE, "++up$$++autorun".  But it can also have issues.  And I rarely use it.

The use of "+up" in the end of a compound command is really tricky.  It's not a bind of BUTTON4 to only "+up", so exactly what happens when the BUTTON4 is released?  That is too implementation dependent to be reliable.

So I tried "up 1" in its place.

/macro B4 "emote flypose1$$autorun 1$$powexectoggleon Jetpack$$up 1"

That one was very well behaved.  With a quick press-and-release of default X ("+down") or SPACE ("+up") to turn off "up", this should work for you, @Shenanigunner.

Edited December 4, 2020 by Jacke

[Shenanigunner]

14 hours ago, Jacke said:

@Shenanigunner try this.  I think it will fix things.

 

BUTTON4 "emote flypose1$$autorun 1$$powexectoggleon Fly$$up 1"

You'll need to cancel the "up 1" during flight with another vertical motion.  A quick press-and-release of default X ("+down") or SPACE ("+up") works.

 

Thanks for all, but changing +up to up 1 just perpetuates the basic problem. What I WANT from the bind is for the alt to jump up before starting forward-fly. it should work. With one flaw, it DOES work: the alt jumps I(up and away from obstacles) but the +up is then being interpreted as up 1, a latched "go up" command instead of a "jump once" command.

 

I maintain that this is a new bug because my longstanding bind of +up on MouseChord has always worked perfectly (rise or jump whenever I chord)... and now, whenever I zone, pressing either mouse button triggers a jump until I press both. New (flawed) behavior, and I suspect at the root of it is why the simple "jump to fly" bind isn't working right.

 

As it is, I already have to hit the "Fly travel" button and then do a quick MouseChord to stop the perpetual rise. Alternate means of doing all that don't really solve the issue.

 

Edited December 4, 2020 by Shenanigunner

[Jacke]

3 hours ago, Shenanigunner said:

Thanks for all, but changing +up to up 1 just perpetuates the basic problem. What I WANT from the bind is for the alt to jump up before starting forward-fly. it should work.

 

@Shenanigunner, you can curse the darkness.  Or you can find a way to light a candle.

 

I still looked for a solution for you and found out a bit more what is happening.  First the solution I found.

BUTTON4 "emote flypose1$$autorun 1$$powexectoggleon Fly$$++up"

Press and release BUTTON4 the first time to jump up and fly.  Press and release BUTTON4 a second time to stop the rise.  A third press-and-release starts rising again, a fourth stops rising, etc.

 

More details in the spoiler.

 

I think when it goes wrong, it's an extension of the current principle that in a compound command, only the right-most power-executing command that can be executed, will be executed.

I couldn't find a way to put a delay into a compound command; there may not be one.  So I decided to try a bit of side-to-side to hopefully cause a bit of delay.

/macro BL4 "emote flypose1$$autorun 1$$powexectoggleon Jetpack$$up 1$$left 1$$right 1$$right 0$$up 0"

For movement commands with 1 and 0, it appears that a first 1 enable is executed, a second 1 enable is executed but abnormal locks on, no more 1 enables are handled, and any 0 disables are executed.

'Cause when I tested this on the Pocket D slopes, I got in a bit of forwards+leftwards skiing after turning off the Jetpack. 🙂

A tap of a key bound to "+forward" or "+backward" cancelled the Autorun, a tap of a key bound to "+left" cancelled the "left 1".  The "left 1" in that compound command is abnormal in that it doesn't turn off in respond to Right commands, only "left 0".



Another test macro cinched this analysis.

/macro BLZ4 "emote flypose1$$autorun 1$$powexectoggleon Jetpack$$up 1$$left 1$$right 1$$left 0$$right 0$$up 0"

Here there was no lock-on of leftward motion, because I'd turned that off in the command.

Using single + on anything except a simple command in a bind is going to be implementation dependent and shouldn't be relied upon, because + was only intended for simple commands.  Even in the macro '/macro "+UP" "+up" ', + doesn't work as it does in a bind and only does the "up 1" and again won't respond to "down" commands, only "up 0" or a press-and-release of SPACE, a key bound with "+up".

 

BUTTON4 "emote flypose1$$autorun 1$$powexectoggleon Fly$$+up"

Here that "+up" in the button being pressed gives effectively "up 1".  But in the button release, it doesn't act as "up 0", because a compound command breaks the operation of +, because + was only intended for simple commands.  As in my test macros, that "up 1" is abnormal and leaves things in a state where "down" doesn't turn it off, only "up 0".  Which I also tested and confirmed.

This ain't my first rodeo.  I've been bashing binds and macros in City a long time.  There are limitations to the current system.  Sometimes you can get beyond them, but if you're depending on an implementation-dependent race condition for something to work, then you're on insecure ground that can give way.  And that's also backed by my experience in other games and my even longer experience as a sysadmin.

 

 

Edited December 4, 2020 by Jacke

[Shenanigunner]

2 hours ago, Jacke said:

 

@Shenanigunner, you can curse the darkness.  Or you can find a way to light a candle.

 

I still looked for a solution for you and found out a bit more what is happening.  First the solution I found.

BUTTON4 "emote flypose1$$autorun 1$$powexectoggleon Fly$$++up"

Press and release BUTTON4 the first time to jump up and fly.  Press and release BUTTON4 a second time to stop the rise.  A third press-and-release starts rising again, a fourth stops rising, etc.

 

 

I really, thoroughly appreciate the help but —

 

1. I know more about binds and macros than probably 99% of the community.
2. I HAVE a solution that goes "up" on one key and stops rising on another. I don't need another.
3. I want a solution that works the way the commands USUALLY work in most combinations: to start with one (1) jump up and then do no more "up" movement except as I otherwise command, without having to cancel a latched "up" state. While we're at it, the same dev fix will probably cure the NEW problem of each mouse key producing "up" when only the combination is supposed to... a condition that did not exist until the last week or two, sometime post I27.

 

Your very detailed answer simply gives another variation of what I am already accomplishing and don't want to. I may be cursing the darkness of a bad parsing problem, but I already have a candle. 🙂

Edited December 5, 2020 by Shenanigunner