[Trigger] Arrow Keys - randomly getting stuck in "pressed" position

Shyster · Oct 7, 2016

So I downloaded an arrow key system recently, and I modified it just a bit. I've been refining it more and more but there's one problem - sometimes you'll get a key stuck pushed down until you press it again. I'll show a couple of the triggers here so you can get an idea. Refer to the test map for the remaining directions. All four of the arrow keys are capable of getting stuck. I can't detect a pattern, though pressing them quickly makes it more likely

Also if it's possible to edit the Down key with this system to make them backpedal instead of turning aroud 180 degrees, I will rep you long time. I'm new to the "proper" way of doing arrow keys around here

PressSetup
- Events
- Conditions
- Actions
  - -------- THE DISTANCE THE ORDERED UNIT WILL BE ORDERED, THIS DOESNT REALLY MATTER --------
  - Set C3D_OrderedDistance = 255
  - -------- I SUGGEST TO KEEP "NEXTMOVETIME" AT .25 --------
  - Set C3D_NextMoveTime = 0.20

Up Press
- Events
  - Player - Player 1 (Red) Presses the Up Arrow key
  - Player - Player 2 (Blue) Presses the Up Arrow key
  - Player - Player 3 (Teal) Presses the Up Arrow key
  - Player - Player 4 (Purple) Presses the Up Arrow key
  - Player - Player 5 (Yellow) Presses the Up Arrow key
  - Player - Player 6 (Orange) Presses the Up Arrow key
  - Player - Player 7 (Green) Presses the Up Arrow key
  - Player - Player 8 (Pink) Presses the Up Arrow key
  - Player - Player 9 (Gray) Presses the Up Arrow key
  - Player - Player 10 (Light Blue) Presses the Up Arrow key
  - Player - Player 11 (Dark Green) Presses the Up Arrow key
  - Player - Player 12 (Brown) Presses the Up Arrow key
- Conditions
- Actions
  - Set C3D_UpDown[(Player number of (Triggering player))] = True
  - If (All Conditions are True) then do (Then Actions) else do (Else Actions)
    - If - Conditions
      - C3D_LeftDown[(Player number of (Triggering player))] Equal to True
    - Then - Actions
      - Set C3D_PointDegrees[(Player number of (Triggering player))] = ((Integer((Facing of Heroes_onevariable[(Player number of (Triggering player))]))) + 35)
    - Else - Actions
      - If (All Conditions are True) then do (Then Actions) else do (Else Actions)
        
        If - Conditions
        
        C3D_RightDown[(Player number of (Triggering player))] Equal to True
        
        Then - Actions
        
        Set C3D_PointDegrees[(Player number of (Triggering player))] = ((Integer((Facing of Heroes_onevariable[(Player number of (Triggering player))]))) - 35)
        
        Else - Actions
        
        Set C3D_PointDegrees[(Player number of (Triggering player))] = (Integer((Facing of Heroes_onevariable[(Player number of (Triggering player))])))
  - Set C3D_MovePosition = (Position of Heroes_onevariable[(Player number of (Triggering player))])
  - Set C3D_ActualPosition = (C3D_MovePosition offset by (Real(C3D_OrderedDistance)) towards (Real(C3D_PointDegrees[(Player number of (Triggering player))])) degrees)
  - Unit - Order Heroes_onevariable[(Player number of (Triggering player))] to Move To C3D_ActualPosition
  - Custom script: call RemoveLocation(udg_C3D_MovePosition)
  - Custom script: call RemoveLocation(udg_C3D_ActualPosition)
  - Countdown Timer - Start C3D_CheckTimer[(Player number of (Triggering player))] as a Repeating timer that will expire in C3D_NextMoveTime seconds

Up Release
- Events
  - Player - Player 1 (Red) Releases the Up Arrow key
  - Player - Player 2 (Blue) Releases the Up Arrow key
  - Player - Player 3 (Teal) Releases the Up Arrow key
  - Player - Player 4 (Purple) Releases the Up Arrow key
  - Player - Player 5 (Yellow) Releases the Up Arrow key
  - Player - Player 6 (Orange) Releases the Up Arrow key
  - Player - Player 7 (Green) Releases the Up Arrow key
  - Player - Player 8 (Pink) Releases the Up Arrow key
  - Player - Player 9 (Gray) Releases the Up Arrow key
  - Player - Player 10 (Light Blue) Releases the Up Arrow key
  - Player - Player 11 (Dark Green) Releases the Up Arrow key
  - Player - Player 12 (Brown) Releases the Up Arrow key
