AJ MacLeod wrote:
> On Thursday 26 January 2006 21:00, Josh Babcock wrote:
>>AJ, I wasn't really following this, and didn't realize what you were
>>doing. My joystick config has differential thrust based on the rudder
>>position. Find it here:
>>It sounds like you are trying to do something very similar.
> Hi Josh,
> My, that's some JS config :-) My braking function works (actually very much
> better than I had hoped for!) now that the listener segfault has been sorted
> - the main benefit that I see is that all that is required in the JS config
> is a simple property assignment on the trigger press (and a cancelling
> This would make it easier for others to use (since it's only a few lines to
> paste in) but my question was really a more fundamental one ; I'd like it to
> be even easier because I know that probaby only one or two people would ever
> bother to try it.
> A simple way of allowing the aircraft to _temporarily_ map functions or
> properties to joystick buttons (if permitted or rather not specifically
> denied) would be nice. Obviously slightly problematic in that sticks vary
> quite considerably, but if the configs listed buttons and axes with
> predictable and descriptive names, I'm sure it could be done quite reasonably
> in a mostly automatic manner.
> Really I was just raising the question, checking I hadn't missed anything...
> I'm not up to implementing anything better myself so it looks like the one or
> two adventurous souls out there will have to cut and paste...
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> Flightgear-devel mailing list
I think that the important thing is that there be two layers. The first
links buttons to functions, and is the purview of the user. If I want
this button to toggle that widget, I don't want anything changing that.
The second layer is the responsibility of the aircraft designer. He has
to determine what it actually means to toggle that particular widget.
This layer connects the first layer to the actual property tree via a
This is pretty much what we have now with controls.nas, but like was
said before not all of the functions have been populated and in some
cases the joystick, mice and keyboard files are directly touching the
properties. If we can fix that then any aircraft designer can implement
any function however he chooses without worrying about the user's
customization and vise versa. The designer just has to remember to be
honest. I don't want to be surprised by some widget extending from the
airplane when I try to extend my flaps, unless that is really what
passes for a flap in that aircraft in real life.
The big caveat that I see is that when someone comes up with a plane
that has some new cool function that is integral to the plane, no one
will have their joystick configs set with a button assigned to this new
One potential solution is to define several reserved functions, maybe a
couple toggles and a few sliders. People could assign controls to these
functions knowing that they are generally meaningless on most aircraft,
but that an aircraft designer may chose to assign some meaning to them.
That way no function that the user considers important will get stepped
on. When one of these gets used, the designer just has to say "Oh, by
the way genericFunctionOne() works the frambulator, so whatever control
you have assigned to that function, use it"