armory
armory copied to clipboard
armory3d
Keyboard started / released interupts on Hashlink linux
Thank you for contributing to Armory!
Description Keyboard key started and Keyboard key released into the start/stop sockets of a pulse node will discontinue after about 1 second when both the started/release key are both the same on linux hashlink.
To Reproduce Keyboard: space [started || down]-> pulse start socket @ interval 0.010 Keyboard: space [released ]-> pulse stop socket tested by getting a rotation of 1 object and setting a rotation of another
Expected behavior Pulse should stop once keyboard is released instead of getting interrupted within 1 sec. Does not occur in browser, hashlink (linux atleast) only.
System Blender: 2.9lts Armory: sept build OS: Ubuntu 22.04.1 LTS
I'm unable to reproduce this on windows-hl, could you please share a video, a screenshot of the exact logic tree or (even better) an example file? Also, what happens if you add a print node to the space [released] node. Does it fire after a second? If yes, this sounds like a Kha/Kinc issue to me.
@MoritzBrueckner he's using Linux, so it's possible more of an OS dependent issue and can't be produced on a Windows OS.
This is what I meant, yes I am on linux. This does not happen on browser target only hashlink for me, and only if the key is the same for down/released
Adding a print node in between the released and pulse stop socket will print after a second holding it down and will constantly print on every frame until let go.
I think there are not chances to this being a OS problem related to inputs, so maybe there is something wrong with the value returned from Time.time() in Linux that makes the value be rounded to 1 second or idk
The node isn't complex, everything happens in the update() function with the value returned by the time() function https://github.com/armory3d/armory/blob/main/Sources/armory/logicnode/PulseNode.hx
I recall trying to use sys time, kha schedular time, kha realtime, as well as offsetting the time within the pulse node +/- which is all I could think of trying in regards of the time being incorrect. I think it may be related to the up down key listeners state because random behavior such as pressing a random key before the pulse finishes will keep the pulse from interrupting and will work from then on.
The thing I suppose: X11 being asynchronous, when a message with key released comes, the node's instantly restarted by a key down, considering the amout of even the window manager gets with a keydown, it gets stacked on the even list and on will always come up on top of the keyrelease. Set a variable to true with keyrelease and test for this variable for stopping the pulse !
That test would be useful. I "refactored" the input class months ago while running linux and never noticed anything wrong with the input listeners, so i can just suspect about the time() function