 |
I believe the Falcon BMS known bugs category may be more appropriate for this issue. A moderator might be kind enough to move it. Cheers. |
|
|
Relevant forum thread https://www.benchmarksims.org/forum/showthread.php?39065-SimHsiCourseInc-still-increments-by-1&highlight=SimHsiCourseInc |
|
|
Seems like the right fix is (a) add a line set g_nKnobAccelerationDelta 300 // Milliseconds between subsequent clicks/rotations, to move knobs 5° instead of 1° to the 'falcon bms.cfg' file (and consider adding it to the Config.exe UI but I think this is the kind of thing than can be self-discovered in the cfg file, when needed). Or just raise the default .. but it seems preferrable to make these things self-discoverable and self-documenting, in the cfg file. And (b) update the docs for g_nKnobAccelerationDelta to remove references to the "By5" callbacks .. there are none .. I think I understand what the doc is trying to say (ie. the generically named callbacks change behavior based on this cfg settings, and frequency of click -- while the "By1" callbacks do not) but it's very confusingly written. |
|
|
And (c) update the short descriptions in the key files, which confusingly declare that SimHsiCourse/Heading callbacks move by 5° |
 |
@Airtex2019, that suggestion to update the docs might be a good issue to post to the Documentation project. I'm inclined to close this one as it's not a bug, it's a feature. The callback increments by 1, unless you repeatedly use it, in which case it increments by 5. |
|
|
It's the literal description strings in the keyfile that threw me off. Not sure if that counts as a doc-bug or data-bug, or code-bug. But I'd agree most of this could be covered by fixing up the doc. |
|
|
Opened separate doc-bug: https://bmsbugs.blu3wolf.com/view.php?id=105 |
|
|
Fish, does adding the config file entry sort this out for you? As I understand it, you want the callback to increment/decrement by 5, instead of selecting 1 or 5 based on rate of the callback? |
|
|
Issue for me is i use an encoder to move the CRS and HDG, but they are so slow at 1deg increments, to make them unusable. Config entry which made it adjustable is always preferable to hard coding a value. (and an update to the config descriptions). Cheers, |
|
|
I would hope that the callbacks,... SimHsiHdgIncBy1 116 0 0xC7 2 0 0 1 "MAIN: HSI HDG Knob - Increase (1°)" SimHsiHdgDecBy1 116 0 0xC7 4 0 0 1 "MAIN: HSI HDG Knob - Decrease (1°)" SimHsiCrsIncBy1 116 0 0xD3 2 0 0 1 "MAIN: HSI CRS Knob - Increase (1°)" SimHsiCrsDecBy1 116 0 0xD3 4 0 0 1 "MAIN: HSI CRS Knob - Decrease (1°)" are not modified, as they work as expected. Thanks for all your good work and patience. |
|
|
Cant you use the encoder with the by5 callbacks? If you turn the encoder rapidly, you should get increments by 5, and if you turn it slowly, increments by 1. If I recall correctly, this was added for specifically the case of pitbuilders using encoders. |
|
|
Hi Blu3wolf, In answer to your question, the encoder provides a keydn/keyup (with a fixed time lag in between) for each pulse, but there's a hardware limit to the speed of pulses. Its a switch encoder, and maybe other types of encoder or IO boards can get better performance. But don't wish to make this discussion about my issue. The inconsistency remains, Take call backs to increment the CRS as one example of the 4 actions in question. SimHsiCourseInc 116 0 0xC9 2 0 0 1 "MAIN: HSI CRS Knob - Increase (5°)" SimHsiCrsIncBy1 116 0 0xD3 2 0 0 1 "MAIN: HSI CRS Knob - Increase (1°)" Both of these call backs behave exactly the same way for me, they increment the CRS by 1deg for a single input pulse/keydn-keyup, no matter what the time is between the up and down. Both for key binds and HID button input. As devs i understand you must prioritise importance , and it would not be the end of the world is the fix is to remove the 5deg call backs from the documentation, since they duplicate the 1deg call backs. My preference, however, would be to be able to move the knobs by 5deg from a single pulse, along with moving them 1deg from a separate call back. Rgds Fish. |
|
|
Is g_nKnobAccelerationDelta no help? Docs say the default is 60ms which imho is pretty crazy fast. |
|
|
Many thanks Airtex, It was not clear to me from your post that that g_nKnobAccelerationDelta functionality was already in BMS. I have now tested @300s and definitely pushes the knob round fast. Need to fine tune it now. Great. I guess the only thing needed is to modify the call back descriptions as you suggested. Cheers. |
|
|
Cool -- no worries. I was also not able to discover this on my own.. I also assumed the "by 5" callbacks were broken, until someone explained it to me. My fix would be: - raise the default from 60 to 300 so this acceleration behavior is more intuitively discoverable (60ms is faster than many systems input-to-render latency... about 1/17th of a second. very hard to click a mouse or press a key faster than 17 times/sec.) - add a line to default cfg file (and set it to 300 there). - [consider] make it so that g_nKnobAccelerationDelta=0 always adjusts by 5 (for the not-by1 callbacks). for folks who want to bind separate inputs to coarse-adjust vs fine-adjust |
|
|
most systems have much lower render latency than 60 ms. 60 ms is a long time, in computing. When last I looked at this, it was trivial to adjust with the mousewheel, which is what I think the default is based around? |
|
|
Just play-tested that a bit and I agree, 60ms seems well tuned to distinguish between slow-mousewheeling and fast-mousewheeling. (I normally fly with g_bMouseWheelKnobs=0 because I hate trying to zoom in/out and accidentally twirling a random knob.) I'd still like to see a line for g_nKnobAccelerationDelta added, right under g_bMouseWheelKnobs in the default cfg file, so it's discoverable.. even if it just explicitly setting the default 60. |
|
|
So, we have 0000105 for updating the documentation to better allow for user discoverability of this feature. AFAIK @Fish has their problem sorted - so I guess we can go ahead and close this one at this point? |
|
|
I'm ok with closing this one. |
|
|
Happy to close it. Many thanks for all contributions. |
|
|
closing as no change required. |
- Anonymous
