![]() ![]() Further reading, the proper format is "dead-band" when searching, and there is mention, "tag *must* precede the binding tag." However, I eventually hopefully found a good example of using the deadband property via a Google search: The "Docs/" contained two quick mentions of deadband, but nothing explicitly related to whether it should be outside the "binding" subsection. (But as they say, where there's smoke there's fire.) And apparently the X52-pro suffers from this same problem. Other than this, the lackings of the X52 were very informative. Rogerx Posts: 65 Joined: Sun 10:39 am Location: Conneaut, Ohioįlyingsolo: Two of your pictures using the are failing to show-up. + -806,4 +812,4 No newline at end of file (FlightGear's white spacing is acting funny, as well as this forum's editor's spacing, but all text under my O/S is properly indented within VIM! -)Ĭode: Select all - src/flightgear/flightgear-data/fgdata/Input/Joysticks/Saitek/ 13:09:15.532534860 -0800 Ten percent probably is one notch under Windows? So maybe 0.075?) (Guessing, about 3/4's of one notch under Windows for deadband. I put the Deadband in anyways, because I do notice some minimal jitter while under Windows, and I have a very small deadband set on the Aileron, Elevation, and Rudders under Windows. Similar to adjusting the factor variable under Windows, factor seems to have no obvious effect while under Windows. Seems I have to specify 1.0 to see any effect with the Deadband variable. The Deadband option seems to have little effect here under Linux, if any. Like I previously stated, under Windows users can easily increase the deadband settings for the axis and prevent the over steering while on ground, but then they still have the rubber-band effect while steering in air? rogerx Posts: 65 Joined: Sun 10:39 am Location: Conneaut, Ohio Or, focusing on a median for this joysticks settings, versus what the simulation does? (In other words, rubber banding seems to be contributed by over-steering, or the higher factor/sensitivity?) Anyways, probably should focus on realistic flight control surfaces, and then if the nosewheel steering needs to be stronger, then exponentially factor, or vice versa. My guess is nosewheel steering on th eground might be accurate(?), but upon lift-off, the rudder steering isn't reduced. Rudder surfaces probably shouldn't be able to steer the aircraft until there's sufficient air moving over the surfaces.) On real Cessna's there is nosewheel steering, operated by the rudder pedals as well. I have tested the 0.3 and must say that is probably more realistic. I'm using factor 0.4 and haven't tested the dynamic x* equation above. I'm all for doing something with the decreasing the factor, or doing whatever needs to be done. I should note I'm running SVN/GIT version or 3.1.0 I tried differenent values, and got no response from the axis. I just tried "(x*(-0.5))^2" and ((x*(-0.5))^2) within the Brows Internal > joystick > axis > binding (etc) and the axis no longer worked. I think 0.5 is the upper preference range, while 0.3 being the lower range? (Trying 0.3, 0.3 seems probably more realistic!) I think I also tried using the factor to 0.5 under Windows for rudder axis, and noticed no real differences in control under Windows. When under Windows, Windows users (including when I rarely use Windows) can hack around this by meerly adjusting the deadbands. (Or, just doesn't feel realistic at all or just feels bad, further contruting to a rubber band effect when moving any of the flight control surfaces such as Ailerons, Elevator and Rudder.) Under Linux there's no easy way to simply adjust the deadband for simple Linux users, and the joystick control feels extremely overly sensitive. ![]()
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |