Can i make the Key input outtime longer?
-
Hey all.
i can edit an option to make the outtiming of the key input for the fms make longer?
Regards Daniel -
Oh, I think I understand what you're looking for. If you have the PC version, you can make one tiny edit to a file to make the timeout longer. Search your Community Folder for
bksq-aircraft-starship\html_ui\Pages\VCockpit\Instruments\NavSystems\bksq-aircraft-starship\CDU.CDU.js. Within that file, search forthis.keyboardTimeoutInterval =, and change the value to how many seconds you would like it to remain active, multiplied by 1,000. Let me know if you have any trouble! -
Thank you... this i have search Big Thanks!
-
With the latest update, I believe the keyboard mode now also blocks clicking the LSKs when making flight plans?
On 1.1, I edited the timeout and was mostly happy with the process then.
Now in 1.2, I use mouse to go to keyboard mode - type in a waypoint - have to click out of keyboard mode - then select the LSK - then have to click again to get into keyboard mode to write the next waypoint. Turns into a lot more fiddling when entering longer routes.Not sure if it is something changed on my side, or this was really an intentional "upgrade"?
-
With the latest update, I believe the keyboard mode now also blocks clicking the LSKs when making flight plans?
On 1.1, I edited the timeout and was mostly happy with the process then.
Now in 1.2, I use mouse to go to keyboard mode - type in a waypoint - have to click out of keyboard mode - then select the LSK - then have to click again to get into keyboard mode to write the next waypoint. Turns into a lot more fiddling when entering longer routes.Not sure if it is something changed on my side, or this was really an intentional "upgrade"?
@Avionic I don't believe anything changed on my end regarding the keyboard input since release. In fact, the keyboard entry has always blocked out other mouse interactions, which made it a very scary feature to implement with the Dukes for the first time. Imagine an edge case resulting in all mouse interaction being blocked indefinitely for the user! Luckily, the behavior has been very reliable. If you think you're seeing something unusual or undesirable, feel free to share a video, and I can take a look!
-
@Avionic I don't believe anything changed on my end regarding the keyboard input since release. In fact, the keyboard entry has always blocked out other mouse interactions, which made it a very scary feature to implement with the Dukes for the first time. Imagine an edge case resulting in all mouse interaction being blocked indefinitely for the user! Luckily, the behavior has been very reliable. If you think you're seeing something unusual or undesirable, feel free to share a video, and I can take a look!
@Black-Square Might just have been my little hiatus between flying 1.1 and 1.2 that has me misremembering how it worked previously.
I guess I could bind the LSK for entering the waypoint to cut down on all the back and forth with the mouse mouse. Without airway entry, routes can end up quite long.
-
@Black-Square Might just have been my little hiatus between flying 1.1 and 1.2 that has me misremembering how it worked previously.
I guess I could bind the LSK for entering the waypoint to cut down on all the back and forth with the mouse mouse. Without airway entry, routes can end up quite long.
@Avionic I made pressing enter also terminate keyboard entry, which it what I use to do it quickly.
-
@Avionic I made pressing enter also terminate keyboard entry, which it what I use to do it quickly.
@Black-Square Ah - that sounds good.
Could even be that I had instinctively been using enter in the past, as a carryover of my operation of the KLN-90B. There, pressing enter is bound to the physical ENT key, so fx route entry can be handled entirely on the keyboard.But of course that is also a system with a different philosophy, with dedicated keys instead of LSKs, so a bit more logical to make a full on keyboard operation mode for it.
