+REP macros run odd if another +REP macro runs and then stops.

ID:2240945
 
Apr 26 2017, 12:50 pm
Resolved
Key repeats were frequently ignored in some cases.
BYOND Version:511
Operating System:Windows 7 Ultimate 64-bit
Web Browser:Chrome 58.0.3029.81
Applies to:Dream Seeker
Status: Resolved (511.1382)
This issue has been resolved.
Descriptive Problem Summary:
If you press a +REP macro, press another while still holding the first, and release the second, the first will fire at about half speed until all keys are released.

Numbered Steps to Reproduce Problem:
Open stub world with an empty map that has enough room to move around.

  1. Open stub world with an blank map that has enough room to move around.
  2. Hold down
  3. Wait one second (or so)
  4. Hold left (don't release down) (this will cause you to move left at normal speed)
  5. wait one second
  6. Release left (you will resume moving down, but at about half speed with randomish delays(see below))


Code Snippet (if applicable) to Reproduce Problem:
client
    var/lastmove = 0
    Move()
        var/diff = world.time - lastmove
        lastmove = world.time
        src << "MOVING: [world.time] ||| [world.timeofday] ||| time since last move: [diff]"
        . = ..()


Expected Results:
MOVING: 137.1 ||| 709149 ||| time since last move: 0.5
MOVING: 137.6 ||| 709149 ||| time since last move: 0.5
MOVING: 138.1 ||| 709150 ||| time since last move: 0.5
MOVING: 138.6 ||| 709151 ||| time since last move: 0.5
MOVING: 139.1 ||| 709152 ||| time since last move: 0.5
MOVING: 139.6 ||| 709153 ||| time since last move: 0.5
MOVING: 140.1 ||| 709153 ||| time since last move: 0.5

Actual Results:
MOVING: 141.6 ||| 709156 ||| time since last move: 1.5
MOVING: 142.1 ||| 709156 ||| time since last move: 0.5
MOVING: 144.6 ||| 709160 ||| time since last move: 2.5
MOVING: 145.6 ||| 709161 ||| time since last move: 1
MOVING: 147.6 ||| 709164 ||| time since last move: 2
MOVING: 148.1 ||| 709165 ||| time since last move: 0.5
MOVING: 150.6 ||| 709168 ||| time since last move: 2.5
MOVING: 151.6 ||| 709169 ||| time since last move: 1
MOVING: 153.6 ||| 709172 ||| time since last move: 2
MOVING: 154.1 ||| 709173 ||| time since last move: 0.5



Workarounds:
Mousedown + mouseup binding and roll your own repeating functionality




Related: https://github.com/tgstation/tgstation/issues/26604

Note: this seems to happens for all verbs, not just movement ones, but its only movement ones that you would really notice it on.

also does it on macros that run instant verbs
Apr 26 2017, 1:19 pm
Yikes. This will be barrels of fun to investigate.
Apr 27 2017, 12:55 am
1378 introduced the bug

there is also a noticeable animation slowness in 1378 compared to 1377, most likely the cause of id:2239732
Apr 27 2017, 8:21 am
By animation slowness do you mean animate() or do you mean a change to icon animations? And is the problem strictly on the client end?

There were macro behavior changes in 1378 that might explain the repeat macro issue somewhat here, although I don't yet see the connection.
Apr 27 2017, 8:49 am
glide animation and apparent movement speed actually
Apr 27 2017, 11:31 am
There was a change to pixel gliding in that same build, but it shouldn't have impacted non-pixel projects.
Apr 27 2017, 1:13 pm
http://files.byondhome.com/MrStonedOne/ sight%20check%20-%20Copy.7z is the project i used to test.

I'm not fully sure on the animation latency anymore, i did notice in my first test thru but i was also testing over remote desktop so it might have been entirely made up, or it might have been a side effect of the macro bug since testing latency involves mashing different arrow keys

I don't really see it now so that part could be ignored for now.
Apr 27 2017, 1:18 pm (Edited on Apr 27 2017, 2:09 pm)
No, actually i do see it, it seems like there is a longer/slower ramp up in animation speed for tile glides in 1378 compared to 1377 or like a longer pause between the first step and the next, that makes things seem laggier and less snappy. This is all really subject thou, it could even be placebo.

Edit, its actually related, the first few macro repeat fires seem to come in later.

1378:
MOVING: 31993 ||| 760561 ||| time since last move: 13.5
MOVING: 31994 ||| 760563 ||| time since last move: 1
MOVING: 31996 ||| 760566 ||| time since last move: 2
MOVING: 31996.5 ||| 760567 ||| time since last move: 0.5
MOVING: 31997 ||| 760568 ||| time since last move: 0.5

1377:
MOVING: 31497 ||| 760899 ||| time since last move: 50.5
MOVING: 31498 ||| 760900 ||| time since last move: 1
MOVING: 31498.5 ||| 760901 ||| time since last move: 0.5
MOVING: 31499 ||| 760902 ||| time since last move: 0.5
MOVING: 31499.5 ||| 760902 ||| time since last move: 0.5
MOVING: 31500 ||| 760903 ||| time since last move: 0.5
Apr 27 2017, 2:11 pm
I've noticed in a empty project with fps set to 60 with a simple Login() & ..() movement is jumpy when trying to move in a direction at the beginning then smoothens out after a few steps. It's even more noticeable when using a small step_size.
Apr 28 2017, 8:45 am
I can see an inconsistency in the timing from your demo, so I'll try to get to the bottom of it.

The weird part is after I release the second key, the timing tends to alternate between 2.5 and 0.5.
May 2 2017, 12:47 pm
Well, this is fun. The issue so far only happens in release mode, which means it's gonna be a pain to figure out.
May 2 2017, 12:58 pm
Well, we know what version it happens in, so look at the code diff for that version, then look at anything that would change in debug mode relating to that code

It should give you a very narrow section of code to look at.

Hopefully something pops.
May 2 2017, 1:20 pm
Lummox JR resolved issue with message:
Key repeats were frequently ignored in some cases.