- Conditions
- Actions
  - Set C3D_UpDown[(Player number of (Triggering player))] = False
  - If (All Conditions are True) then do (Then Actions) else do (Else Actions)
    - If - Conditions
      - C3D_LeftDown[(Player number of (Triggering player))] Equal to True
    - Then - Actions
      - Set C3D_PointDegrees[(Player number of (Triggering player))] = ((Integer((Facing of Heroes_onevariable[(Player number of (Triggering player))]))) + 30)
      - Set C3D_MovePosition = ((Position of Heroes_onevariable[(Player number of (Triggering player))]) offset by (Real(C3D_OrderedDistance)) towards (Real(C3D_PointDegrees[(Player number of (Triggering player))])) degrees)
      - Unit - Order Heroes_onevariable[(Player number of (Triggering player))] to Move To C3D_MovePosition
    - Else - Actions
      - If (All Conditions are True) then do (Then Actions) else do (Else Actions)
        
        If - Conditions
        
        C3D_RightDown[(Player number of (Triggering player))] Equal to True
        
        Then - Actions
        
        Set C3D_PointDegrees[(Player number of (Triggering player))] = ((Integer((Facing of Heroes_onevariable[(Player number of (Triggering player))]))) - 30)
        
        Set C3D_MovePosition = ((Position of Heroes_onevariable[(Player number of (Triggering player))]) offset by (Real(C3D_OrderedDistance)) towards (Real(C3D_PointDegrees[(Player number of (Triggering player))])) degrees)
        
        Unit - Order Heroes_onevariable[(Player number of (Triggering player))] to Move To C3D_MovePosition
        
        Else - Actions
  - If (All Conditions are True) then do (Then Actions) else do (Else Actions)
    - If - Conditions
      - C3D_DownDown[(Player number of (Triggering player))] Equal to False
      - C3D_LeftDown[(Player number of (Triggering player))] Equal to False
      - C3D_RightDown[(Player number of (Triggering player))] Equal to False
      - C3D_UpDown[(Player number of (Triggering player))] Equal to False
    - Then - Actions
      - Unit - Order Heroes_onevariable[(Player number of (Triggering player))] to Stop
      - Countdown Timer - Pause C3D_CheckTimer[(Player number of (Triggering player))]
      - Set C3D_MovePosition = (Position of Heroes_onevariable[(Player number of (Triggering player))])
    - Else - Actions
  - Custom script: call RemoveLocation(udg_C3D_MovePosition)

Red Timer
- Events
  - Time - C3D_CheckTimer[1] expires
- Conditions
- Actions
  - If (All Conditions are True) then do (Then Actions) else do (Else Actions)
    - If - Conditions
      - C3D_UpDown[(Player number of (Triggering player))] Equal to False
      - C3D_LeftDown[(Player number of (Triggering player))] Equal to True
      - C3D_RightDown[(Player number of (Triggering player))] Equal to False
      - C3D_DownDown[(Player number of (Triggering player))] Equal to False
    - Then - Actions
      - Set C3D_PointDegrees[(Player number of (Triggering player))] = (C3D_PointDegrees[(Player number of (Triggering player))] + 30)
    - Else - Actions
      - If (All Conditions are True) then do (Then Actions) else do (Else Actions)
        
        If - Conditions
        
        C3D_UpDown[(Player number of (Triggering player))] Equal to False
        
        C3D_LeftDown[(Player number of (Triggering player))] Equal to False
        
        C3D_RightDown[(Player number of (Triggering player))] Equal to True
        
        C3D_DownDown[(Player number of (Triggering player))] Equal to False
        
        Then - Actions
        
        Set C3D_PointDegrees[(Player number of (Triggering player))] = (C3D_PointDegrees[(Player number of (Triggering player))] - 30)
        
        Else - Actions
        
        If (All Conditions are True) then do (Then Actions) else do (Else Actions)
        
        If - Conditions
        
        C3D_UpDown[(Player number of (Triggering player))] Equal to True
        
        C3D_LeftDown[(Player number of (Triggering player))] Equal to True
        
        C3D_RightDown[(Player number of (Triggering player))] Equal to False
        
        C3D_DownDown[(Player number of (Triggering player))] Equal to False
        
        Then - Actions
        
        Set C3D_PointDegrees[(Player number of (Triggering player))] = (C3D_PointDegrees[(Player number of (Triggering player))] + 10)
        
        Else - Actions
        
        If (All Conditions are True) then do (Then Actions) else do (Else Actions)
        
        If - Conditions
        
        C3D_UpDown[(Player number of (Triggering player))] Equal to True
        
        C3D_LeftDown[(Player number of (Triggering player))] Equal to False
        
        C3D_RightDown[(Player number of (Triggering player))] Equal to True
        
        C3D_DownDown[(Player number of (Triggering player))] Equal to False
        
        Then - Actions
        
        Set C3D_PointDegrees[(Player number of (Triggering player))] = (C3D_PointDegrees[(Player number of (Triggering player))] - 10)
        
        Else - Actions
  - Set C3D_MovePosition = (Position of Heroes_onevariable[1])
  - Set C3D_ActualPosition = (C3D_MovePosition offset by (Real(C3D_OrderedDistance)) towards (Real(C3D_PointDegrees[1])) degrees)
  - Unit - Order Heroes_onevariable[1] to Move To C3D_ActualPosition
  - Custom script: call RemoveLocation(udg_C3D_MovePosition)
  - Custom script: call RemoveLocation(udg_C3D_ActualPosition)

