You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm running KSP on Linux, and it seems that the Linux build of KSP does not return correct key codes for special keys. Sadly this includes the return key. This means that I'm unable to confirm the delay setting in Remote Tech, making this function unavailable on Linux. Although this is a stock, or more correctly, a Unity bug, it can be worked around on a per-mod basis.
Steps to reproduce:
On Linux KSP+RT, open the flight computer, extend the queue and dely panel, input something into the delay panel and press the return key.
Expected: The set delay should be taken into account after pressing return
Happened: An invisible character gets added at the end of the text, delay isn't taken into account.
Something that is probably the same issue has been investigated for kOS here: KSP-KOS/KOS#206
It seems that there is something wrong with padding the key codes to full datatype length, where, instead of zeroes, ones are padded.
Possible solutions:
o) Discard the higher byte for key codes, like kOS does
o) Add a button, that applies the set delay value
The text was updated successfully, but these errors were encountered:
I'm running KSP on Linux, and it seems that the Linux build of KSP does not return correct key codes for special keys. Sadly this includes the return key. This means that I'm unable to confirm the delay setting in Remote Tech, making this function unavailable on Linux. Although this is a stock, or more correctly, a Unity bug, it can be worked around on a per-mod basis.
Steps to reproduce:
On Linux KSP+RT, open the flight computer, extend the queue and dely panel, input something into the delay panel and press the return key.
Expected: The set delay should be taken into account after pressing return
Happened: An invisible character gets added at the end of the text, delay isn't taken into account.
Something that is probably the same issue has been investigated for kOS here:
KSP-KOS/KOS#206
It seems that there is something wrong with padding the key codes to full datatype length, where, instead of zeroes, ones are padded.
Possible solutions:
o) Discard the higher byte for key codes, like kOS does
o) Add a button, that applies the set delay value
The text was updated successfully, but these errors were encountered: