On Sun, 2003-03-30 at 20:05, Michael Selig wrote:
> At 3/30/03, you wrote:
> >Michael Selig writes:
> >
> > > I noticed the 'squared' effect when I started flying w/ my R/C
> > > joysticks. Using the actual joysticks exactly models what an R/C
> > > pilot feels, so no exponent fudging is desired in that case. Also,
> > > exponential rates and mixing if used are done onboard the R/C
> > > transmitter, so again nothing needs to be done on the fgfs side.
> >
> >Great. Under our current system, the 'power' property is not applied
> >by default -- it has to be specified separately for each axis in each
> >joystick-specific config file, so there should be no problem leaving
> >it out for your R/C joysticks.
>
> That's what I've done. That R/C joystick file is committed.
>
>
> > > In special cases (e.g. some airplanes in the current fgfs hanger),
> > > suppose one wanted to change a property that is set in the specific
> > > base package joystick file (or any other xml file). Can the
> > > related tags be added to the -set.xml file with the effect of
> > > over-riding the previous values? There have been instances where I
> > > have wanted to do this, but I don't think it worked.
> >
> >It's doable, but complicated. Let me know what you're thinking of.
>
> Things that I would like to over-ride and post to the fgfs cvs for flying
> the uiuc airplanes (and new ones coming):
>
> [1] I'd like to add keyboard customization that would work w/ the ASW-20.
> Spoilers working w/ j/k keys:
>
> <key n="106">
> <name>j</name>
> <desc>Decrease spoilers.</desc>
> <binding>
> <command>property-adjust</command>
> <property>/controls/spoilers</property>
> <min>0</min>
> <step type="double">-0.25</step>
> </binding>
> </key>
>
> <key n="107">
> <name>k</name>
> <desc>Increase spoilers.</desc>
> <binding>
> <command>property-adjust</command>
> <property>/controls/spoilers</property>
> <max>1</max>
> <step type="double">0.25</step>
> </binding>
> </key>
>
> [2] In preferences.xml, I have changed 'eye-heading-deg-path' per below.
> The LaRCsim/UIUC code computes this value. The advantage is that in the
> second view, the view direction is in the direction of the airplane
> ("Gamma" horizontal in effect). The result is that when rudder is applied,
> the airplane will yaw, but the view direction will not. It is a much more
> natural way to see the airplane and tendency for vertigo is greatly reduced
> when things are unsteady. With the ASW-20 landing w/ sideslip
> (cross-controls), the 2nd view is down the runway w/ the airplane in a big
> sideslip.
>
> <!-- view 2 -->
> <view>
> <name>Chase View</name>
> <type>lookat</type>
> <config>
> <from-model type="bool">false</from-model>
> <from-model-idx type="int">0</from-model-idx>
> <eye-lat-deg-path>/position/latitude-deg</eye-lat-deg-path>
> <eye-lon-deg-path>/position/longitude-deg</eye-lon-deg-path>
> <eye-alt-ft-path>/position/altitude-ft</eye-alt-ft-path>
> <eye-heading-deg-path>/orientation/Gamma_horiz_deg</eye-heading-deg-path>
>
> Frankly, I think this should be applied w/ all FDMs, but JSBSim and YASim
> will need to compute Gamma_horiz_deg first.
Flight path angle is computed by JSBSim. It's probably not passed to FG, however.
I am referring to the "flight path angle" in the horizontal plane, not the flight path angle proper (in the vertical plane). I'm not sure if that was clear. Does JSBSim compute the "flight path angle" in the horizontal plane?
The file preferences.xml currently has: <eye-heading-deg-path>/orientation/heading-deg</eye-heading-deg-path>. This causes the view to sway back and forth w/ yaw.
Regards, Michael
_______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