WaterKnight · Oct 7, 2016

You cannot check if an arrow key button is being pressed, only catch the signals when it is tapped down/released. And in some states those will not react, like the wc3 window not having focus or handling some menu.

Also "proper way" and GUI cannot be used in the same non-contradictory context.

Shyster · Oct 7, 2016

WaterKnight said:
You cannot check if an arrow key button is being pressed, only catch the signals when it is tapped down/released. And in some states those will not react, like the wc3 window not having focus or handling some menu.

Also "proper way" and GUI cannot be used in the same non-contradictory context.

OK well I'm honestly not interested in whether it is the JASS holy grail of proper-ness, I really didn't understand what you were saying. I am trying to improve what I have here and am asking for someone who can help me do that.

Pyrogasm · Oct 7, 2016

Depending on the unit, you can lock the facing of a particular bone in a particular direction. This would allow you to have the units backpedal instead of actually walking. This requires a compatible model, though; for example I think Gariothos has the right bone to lock his facing. You could also try using SetUnitPropWindow(yourUnit, 0.00) (no GUI equivalent), which means it can no longer turn to face its targets. This might entirely remove its ability to move, but it could also do what you want.

Curiousity though, has anyone tried setting a negative movement speed with some item movement bonus LUA script?

WaterKnight is saying that if the wc3 window doesn't have the proper focus while you're pressing keys (dialog window open, alt-tabbed, etc.) it will not detect key release events. There's pretty much nothing you can do about this as far as I am aware other than tell people not to release the keys while wc3 doesn't have focus.

Shyster · Oct 8, 2016

Pyrogasm said:
Depending on the unit, you can lock the facing of a particular bone in a particular direction. This would allow you to have the units backpedal instead of actually walking. This requires a compatible model, though; for example I think Gariothos has the right bone to lock his facing. You could also try using SetUnitPropWindow(yourUnit, 0.00) (no GUI equivalent), which means it can no longer turn to face its targets. This might entirely remove its ability to move, but it could also do what you want.

Curiousity though, has anyone tried setting a negative movement speed with some item movement bonus LUA script?

WaterKnight is saying that if the wc3 window doesn't have the proper focus while you're pressing keys (dialog window open, alt-tabbed, etc.) it will not detect key release events. There's pretty much nothing you can do about this as far as I am aware other than tell people not to release the keys while wc3 doesn't have focus.

I'm not sure that bone tip would help since there's 55 heroes I've got to do this with. That's interesting about the window thing, but that's not my issue. It happens without accidentally alt tabbing or anything. I guess I tend to notice while fighting because I press the keys more often, but again I haven't been able to reproduce the bug reliably...

Pyrogasm · Oct 8, 2016

WaterKnight said:
And in some states those will not react, like the wc3 window not having focus or handling some menu.

Not exactly alt-tabbing but something is causing the event not to register. Could be any number of things that potentially bock key input in the game.

Shyster · Oct 8, 2016

Pyrogasm said:
Not exactly alt-tabbing but something is causing the event not to register. Could be any number of things that potentially bock key input in the game.

