Open TrucksO opened 2 years ago
Happens to me too every once in a while. I haven't found any solution so far.
Just to note that I see this problem quite a lot. I have not been able to isolate it.
I haven't been able to reproduce this on my machines, so I'm afraid I can only guess at what might be going on. It's undoubtedly related to the wheel-spin acceleration change I made in 1.1.0 beta 2, since that intentionally changed the keyboard auto-repeat handling. But beyond that, it's guesswork on my end, because I can't replicate it and therefore can't catch it in the act to trace through whatever code is going wrong. The OP is on Windows 10, and I'm testing on 7 and 8.1, so maybe it's some subtle change in Win 10 to the way the system delivers WM_KEYxxx events that I'm not accounting for properly, although I haven't seen any documentation to suggest there are any such changes. Or maybe it's something hardware-specific. At any rate, as a wild guess, I've added some extra key state checks to try to stop the auto-repeat even if the key-up events go missing. Testing on my machine obviously doesn't tell me if it'll make any difference, since I can't seem to replicate the problem in the first place, so hopefully someone who's been experiencing the problem will be able to try it out. 1.1.0 beta 6, just posted.
Thank you very much for taking care of this issue! I did a quick test with beta 6 (will look closer when I'm back home). The issue still remains being present (using Windows 10). However, there is a change in behaviour. Previously, when the wheel was scrolling into one direction, a keypress with the opposite flipper button lead to the wheel immediately spinning into the other direction. Now, the wheel stops spinning at that position. Maybe this observation helps a bit. I think the initial issue with somehow not detecting the keyrelease and thus starting to scroll is not affected by the code change.
Further observation: The unwanted scrolling starts only if a flipper button is released very quickly after pressing the flipper button. When the flipper button is held until one or more than one table is cycled and then released, the scrolling does not continue. Another observation: After using PinballY for a short time, the issue disappeared. I could navigate as intended and the scrolling did not start, even when quickly pushing and releasing flipper buttons. I don't know what caused that change in behavior.
Thanks for trying it. Sounds like my guess about the cause was wrong. I don't have any other ideas at the moment, but I'll let you know if I think of anything. Out of curiosity, do you get any sticky repeat problems anywhere else other than the wheel spin? E.g., if you press Start to open the Play menu and press Next, can you get the sticky repeat to happen there as well?
Thanks for trying it. Sounds like my guess about the cause was wrong. I don't have any other ideas at the moment, but I'll let you know if I think of anything. Out of curiosity, do you get any sticky repeat problems anywhere else other than the wheel spin? E.g., if you press Start to open the Play menu and press Next, can you get the sticky repeat to happen there as well?
No, any other interaction works just fine (start, exit, menus)
Some more things to try:
I think I found the cause for the issue while following your instructions. Step 1 is before I found the cause. I just left it in.
I hope this helps to find the root cause and get rid of the issue.
After restarting PinballY with now disabled virtualDMD, the cycling/spinning behavior works flawless!
That's a great discovery. Hopefully that'll finally let me reproduce it and see what's going on internally. I expect you're exactly right that it's some kind of keyboard focus switching issue. I'll take a look at it and see what I can find.
I did a little quick testing with DMD-extensions 1.10.2 enabled, and I'm still not seeing the spurious auto-repeat. I also haven't noticed the change in repeat speed, so you might be onto something that they're related. Is there any common thread you notice in when the speed change happens? I'm thinking it could be something time-consume on the DMD-ext side that you have configured per game, like loading new media or something like that. Can you think of anything like that that you've configured on the DMD-ext side? If so, maybe try turning that off and see if that changes it - maybe we can further narrow down the specific cause not just to DMD-ext but to some particular configuration issue with DMD-ext. At any rate, it seems like the "vanilla" configuration of DMD-ext doesn't cause it all by itself, at least for me.
I'm thinking it could be something time-consume on the DMD-ext side that you have configured per game, like loading new media or something like that. Can you think of anything like that that you've configured on the DMD-ext side? If so, maybe try turning that off and see if that changes it
I think you are right. My extDMD config looks like below (inner glow, outer glow, backgroundimage, ...). But I think that extDMD is only a part of the problem. See below the code section for the tests I did and my conclusion.
[virtualdmd]
...
style = default
style.default.backgroundcolor = #ff000000
style.default.foreground.enabled = true
style.default.foreground.size = 0,8
style.default.foreground.opacity = 1
style.default.foreground.luminosity = 0
style.default.foreground.rounded.enabled = true
style.default.foreground.rounded = 0,7
style.default.foreground.blur.enabled = false
style.default.innerglow.enabled = true
style.default.outerglow.enabled = true
style.default.background.enabled = false
style.default.innerglow.size = 1
style.default.innerglow.opacity = 0,6
style.default.innerglow.luminosity = 0
style.default.innerglow.rounded.enabled = true
style.default.innerglow.rounded = 1
style.default.innerglow.blur.enabled = true
style.default.innerglow.blur = 54
style.default.outerglow.size = 8
style.default.outerglow.opacity = 0,15
style.default.outerglow.luminosity = -40
style.default.outerglow.rounded.enabled = true
style.default.outerglow.rounded = 1
style.default.outerglow.blur.enabled = true
style.default.outerglow.blur = 500
style.default.foreground.unlit = false
style.default.foreground.unlit.color = #00000000
style.default.innerglow.unlit = false
style.default.innerglow.unlit.color = #00000000
style.default.outerglow.unlit = false
style.default.outerglow.unlit.color = #00000000
style.default.brightness = 0.95
style.default.dotsize = 0.92
style.default.dotrounding = 1
style.default.dotsharpness = 0.8
style.default.unlitdot = #00000000
style.default.dotglow = 0.154471544715447
style.default.backglow = 0.154471544715447
style.default.gamma = 1
style.default.tint = #00ff5820
style.default.glass = C:\Visual Pinball\VPinMAME\DMDext\textures\glasses\glass3.jpg
style.default.glass.color = #ff808080
style.default.glass.lighting = 0.5
style.default.glass.padding.left = 0
style.default.glass.padding.top = 0
style.default.glass.padding.right = 0
style.default.glass.padding.bottom = 0
style.default.frame =
style.default.frame.padding.left = 0
style.default.frame.padding.top = 0
style.default.frame.padding.right = 0
style.default.frame.padding.bottom = 0
I did these tests:
My final conclusion: It's the combination of 3 assets being loaded (bg, table & topper image) plus extDMD being updated which affects PinballY detecting the key_up. It might be that even when not using extDMD at all, but with an even heavier load of assets (videos) the same issue might be triggered as well. But that's just an assumption...
I'm going to try adding some logging to see if I can see some more about what's going on internally. Do you use the 32-bit or 64-bit build?
I have an important remark. And I'm sorry that I didn't thought of it earlier. The manufacturer logos + table title names are shown on the virtual DMD through that PinballY flexDMD.js extension (leveraging vbousquets flexDMD rendering lib. You know that..) - I could not for the heck of it remember where the manufacturer logos + table titles were coming from (I added the .js extension long ago before I paused using my cab over the season and forgot about it). Long story short: I disabled (commented out) the flexDMD.js extension and voilá, navigation with enabled extDMD + usual table assets (BG, table, topper) works also flawless. So I think we can narrow it down to the way flexDMD is ues through your Javascript API.
That's good to know. There does seem to be a basic problem with the way the flexDMD add-in works, in that it invokes a long-running operation on the main foreground thread, which blocks UI activity for a noticeable amount of time - that really needs to be moved onto a background thread in the flexDMD code. But even so, the keyboard behavior you're seeing is still weird.
Did you see my question about which version (32 or 64) you use? I want to post a private build with some additional logging for you to try out, to see what's going on with the keyboard.
Sorry, I missed that. It's the 64-bit version.
Sorry for the delay. Here's the test build - it's just the main .exe, which you can extract and replace your existing one with. Launch it, do the usual steps to trigger the nonstop spinning, let it run for a few seconds, and close the program. Post the PInballY.log file. It should have a bunch of data on the keyboard status during the repeats - which probably won't provide an answer but might at least point to the next thing to look at.
np. Now how to start... I cannot reproduce the uncontrolled wheel spinning anymore (at least for now)! This came also as a surprise to me when I re-enabled all setting that I disabled inbetween so that PinballY is usable for me (commented out FlexDMD.js in main.js + set [virtualdmd] enabled to false in dmddevice.ini) I re-enabled both for doing the keyboard logging, but the uncontrolled spinning did not occurr. Neither with the regular PinballY exe, nor with the keylog version. First I felt bad because you provided this test build after my feedback and me not being able to report any keyboard logs.. But then I was thinking about what I changed recently in the cab. And since PinballY behaves differently in regards to the spinning issue, I figured this might help to further track down the root cause. Let me summarize what I did in the last few days:
I know, I wrote a lot of stuff here. But maybe it helps to fid the root cause.
I'm afraid that's a bit too much new information for me to speculate about a root cause or to try all of the different combinations myself. If you can't get the problem to reproduce any more no matter what you do, then it's as good as solved for your setup, and you can just call it done and move on. I'll leave the issue open so that the next person who runs into it can read back through what you've tried so far and pick up where you left off. If you do feel motivated to keep experimenting, nothing beats the scientific method - change one variable at a time, test after each change, repeat until you can identify one thing where you can conclusively demonstrate that if you do X, the problem manifests, and if you don't do X, it doesn't.
Sure, for the moment I'm fine with my cab. I really wanted to help you fixing the problem for anyone. Therefore I wrote all the details above. Ultimately it boils down to the following: If there's a problem with the communication to the LED controller / directoutput.dll, it might affect PinballYs timing and ability to react to the keyboard events.
I really wanted to help you fixing the problem for anyone. Therefore I wrote all the details above.
Certainly any information could turn out to be useful, so I appreciate you noting it all down for future reference.
Ultimately it boils down to the following: If there's a problem with the communication to the LED controller / directoutput.dll, it might affect PinballYs timing and ability to react to the keyboard events.
It's probably more productive not to speculate on an underlying theory of the root cause until we have a solid isolated test case, since these sorts of perceived correlations so often turn out to be red herrings. I wouldn't rule out a DOF delay as somehow related, although that doesn't suggest anything to me about what the underlying cause could be, so it could just as well be coincidental or randomly correlated. Hopefully someone will be able to isolate the real test case at some point - there's evidently some set of conditions that causes it given that you were able to reproduce it so consistently in your old setup.
Describe the bug The selection wheel at random times starts scrolling through multiple tables as if a button keeps getting held down, even though it was just a single, short press. For my system, this happens quite often, about 1 out of 5 button presses. At friends' VPins this is less frequent but still comes up, sometimes in the form of "double clicks/double jumps" instead of continuous scrolling. For some reason, this bug does not happen in PinballY versions 1.1.0 Beta 1, only higher versions.
To Reproduce
Alternatively, instead of steps 3, 4 and 5 the system will jump two steps instead of one, as if the button had been pressed two times in quick succession.
Expected behavior When pressing left or right flipper, it should jump one step to the next table on the left or right, respectively. Same goes for the magna except that here it should jump directly to the next letter.
Windows version Windows 10
Additional context To rule out potential problems with the flipper buttons' hardware, I tried pushing the buttons with a keyboard - same result. I also did a quick check of the registered button presses in Windows by assigning the flipper buttons to letters in Pinscape. When I then went into e.g. Notepad and pressed the buttons, it would register exactly one letter instead of multiple when I held down the button. This would imply to me, that at least on the hardware side and in Windows itself, the "registration of the keys" for lack of a better word works fine.