Re: [Flightgear-devel] Linking order problems?

2005-06-26 Thread James Turner
On 27 Jun 2005, at 02:20, Jon Berndt wrote:I've got the basic build procedure figured out (I think) with the new JSBSim code in FlightGear. However, once it gets to the Big Link, it ultimately fails. Here's the link line: I think the problem here is ordering of static libs - I assume the various JSBsim sub-libs, eg 'jsbsim/models/libModels.a', all rely on symbols from the core JSBsim lib, jsbsim/libJSBSim.a. However, libJSBSim.a is listed before them in the link order. GCC has the behaviour, when linking static libraries, of using the static library to resolve all currently un-defined symbols in the current code, and then discarding all remaining symbols from the static lib. If a later library in the link line then needs one of those symbols, it will not be found.So, in summary, the solution is to edit your Makefile so libJSBSim is linked after all the other JSBSim libs, and you may have to further tweak the order to get everything to come out right.Hope this helps,JamesPS - I used to wonder why GCC's linker doesn't do what most people expect, which would be to retain the entire static lib in memory until the complete link is finished, and only then discard un-used symbols. I believe the reason for the actual behaviour is to do with keeping the linker a single-pass system, with less drastic memory requirements. -- Morbo finds all humans pathetic  ___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

[Flightgear-devel] About 3D Clouds

2005-06-26 Thread Ampere K. Hardraade
After removing Xorg and upgrading XFree to the latest CVS version, I am 
finally able to use FlightGear in 24-bits color.  However, I am still not 
seeing any 3D clouds.

I have an ATI Radeon 9200SE graphic card.  I remember 3D Clouds was working 
fine when it (the code for the new 3D Clouds) was first added the code to the 
CVS.  I haven't been able to get the 3D clouds to show up in subsequent 
updates.

What am I missing?

Thanks in advance,
Ampere

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


[Flightgear-devel] ..multi-X trick ideas, was: FlightGear got killed (seems like memory problem)

2005-06-26 Thread Arnt Karlsen
On Sun, 26 Jun 2005 20:28:04 -0400, Ampere wrote in message 
<[EMAIL PROTECTED]>:

> Hello,
> 
> I uninstalled Xorg and went back to XFree today so I could do some
> testing  with XFree and the latest FlightGear CVS. 

..a tad drastic, for FG development, you could simply set up two
runlevels, say runlevel 2 to run xorg and runlevel 3 to run XFree, 
these 2 runlevels could othervise be identical.  

..to push this further, you could also use runlevel 4 to run both at the
same time, say xorg on /dev/tty7 as :0 and XFree on /dev/tty8 as :1,
hopping between them is then [ctrl]+[alt]+[F7] and [ctrl]+[alt]+[F8].
Etc.

-- 
..med vennlig hilsen = with Kind Regards from Arnt... ;o)
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Shadows

2005-06-26 Thread Lee Elliott
On Sunday 26 Jun 2005 23:03, Vivian Meazza wrote:
> Frederic Bouvier
>
> > Vivian Meazza a écrit :
> > >I've just seen the new volumetric shadows. Brilliant!!! On
> > > a Nvidia
> >
> > gForce
> >
> > >5200, the frame rate hit is about 10 in external view (I
> > > can live with
> >
> > it)
> >
> > >and no noticeable effect in internal - perhaps 1 or 2.
> >
> > Yes, it is very nice. I have a drop of 10 fps ( 50 -> 40 )
> > when I enable all ( ac + ai + to )
> >
> > >There's a bit of a funny with the interaction between the
> > > Hurricane propeller disk and the ac shadow: it makes the
> > > shadow disappear, and
> >
> > there's
> >
> > >something throwing a shadow on to the disk, which I've not
> > > seen in real life, although I might not have noticed it.
> > > Is there anything I can do within the ac model to tidy
> > > this up?
> >
> > 2 stranges things that I know are inherent to the shadow
> > volume technique
> >
> > 1. even when surfaces are smoothed, the shadows are hard and
> > apply to a whole quad when a fuselage shadows itself ( try
> > the A320, look at the airframe and press t to see what I
> > mean ).
> > 2. transparent surfaces ( the suspension chains of the
> > bridges, or the metallic structures ) produce filled
> > shadows.
>
> Yes, I can see that. The markings on the Hunter are on
> separate transparent object: these throw a shadow. It seems as
> if I'm going to abandon that method if shadows are to be
> usable with that model. Pity; it saves a huge amount of
> artwork and texture. The edges of the shadows are a bit too
> hard; a little penumbra would be good
>
> > Let wait the hardware to catch up a hit, and we could have
> > clouds and mountains casting shadows ;-)
>
> Nice if aircraft could throw shadow on cloud.
>
> Altogether it's a nice enhancement.
>
> V.