Well I attached the map because I couldn't find a commonality between the seemingly random occurences. It's just a small 2 lane test map AoS, nothing huge going on.

Dr Super Good · Oct 8, 2016

Keyboards work by sending key press and release events. Hence the numlock bug in Diablo III.

One adds conditions to the press events to prevent double presses and then accepts that some times a key will become stuck. If it becomes stuck the player can always depress it again to unstick it as the depress actions will only run once thanks to keeping track of the current key state.

Players may also use third party tools to force such events in an illogical way. Nothing stops a third party tool sending to the server 1337 key press events without a single release event. Again another reason why one should keep track of press/release state and not run actions on duplicate press events.

Shyster · Oct 8, 2016

Dr Super Good said:
Keyboards work by sending key press and release events. Hence the numlock bug in Diablo III.

One adds conditions to the press events to prevent double presses and then accepts that some times a key will become stuck. If it becomes stuck the player can always depress it again to unstick it as the depress actions will only run once thanks to keeping track of the current key state.

Players may also use third party tools to force such events in an illogical way. Nothing stops a third party tool sending to the server 1337 key press events without a single release event. Again another reason why one should keep track of press/release state and not run actions on duplicate press events.

Does that mean the system I downloaded here just inherently is going to have this issue? This is all pretty new to me so i do not know if i need to find another system or try to improve the existing one

Dr Super Good · Oct 8, 2016

Shyster said:
Does that mean the system I downloaded here just inherently is going to have this issue?

I am not sure what the system does. But I was simply suggesting that checks be added to detect double press or depress events in case the logic assumes they cannot happen.

Emm-A- · Oct 8, 2016

I had that problem once, that some arrow keys seemed to be stuck in "press down" mode. It turned out that the player should not chat, that means press enter, while using the arrow keys. Do you think this was the case for you?

Shyster · Oct 9, 2016

So no one has looked at the map I attached for themselves? Here is the system I downloaded: ARROW MOVEMENT SYSTEM v1.3 [updated]

As I said I only made a few slight modifications which you can easily test. Also, no Emm-A- it wasn't chat related. But now that the idea of double press has been mentioned I'm really hoping someone will look at the map because I am pretty sure this system does not account for that. In fact I was wondering how to do so the other day.

Shyster · Nov 4, 2016

Bump. Would be grateful if someone looked at the map.

streetpunk · Nov 4, 2016

Hey Shyster, how goes it? I think I know what causes this issue: selections. I experienced something similar on my project, if you select something while holding the arrow key it might get stuck into press state.

Shyster · Nov 4, 2016

streetpunk said:
Hey Shyster, how goes it? I think I know what causes this issue: selections. I experienced something similar on my project, if you select something while holding the arrow key it might get stuck into press state.

lol wait a sec... why would anyone make an arrow key system at all if it gets glitched by something so basic that you do multiple times per second?

Besides I've seen it happen on this map I uploaded without clicking anything.

streetpunk · Nov 5, 2016

I'll check it out!

Kazeon · Nov 7, 2016

Hello.

I have tested the map and played it for a while but couldn't reproduce the bug you mentioned. I also tried to press all arrow keys like crazy but still no luck.

There are several things which are probably causing this issue:
- Disabling user control when arrow key is pressed
- Pausing game (includes minimizing program) when arrow key is pressed
- Entering chat mode when arrow key is pressed
- Pretty much everything that's interfering with keyboard or user control

However, I checked all triggers but couldn't find anything suspicious. As far as I see, you aren't using neither cinematic mode, game pause, nor disable user control. I didn't see any problem with the arrow key system you are using as well. So, are you sure the bug really appeared randomly?

For now you need to make sure the issue really exists.

Shyster · Nov 7, 2016

Thanks for the replies I appreciate it lots. I've been thinking about this for days but I haven't booted it up again til just now. It would seem I was wrong; streetpunk's hypothesis was correct. Selecting ANYTHING while using the keys in most any way causes one key to get stuck almost every time.

This is a huge mind!@#% to me...how does anyone play games with arrow keys where you have to select things all the time? That's like the worst kind of bug you could have... at least we know what the issue is now? #glassishalffull

streetpunk · Nov 7, 2016

I was right for once, that's new hahaha maybe you can make a trigger that is fired upon selection, that will manage to deal with the bug, something like: player selects something -> check if pressed -> set key variable to negative

Shyster · Nov 7, 2016

