This is in fact my preferred solution.
- it does not break existing aircraft
- it keeps existing --enable-auto-coordination behavior
- it is configurable, even at runtime
- minimal code change
I have the patch ready and I'm about to commit it. While at it, I'd like
to move the involved properties out of "/sim/" to "/controls".
/sim is so very much unstructured and a melting pot for properties that
never found an appropriate location. And I think /controls just fits
better than "don't know where, so put it in /sim". Objections?
I'll take care of the wrightFlyer1903, the pa22, the waveXtreme150, the
Saitek X52 and the bintest protocol in FGDATA and adjust the names
accordingly.
Torsten
Am 09.03.2012 21:41, schrieb syd adams:
> Now that sounds like an even better idea.Less chance of breaking
> anything , but still adjustable.Thanks Torsten.
>
> On Fri, Mar 9, 2012 at 1:32 PM, Torsten Dreyer<tors...@t3r.de> wrote:
>> Am 09.03.2012 20:44, schrieb syd adams:
>>> Ok I haven't entirely given up on the idea of removing the
>>> auto-coordination from the code.Wouldn't it be more appropriate to add
>>> that rudder control to controls.nas?
>>> Then it can be replaced if need be on a per aircraft basis , but not
>>> break anything
>>> otherwise.And maybe it could be slip/skid-ball driven ... my whole
>>> point is NOT to disable it but make it configurable.
>>
>> Currently the rudder is set to 0.5 * aileron if autocoordination is
>> enabled. The value of 0.5 is hardcoded.
>> An easy and portable way to implement your request might be to introduce
>> a new property (e.g. /sim/auto-coordination-factor) with the default
>> value of 0.5. and change the code
>> if ( auto_coordination->getBoolValue() ) {
>> set_rudder( aileron / 2.0 );
>> }
>>
>> to
>>
>> if ( auto_coordination->getBoolValue()
>> && auto_coordination_factor->getDoubleValue()> 0.0 ) {
>> set_rudder( aileron * auto_coordination_factor->getDoubleValue() );
>> }
>>
>> so that setting /sim/auto-coordination-factor to a value of zero or less
>> disables the hardcoded auto-coordination but leaves the command-line
>> argument and the enable-property usable.
>>
>> Torsten
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Virtualization& Cloud Management Using Capacity Planning
>> Cloud computing makes use of virtualization - but cloud computing
>> also focuses on allowing computing to be delivered as a service.
>> http://www.accelacomm.com/jaw/sfnl/114/51521223/
>> _______________________________________________
>> Flightgear-devel mailing list
>> Flightgear-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
> ------------------------------------------------------------------------------
> Virtualization& Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
>
------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