Yep - I've used the same texturing technique on a few a/c as 
well:(  Then again, I've already stopped using it:)  It did save 
a lot of texture space though.

Re the 1st problem Fred referred to, it seems to happen when an 
object puts itself in shadow.  Shadows cast by other objects 
seem to be ok.  Generally, the old shading code did a good 
enough job of shading each individual object in a model, 
according to the sun pos, so I wonder if the new shadows might 
work better if they were only applied to other objects, and let 
the old code shade each individual object...

LeeE

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


[Flightgear-devel] Linking order problems?

2005-06-26 Thread Jon Berndt
I've got the basic build procedure figured out (I think) with the new JSBSim 
code in
FlightGear. However, once it gets to the Big Link, it ultimately fails. Here's 
the link
line:

--- start ---

g++ -DPKGLIBDIR=\"/usr/local/share/FlightGear\" -g -O2 -D_REENTRANT
-L/usr/local/lib -o fgfs.exe  bootstrap.o ../../src/Main/libMain.a
../../src/Aircraft/libAircraft.a ../../src/ATC/libATC.a
../../src/Cockpit/libCockpit.a ../../src/Cockpit/built_in/libBuilt_in.a
../../src/Controls/libControls.a ../../src/FDM/libFlight.a
../../src/FDM/Balloon/libBalloon.a ../../src/FDM/ExternalNet/libExternalNet.a
../../src/FDM/ExternalPipe/libExternalPipe.a
../../src/fdm/jsbsim/libJSBSim.a
../../src/fdm/jsbsim/initialization/libInit.a
../../src/fdm/jsbsim/input_output/libInputOutput.a
../../src/fdm/jsbsim/math/libMath.a
../../src/fdm/jsbsim/models/atmosphere/libAtmosphere.a
../../src/fdm/jsbsim/models/flight_control/libFlightControl.a
../../src/fdm/jsbsim/models/libModels.a
../../src/fdm/jsbsim/models/propulsion/libPropulsion.a
../../src/FDM/YASim/libYASim.a ../../src/FDM/LaRCsim/libLaRCsim.a
../../src/FDM/UIUCModel/libUIUCModel.a ../../src/FDM/SP/libSPFDM.a
../../src/GUI/libGUI.a ../../src/Autopilot/libAutopilot.a
../../src/Input/libInput.a ../../src/Instrumentation/libInstrumentation.a
../../src/Model/libModel.a ../../src/AIModel/libAIModel.a
../../src/Network/libNetwork.a ../../src/Navaids/libNavaids.a
../../src/Scenery/libScenery.a ../../src/Scripting/libScripting.a
../../src/Sound/libSound.a ../../src/Airports/libAirports.a
../../src/MultiPlayer/libMultiPlayer.a ../../src/Replay/libReplay.a
../../src/Systems/libSystems.a ../../src/Time/libTime.a
../../src/Traffic/libTraffic.a ../../src/Environment/libEnvironment.a  -
lsgroute -lsgsky -lsgsound -lsgephem -lsgmaterial -lsgtgdb -lsgmodel -
lsgtiming -lsgio -lsgscreen -lsgmath -lsgbucket -lsgprops -lsgdebug -lsgmagvar
-lsgmisc -lsgnasal -lsgxml -lsgsound -lsgserial -lsgstructure -lsgenvironment
-lsgthreads  -lplibpu -lplibfnt -lplibjs -lplibnet -lplibssg -lplibsg -lplibul
-lz -lglut32 -lglu32 -lopengl32 -luser32 -lgdi32 -lALut -lopenal32   -lwinmm -
ldsound -ldxguid -lole32

--- end ---

I don't think I see a problem with this line, but, immediately after this line 
I start
getting pages of errors.

--- start ---

../../src/fdm/jsbsim/models/libModels.a(FGFCS.o): In function
`_ZN6JSBSim5FGFCS4LoadEPNS_7ElementE':
/usr/include/c++/3.3.3/bits/stl_vector.h:596: undefined reference to
`JSBSim::FGFilter::FGFilter[in-charge](JSBSim::FGFCS*, JSBSim::Element*)'
/usr/include/c++/3.3.3/bits/stl_vector.h:596: undefined reference to
`JSBSim::FGGain::FGGain[in-charge](JSBSim::FGFCS*, JSBSim::Element*)'
/usr/include/c++/3.3.3/bits/stl_vector.h:596: undefined reference to
`JSBSim::FGSummer::FGSummer[in-charge](JSBSim::FGFCS*, JSBSim::Element*)'
/usr/include/c++/3.3.3/bits/stl_vector.h:596: undefined reference to
`JSBSim::FGDeadBand::FGDeadBand[in-charge](JSBSim::FGFCS*, JSBSim::Element*)'
/usr/include/c++/3.3.3/bits/stl_vector.h:596: undefined reference to
`JSBSim::FGGradient::FGGradient[in-charge](JSBSim::FGFCS*, JSBSim::Element*)'
/usr/include/c++/3.3.3/bits/stl_vector.h:596: undefined reference to
`JSBSim::FGSwitch::FGSwitch[in-charge](JSBSim::FGFCS*, JSBSim::Element*)'
/usr/include/c++/3.3.3/bits/stl_vector.h:596: undefined reference to
`JSBSim::FGKinemat::FGKinemat[in-charge](JSBSim::FGFCS*, JSBSim::Element*)'
/usr/include/c++/3.3.3/bits/stl_vector.h:596: undefined reference to
`JSBSim::FGFCSFunction::FGFCSFunction[in-charge](JSBSim::FGFCS*, 
JSBSim::Element*)'
../../src/fdm/jsbsim/models/libModels.a(FGOutput.o): In function
`_ZN6JSBSim8FGOutputD2Ev':
/usr/include/c++/3.3.3/bits/stl_alloc.h:656: undefined reference to
`JSBSim::FGfdmSocket::~FGfdmSocket [in-charge]()'
../../src/fdm/jsbsim/models/libModels.a(FGOutput.o): In function
`_ZN6JSBSim8FGOutputD1Ev':
/usr/include/c++/3.3.3/bits/stl_alloc.h:656: undefined reference to
`JSBSim::FGfdmSocket::~FGfdmSocket [in-charge]()'
../../src/fdm/jsbsim/models/libModels.a(FGOutput.o): In function
`_ZN6JSBSim8FGOutputD0Ev':
/usr/include/c++/3.3.3/bits/stl_alloc.h:656: undefined reference to
`JSBSim::FGfdmSocket::~FGfdmSocket [in-charge]()'
../../src/fdm/jsbsim/models/libModels.a(FGOutput.o): In function
`_ZN6JSBSim8FGOutput12SocketOutputEv':
/home/jon/src/FlightGear/src/FDM/JSBSim/models/FGOutput.cpp:341: undefined 
reference to
`JSBSim::FGfdmSocket::Clear()'
../../src/fdm/jsbsim/models/libModels.a(FGOutput.o): In function
`_ZN6JSBSim8FGOutput12SocketOutputEv':
/usr/include/c++/3.3.3/bits/stl_alloc.h:652: undefined reference to
`JSBSim::FGfdmSocket::Clear(std::basic_string,
std::allocator >)'
../../src/fdm/jsbsim/models/libModels.a(FGOutput.o): In function
`_ZN6JSBSim8FGOutput12SocketOutputEv':
/home/jon/src/FlightGear/src/FDM/JSBSim/models/FGOutput.cpp:344: undefined 
reference to
`JSBSim::FGfdmSocket::Append(char const*)'
...
...
...
etc.

--- end ---

Any suggestions on what might be wrong and/or how to fix this would be much 
appreciated -
it wo

[Flightgear-devel] FlightGear got killed (seems like memory problem)

2005-06-26 Thread Ampere K. Hardraade
Hello,

I uninstalled Xorg and went back to XFree today so I could do some testing 
with XFree and the latest FlightGear CVS.  I got the following outputs from 
FlightGear:

RenderTexture Error: Couldn't find a suitable pixel format.
WARNING: ssgLoadAC: Failed to open 
'/usr/local/FlightGear/share/FlightGear/Aircraft/c172r/Models/c172-dpm.ac' 
for reading
WARNING: ssgLoadAC: Failed to open 
'/usr/local/FlightGear/share/FlightGear/Aircraft/pa28-161/Models/pa28-161.ac' 
for reading
Killed
^

From what I can tell, there seems to be some memory management problems.  
FlightGear first slows down at an exponential rate, then freeze, and finally 
got shut down by the Operating System.

I am using Debian Linux.
[EMAIL PROTECTED]:~$ uname -a
Linux localhost 2.6.10 #1 Wed Jun 15 04:47:56 EDT 2005 i686 GNU/Linux
...with XFree86 4.3.0

Graphic card: ATI 9200SE (PCI version)



Ampere

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Shadows

2005-06-26 Thread Vivian Meazza
Frederic Bouvier

> Vivian Meazza a écrit :
> 
> >I've just seen the new volumetric shadows. Brilliant!!! On a Nvidia
> gForce
> >5200, the frame rate hit is about 10 in external view (I can live with
> it)
> >and no noticeable effect in internal - perhaps 1 or 2.
> >
> >
> Yes, it is very nice. I have a drop of 10 fps ( 50 -> 40 ) when I enable
> all ( ac + ai + to )
> 
> >There's a bit of a funny with the interaction between the Hurricane
> >propeller disk and the ac shadow: it makes the shadow disappear, and
> there's
> >something throwing a shadow on to the disk, which I've not seen in real
> >life, although I might not have noticed it. Is there anything I can do
> >within the ac model to tidy this up?
> >
> >
> 
> 2 stranges things that I know are inherent to the shadow volume technique
> :
> 1. even when surfaces are smoothed, the shadows are hard and apply to a
> whole quad when a fuselage shadows itself ( try the A320, look at the
> airframe and press t to see what I mean ).
> 2. transparent surfaces ( the suspension chains of the bridges, or the
> metallic structures ) produce filled shadows.

Yes, I can see that. The markings on the Hunter are on separate transparent
object: these throw a shadow. It seems as if I'm going to abandon that
method if shadows are to be usable with that model. Pity; it saves a huge
amount of artwork and texture. The edges of the shadows are a bit too hard;
a little penumbra would be good 
 
> Let wait the hardware to catch up a hit, and we could have clouds and
> mountains casting shadows ;-)

Nice if aircraft could throw shadow on cloud.

Altogether it's a nice enhancement.

V.







___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Shadows

2005-06-26 Thread Lee Elliott
On Sunday 26 Jun 2005 21:53, Frederic Bouvier wrote:
> Vivian Meazza a écrit :
> >I've just seen the new volumetric shadows. Brilliant!!! On a
> > Nvidia gForce 5200, the frame rate hit is about 10 in
> > external view (I can live with it) and no noticeable effect
> > in internal - perhaps 1 or 2.
>
> Yes, it is very nice. I have a drop of 10 fps ( 50 -> 40 )
> when I enable all ( ac + ai + to )
>
> >There's a bit of a funny with the interaction between the
> > Hurricane propeller disk and the ac shadow: it makes the
> > shadow disappear, and there's something throwing a shadow on
> > to the disk, which I've not seen in real life, although I
> > might not have noticed it. Is there anything I can do within
> > the ac model to tidy this up?
>
> 2 stranges things that I know are inherent to the shadow
> volume technique : 1. even when surfaces are smoothed, the
> shadows are hard and apply to a whole quad when a fuselage
> shadows itself ( try the A320, look at the airframe and press
> t to see what I mean ).
> 2. transparent surfaces ( the suspension chains of the
> bridges, or the metallic structures ) produce filled shadows.
>
> Let wait the hardware to catch up a hit, and we could have
> clouds and mountains casting shadows ;-)
>
> Good job again.
> -Fred

Yes, very nice work.  I notice a little frame-rate drop but not 
as much as I expected (nVidia 6600 based card).

I noticed problems with prop disks too.  I'm fading both the 
props and prop disks in and out, depending on their rpm and even 
when the prop disk is completely faded out a shadow from the 
spinners is cast on them.  As the disks are faded in the shadow 
density upon the prop disk seems to remain constant.

I imagine that varying the shadow density based on the alpha 
channel of the texture of the object that the shadow is cast 
upon would not be trivial.

I also noticed that the props, before being faded out, also cast 
a shadow upon the still faded out prop disks but don't once 
they're de-selected.

I noticed a few 'artifacts' in the shadows cast upon the aircraft 
itself but I think most of these were due to tiny irregularities 
in the model geometry that are normally not noticed due to 
smoothing i.e. tiny concavities in the model which may not be 
obvious but which cast shadows.  The shadow of the tailfin 
moving across the tailplanes is fine though, as was the shadow 
of the wing trailing edge upon the partially deployed flaps.

I don't think I've seen the problem Fred reported of entire quads 
being shadowed incorrectly  (hmm - Fred, are you referring to 
four-sided polys here?  Any polys with > 3 sides appear to be 
triangulated before rendering.

LeeE

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Shadows

2005-06-26 Thread Frederic Bouvier

Vivian Meazza a écrit :


I've just seen the new volumetric shadows. Brilliant!!! On a Nvidia gForce
5200, the frame rate hit is about 10 in external view (I can live with it)
and no noticeable effect in internal - perhaps 1 or 2.  
 

Yes, it is very nice. I have a drop of 10 fps ( 50 -> 40 ) when I enable 
all ( ac + ai + to )



There's a bit of a funny with the interaction between the Hurricane
propeller disk and the ac shadow: it makes the shadow disappear, and there's
something throwing a shadow on to the disk, which I've not seen in real
life, although I might not have noticed it. Is there anything I can do
within the ac model to tidy this up?
 



2 stranges things that I know are inherent to the shadow volume technique :
1. even when surfaces are smoothed, the shadows are hard and apply to a 
whole quad when a fuselage shadows itself ( try the A320, look at the 
airframe and press t to see what I mean ).
2. transparent surfaces ( the suspension chains of the bridges, or the 
metallic structures ) produce filled shadows.


Let wait the hardware to catch up a hit, and we could have clouds and 
mountains casting shadows ;-)


Good job again.
-Fred



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Shadows

2005-06-26 Thread Vivian Meazza
Harald JOHNSEN

> Paul Kahler wrote:
> 
> >Oh does that sound like a bad hack. What happens to objects that have
> >specular highlights? Would the illumination be as if the sun were
> >shining rather than the spotlight? Lighting is important, but this
> >doesn't seem like it's physically correct at all. OTOH, fake lighting is
> >better than no lighting ;-)
> >
> >Paul
> >
> >
> >
> You are right, this is totaly incorrect lighting. For correct lighting
> and correct specular we should use an
> Opengl light for each light source. The problem is that opengl is sill
> slow for spot lights, and there can be
> more than 100 light around an airport. Of course opengl can not handle
> more than 8 lights in hardware
> (and I am not sure that it is still realtime on lot of machines) so we
> would have to switch ogl lights
> depending on the position of objects or ground geometry... a bit
> overkill I think.
> Perhaps can we use a real ogl light for the aircraft landing light and
> fake light for the airport lights,
> and since the view is centered on the aircraft the hack could be good
> enought.
> 

I've just seen the new volumetric shadows. Brilliant!!! On a Nvidia gForce
5200, the frame rate hit is about 10 in external view (I can live with it)
and no noticeable effect in internal - perhaps 1 or 2.  

There's a bit of a funny with the interaction between the Hurricane
propeller disk and the ac shadow: it makes the shadow disappear, and there's
something throwing a shadow on to the disk, which I've not seen in real
life, although I might not have noticed it. Is there anything I can do
within the ac model to tidy this up?

It would be nice to assign 2 of the 8 OpenGL lights to ac landing lights.

Well done indeed

Vivian



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


[Flightgear-devel] Makefile.am and new JSBSim files

2005-06-26 Thread Jon Berndt
I'm working on getting the new JSBSim code into FlightGear. It's going pretty 
well,
actually, but I still have one problem. I can't seem to get JSBSim.cxx to 
compile in the
JSBSim directory. It wants to use JSBSim.cpp - which isn't there. My new 
Makefile.am looks
like this:

--- start ---

SUBDIRS = initialization models input_output math

noinst_LIBRARIES = libJSBSim.a

libJSBSim_a_SOURCES =  JSBSim.cxx FGFDMExec.cpp FGJSBBase.cpp FGState.cpp

INCLUDES = -I$(top_srcdir)/src/FDM/JSBSim

AM_CXXFLAGS = -DFGFS

--- end ---

Am I leaving something out? The problem seems to be somehow with the .cxx 
extension.

Jon


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Turn Coordinator is out ==> c172r and others

2005-06-26 Thread Roy Vegard Ovesen
On Sunday 26 June 2005 16:36, Gerard Robin wrote:
> > It's the new nasalised electrical system. The turn indicator is hardcoded
> > to expect 60 ampere as input. The new system outputs 28 volts instead (I
> > told Curt that it made more sense to output volts rather than amperes).
> > So the result is that the gyro is not spinning fast enough.
> >
> > I tried the radiostack just now, and it seemed to work fine.
>
>  Well, what must be done to solve that ?

Short term ugly hack:

--- c172-electrical.nas 14 Jun 2005 21:31:13 -  1.2
+++ c172-electrical.nas 26 Jun 2005 16:01:25 -
@@ -111,7 +111,7 @@ AlternatorClass.new = func {
 obj = { parents : [AlternatorClass],
 rpm_source : "/engines/engine[0]/rpm",
 rpm_threshold : 600.0,
-ideal_volts : 28.0,
+ideal_volts : 60.0,
 ideal_amps : 60.0 };
 setprop( obj.rpm_source, 0.0 );
 return obj;



-- 
Roy Vegard Ovesen

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Turn Coordinator is out ==> c172r and others

2005-06-26 Thread Gerard Robin
Le dimanche 26 juin 2005 à 07:53 +0200, Roy Vegard Ovesen a écrit :
> On Sunday 26 June 2005 04:04, Ampere K. Hardraade wrote:
> > I notice it as well, but I thought my CVS version is outdated, so I didn't
> > mention it.
> >
> > Beside the turn coordinator, everything on the radio stack seems to be out
> > as well.
> 
> It's the new nasalised electrical system. The turn indicator is hardcoded to 
> expect 60 ampere as input. The new system outputs 28 volts instead (I told 
> Curt that it made more sense to output volts rather than amperes). So the 
> result is that the gyro is not spinning fast enough.
> 
> I tried the radiostack just now, and it seemed to work fine.
> 


 Well, what must be done to solve that ?

thanks
-- 
Gerard


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d