streetpunk said:
I was right for once, that's new hahaha maybe you can make a trigger that is fired upon selection, that will manage to deal with the bug, something like: player selects something -> check if pressed -> set key variable to negative

But then any time you select something it'll screw up your movement in a slightly different way than before. The issue isn't actually resolved.

I don't know if all other systems have this issue, but most arrow key systems I've found either say they are JASS, (I do not know it, and am not installing 2000 plugins + JNGP since it runs SO SLOW) or they are bound to cardinal directions. I had to edit this one so it is based on the unit's current facing instead.

Pyrogasm · Nov 8, 2016

Shyster said:
(I do not know it, and am not installing 2000 plugins + JNGP since it runs SO SLOW)

With that kind of attitude you might as well give up ever getting this to work. The JNGP is not laggy-- if it was someone else would have pointed it out long before now. It does have some issues redrawing windows in Win10, but it has run perfectly fine on every shitty computer I've ever owned. There are no plugins required. To use it you literally put it in your Wc3 folder and double click it.

Shyster · Nov 8, 2016

I've used it plenty. I got rid of it because it was much slower performing basic operations than the default world editor, that is a fact. By plugins I am just referring to many spell systems (or arrow key systems) that require tons of other systems to work.

Pyrogasm · Nov 8, 2016

I don't know what to tell you other than that you are straight up wrong about it being slow. The problem is with your system, not the program.

Which is more likely: that you as a user have just now discovered something that thousands of other wc3 modders have never noticed about the JNGP... or that your experience is not representative of the program?

Shyster · Nov 8, 2016

I don't need to be lectured on the likelihood of my discovering something first. Should I edit the post to say slow for me? Obviously it is my experience. It probably is my machine. Anyway, none of this is productive as you can see I am quite aware of the situation with JNGP already. Do you know anything about the issue I am discussing here?

KILLCIDE · Nov 8, 2016

Shyster said:
By plugins I am just referring to many spell systems (or arrow key systems) that require tons of other systems to work.

The systems are there for a reason. The creator didn't choose it because they wanted to, but because it was needed. Heck, one of those systems you are complaining about probably found a way to fix the selection bug.

Shyster said:
I got rid of it because it was much slower performing basic operations than the default world editor, that is a fact.

Sounds like an issue on your end. Do you mind elaborating what "slower performing basic operations" means? Did you have the Brush List enabled?

Shyster · Nov 8, 2016

KILLCIDE said:
The systems are there for a reason. The creator didn't choose it because they wanted to, but because it was needed. Heck, one of those systems you are complaining about probably found a way to fix the selection bug.

Sounds like an issue on your end. Do you mind elaborating what "slower performing basic operations" means? Did you have the Brush List enabled?

Well, I have a theory on how to fix my issue and I need to do a bit of digging before I know for sure but I will get started on that soon.

Regarding JNGP no I terminated that vile Brush List long ago thankfully. Off the top of my head, I remember editing GUI trigger fields took 3-4 times longer than normal. My project is rather large so it can be slow as it is. It felt as though the brush list had been turned back on but in more ways than the brush list ever affected the WE, basically

KILLCIDE · Nov 8, 2016

Oh you downloaded the newest version of JNGP. Currently, looking_for_help's TESH included in the new package causes that issue. It can easily be fixed by just using an older version of TESH. I brought up this issue to looking_for_help way before it was included in the new JNGP.

Shyster · Nov 8, 2016

KILLCIDE said:
Oh you downloaded the newest version of JNGP. Currently, looking_for_help's TESH included in the new package causes that issue. It can easily be fixed by just using an older version of TESH. I brought up this issue to looking_for_help way before it was included in the new JNGP.

Ah ok, that is good info thanks for the help. Maybe if my idea fails I'll give that another spin

Shyster · Nov 10, 2016

So my theory did not work. I have tried three different systems:

Advanced Camera, Keyboard & Movement System

ARROW MOVEMENT SYSTEM v1.3 [updated]

GUI Movement System v1.6

---

All three of them have the same issue. I couldn't find any more if there are any. Has it always been this way? I've never seen anyone else bring up this issue.

KILLCIDE · Nov 10, 2016

Probably because most maps that use an arrow system also means they have no use for using selection. Using selection at that angle would just be a pain in the ass.

[Trigger] Arrow Keys - randomly getting stuck in "pressed" position

Attachments

Similar threads