flightgear-devel

[Flightgear-devel] compilation pb: error: 'const class osg::Viewport' has no member named 'getViewport'

[<seb...@fr...>]

hi all,

I've compiled flightgear and OSG with no problem until three days...
actually the last time was two weeks ago...

but now I get this error:

if g++ -DHAVE_CONFIG_H -I.
-I/home/moi/scripts/fgfs-builder/src/FlightGear/src/Model
-I../../src/Include -I/home/moi/scripts/fgfs-builder/src/FlightGear
-I/home/moi/scripts/fgfs-builder/src/FlightGear/src
-I/home/moi/scripts/fgfs-builder/install/include -I/usr/X11R6/include
-I/usr/local/include  -g -O2 -D_REENTRANT -MT panelnode.o -MD -MP -MF
".deps/panelnode.Tpo" -c -o panelnode.o
/home/moi/scripts/fgfs-builder/src/FlightGear/src/Model/panelnode.cxx; \
         then mv -f ".deps/panelnode.Tpo" ".deps/panelnode.Po"; else rm
-f ".deps/panelnode.Tpo"; exit 1; fi
/home/moi/scripts/fgfs-builder/src/FlightGear/src/Model/panelnode.cxx:
In member function 'virtual void
FGPanelNode::drawImplementation(osg::State&) const':
/home/moi/scripts/fgfs-builder/src/FlightGear/src/Model/panelnode.cxx:135:
error: 'const class osg::Viewport' has no member named 'getViewport'


greping in /home/moi/scripts/fgfs-builder/install/include reports me:

./osg/Camera:92:const Viewport* getViewport() const { return
_viewport.get(); }
./osg/Camera:95:Viewport* getViewport() { return _viewport.get(); }
./osg/CullStack:132: inline osg::Viewport* getViewport();
./osg/CullStack:207:inline osg::Viewport* CullStack::getViewport()
./osg/Viewport:76: void getViewport(int& x,int& y,int& width,int&
height) const
./osg/Viewport:84:void getViewport(double& x,double& y,double&
width,double& height) const
./osgUtil/RenderStage:72:const osg::Viewport* getViewport() const {
return _viewport.get(); }
./osgUtil/RenderStage:75:osg::Viewport* getViewport() { return
_viewport.get(); }
./osgUtil/SceneView:97:osg::Viewport* getViewport() { return
(_camera->getViewport()!=0) ?_camera->getViewport() : 0; }
./osgUtil/SceneView:100:const osg::Viewport* getViewport() const {
return (_camera->getViewport()!=0) ? _camera->getViewport() : 0; }

I use fgfs-builder (rev29) to build. I've copied
/home/moi/scripts/fgfs-builder/install/include/* in /usr/local/include,
just to make a try, with no better result.
The config.log of FlightGear doesn't seem to report errors...
I use the last CVS and svn versions. I googled about "getViewport" with
no relevant solutions (imho)...
OpenProducer, OpenSceneGraph, OpenThreads, plib and Simgear compilations
are ok.

does one of you know what I've missed?

thanks
regards,

seb

Re: [Flightgear-devel] compilation pb: error: 'const class osg::Viewport' has no member named 'getViewport'

[Manuel M. <m.m...@wa...>]

S=E9bastien,

I posted a compilation fix yesterday, see
http://sourceforge.net/mailarchive/message.php?msg_id=3D37837809

bye,
	Manuel

Re: [Flightgear-devel] compilation pb: error: 'const class osg::Viewport' has no member named 'getViewport'

[<seb...@fr...>]

thank you very much Manuel, it compiles perfectly now.

regards

Manuel Massing a =E9crit :
> S=E9bastien,
>=20
> I posted a compilation fix yesterday, see
> http://sourceforge.net/mailarchive/message.php?msg_id=3D37837809
>=20
> bye,
> 	Manuel
>=20
> -----------------------------------------------------------------------=
--
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share=
 your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV
> _______________________________________________
> Flightgear-devel mailing list
> Fli...@li...
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>=20
>=20

[Flightgear-devel] memory leak

[John D. <sf...@av...>]

My version of fgfs has a rather large memory leak.

If I leave the thing parked after a flight, brakes on,
simulator paused, it will gobble up about 3 gigabytes
of virtual memory overnight.  (In contrast, it's only
a little over 500 meg after a few minutes of flight.)

I'm running the version of fgfs that is bundled with the
current Debian "etch" distribution.  The fgfs binary is
dated May 17 2006 if that means anything.  I'm using it
with the /data/ from cvs.

[Flightgear-devel] ? cockpit lighting ?

[John D. <sf...@av...>]

I have been unable to find any way to turn on cockpit area lighting.

I found nothing on the subject in the documentation.

I tried looking around in the c172 and c182 aircraft models and
didn't find anything.

I tried fiddling with some of the suggestively-named variables
without success.

Is it possible that the aircraft models do not (yet) implement
this feature?

It is kinda hard to fly the aircraft properly with no lighting.
For example, good pilot procedure calls for checking the position
of the flaps on occasion ... and you can't do that if it's too
dark to see the knobs and indicators.

So ... what's the status?  Where do we go from here?

Re: [Flightgear-devel] ? cockpit lighting ?

[Dave P. <ski...@mi...>]

On Sun, 2007-01-07 at 20:11 -0500, John Denker wrote:
> I have been unable to find any way to turn on cockpit area lighting.
> 
> I found nothing on the subject in the documentation.
> 
> I tried looking around in the c172 and c182 aircraft models and
> didn't find anything.

Hi John,
Try the pa24-250 at night.  I used material animation to accomplish
this.  Even in the real AC, the instrument light and nav lights are on
the same switch.  The "aircraft help" give you keyboard bindings for the
switches as well as starting instructions (or just click on the
switches).

Really like your "location-in-air" xml so far.  I used the offset from a
fix, even a fix several hundred miles distant successfully.  I have not
been able to do the same with a VOR.  Works sometimes, but not others.

Regards,
Dave
-- 
Dave Perry <ski...@mi...>

Re: [Flightgear-devel] ? cockpit lighting ?

[Stuart B. <stu...@ya...>]

--- John Denker wrote:
> I have been unable to find any way to turn on cockpit area lighting.
> 
> I found nothing on the subject in the documentation.
> 
> I tried looking around in the c172 and c182 aircraft models and
> didn't find anything.
> 
> I tried fiddling with some of the suggestively-named variables
> without success.
> 
> Is it possible that the aircraft models do not (yet) implement
> this feature?

To give a quick bit of background, I believe OpenGL limitations mean that
we cannot just stuff a light-source into the cockpit for this.

Also, as you've probably already realized, this is a per-aircraft model
issue, so it is up to the aircraft maintainer and any contributers to
implement.

Some models are quite advanced - the SenecaII and pa24-250 in particular
have detailed cockpits in the GA fleet.

However, some of the aircraft are a bit behind the times and have only
rudimentary 3-D cockpits.

I am the maintainer of the c182 and c310, which suffers from this in
particular.

Are you particularly interested in using the c182?

If so, I'll spend some time this evenign adding some lighting.

I have never actually been in one, let alone at night, so could you answer
a couple of questions for me:

1) Presumably the panel itself is lit from behind as it is implemented
currently. Is that correct?

2) Do you have any reference for where the nav, panel, landling light
switches are located in the c182?

3) Am I correct in thinking that any light to see the flaps, yoke etc is a
reflection of the panel light, and therefore very low intensity? The
easiest way to implement this will be with a low-intensity emissive light
source on the objects.

4) Is the flap indicator illuminated from behind like the instruments, or
does it also rely on the panel light reflection?

BTW, you should be aware that we currently don't have any landing light
implementation, so I guess landing at night will be quite unrealistic.

Finally, you are of course welcome to implement this yourself - the model
readme should provide enough information to get you started.

-Stuart


Send instant messages to your online friends http://uk.messenger.yahoo.com 

Re: [Flightgear-devel] ? cockpit lighting ?

[Torsten D. <to...@t3...>]

Hi Stuart
> I have never actually been in one, let alone at night, so could you answer
> a couple of questions for me:
You definitely missed something in life, especially at night ;-) 
>
> 1) Presumably the panel itself is lit from behind as it is implemented
> currently. Is that correct?
here http://commons.wikimedia.org/wiki/Image:Cessna_182_P_Skylane_Cockpit.jpg 
is a cockpit photo. At the artificial horizon for example are two round 
knobs: the black one below is for adjusting the horizon symbol and the 
metal-like one above is the instrument light, that illuminates the 
instruments from outside. There is one on the top left corner of the airspeed 
indicator (top left instrument), too. On can see the notch where the light 
comes out. Looks like every round instrument has such a light source. The 
engine instruments are backlit.
>
> 2) Do you have any reference for where the nav, panel, landling light
> switches are located in the c182?
>
> 3) Am I correct in thinking that any light to see the flaps, yoke etc is a
> reflection of the panel light, and therefore very low intensity? The
> easiest way to implement this will be with a low-intensity emissive light
> source on the objects.
Correct
>
> 4) Is the flap indicator illuminated from behind like the instruments, or
> does it also rely on the panel light reflection?
No internal light, it's just seen by panel and cockpit light reflection.

Martin is a skilled skylane pilot, maybe he has some nice cockpit photos to 
share?

Greetings, Torsten

[Flightgear-devel] C182 creeping features

[John D. <sf...@av...>]

On 01/08/2007 10:06 AM, Stuart Buchanan wrote:

> Are you particularly interested in using the c182?

Well, yes I am.  A lot of FBOs will let you rent a 182.  If we make
an XY plot trading off availability versus a combination of speed
and roominess, the 182 has high availability for a given niceness,
and high niceness for a given availability.

Also the 182 RG is one of the two aircraft most-commonly used for
transition training, as pilots transition to "complex aircraft".

> If so, I'll spend some time this evenign adding some lighting.

:-)

> you are of course welcome to implement this yourself - the model
> readme should provide enough information to get you started.

Maybe we should work together.

If you enjoy working on models, there's lots of things that could
be done to kick the realism up a notch.  I've been keeping a list
of nitpicks, creeping features, and other notes at
  http://www.av8n.com/fly/fgfs/c182.notes

> I have never actually been in one, let alone at night, so could you answer
> a couple of questions for me:
> 
> 1) Presumably the panel itself is lit from behind as it is implemented
> currently. Is that correct?

It's more complicated than that.
 -- There is "area lighting" including a white dome light and a red
  dome light.  This is useful for e.g. looking at the position of
  the flap handle, landing gear handle, fuel selector, and other things
  that are not well covered by the post lights.  (Also in the real world,
  not in the model, this would be critical for map-reading.)
 -- Radios are internally lighted.  Either they have glowing LED segments,
  or LCDs with a backlight, or something similar.
 -- There is a class of instruments unlovingly referred to as "steam
  gauges" including the airspeed indicator, altimeter, VSI, et cetera.
  These are lighted from the front by "post lights", i.e. little posts
  that stick out from the front of the panel and shine light back onto
  the front of the panel.  (Modeling the post lights would require a
  ton of detail work.  It may be expedient to do a better-than-realistic
  job of area lighting so as to make post lights unnecessary.)
 -- I have a light attached to my headset, which I can turn on as needed,
  so that wherever I turn my head gets lit up.  Also any pilot who flies
  at night has a flashlight, typically dangling from a strap around his
  neck, as a backup for all the other lighting systems.  (I don't expect
  the model to capture this :-).


> 2) Do you have any reference for where the nav, panel, landling light
> switches are located in the c182?

Here's a nice shot of the panel
  http://www.linkscomputer.com/images/ebay/skydive/c182panel_06.jpg

A lot of the interesting switches are behind the horizontal part of
the pilot's yoke in that shot, i.e. in a row above the row of
circuit breakers.  That's a problem, because if the model puts the
switches in the realistic place, they will be very hard to see.

Other factoids: Just to the left of the lower-left corner of the
yoke you can see, left to right, the master switch and fuel boost
switch.  The magneto/start switch is next in line, hiding behind the
corner of the yoke.  Below the master you can see the primer knob.
Below the lower /left/ corner of the yoke is the gear handle.

On the pedestal beside the pilot's knee you can see elevator trim,
rudder trim, handheld mike, and cowl-flap lever.

I'd offer to scan the relevant POH page but it is no clearer than
the photo cited above.  I may need to take my camera to the airport.

> 3) Am I correct in thinking that any light to see the flaps, yoke etc is a
> reflection of the panel light, and therefore very low intensity? The
> easiest way to implement this will be with a low-intensity emissive light
> source on the objects.

There's also area lighting, coming from somewhere above the pilot's head.

> 4) Is the flap indicator illuminated from behind like the instruments, or
> does it also rely on the panel light reflection?

Area lighting.  The flap indicator doesn't have its own post lights or
anything.  Throttle/prop/mixture knobs are in this same category, and
the fuel-tank selector.

> BTW, you should be aware that we currently don't have any landing light
> implementation, so I guess landing at night will be quite unrealistic.

Well, yes, I noticed ... but landing without a landing light is not the
least bit unrealistic.  I put this near the bottom of the list at
  http://www.av8n.com/fly/fgfs/c182.notes

That stands in contrast to cockpit area lighting, which is near the top
of the list.  The contrast is odd, but I just call 'em like I see 'em.

Re: [Flightgear-devel] C182 creeping features

[Stuart B. <stu...@ya...>]

--- John Denker <sf...@av...> wrote:

> On 01/08/2007 10:06 AM, Stuart Buchanan wrote:
> 
> > Are you particularly interested in using the c182?
> 
> Well, yes I am.  A lot of FBOs will let you rent a 182.  If we make
> an XY plot trading off availability versus a combination of speed
> and roominess, the 182 has high availability for a given niceness,
> and high niceness for a given availability.

I agree it is a very common aircraft, and I find it a good choice for
doing instrument work. However, the reason I ask is that I don't know how
many other people fly the FG c182. 

<snip>

> If you enjoy working on models, there's lots of things that could
> be done to kick the realism up a notch.  I've been keeping a list
> of nitpicks, creeping features, and other notes at
>   http://www.av8n.com/fly/fgfs/c182.notes

Thanks. Having someone with RL experience of the aircraft is a big help. 

> > 
> > 1) Presumably the panel itself is lit from behind as it is implemented
> > currently. Is that correct?
> 
> It's more complicated than that.
>  -- There is "area lighting" including a white dome light and a red
>   dome light.  This is useful for e.g. looking at the position of
>   the flap handle, landing gear handle, fuel selector, and other things
>   that are not well covered by the post lights.  (Also in the real
> world,
>   not in the model, this would be critical for map-reading.)

OK - I'll probably leave this as a general emissive light. Where is the
switch located? On the ceiling?

>  -- Radios are internally lighted.  Either they have glowing LED
> segments,
>   or LCDs with a backlight, or something similar.
>  -- There is a class of instruments unlovingly referred to as "steam
>   gauges" including the airspeed indicator, altimeter, VSI, et cetera.
>   These are lighted from the front by "post lights", i.e. little posts
>   that stick out from the front of the panel and shine light back onto
>   the front of the panel.  (Modeling the post lights would require a
>   ton of detail work.  It may be expedient to do a better-than-realistic
>   job of area lighting so as to make post lights unnecessary.)

This is probably more hassle than it is worth right now. Currently the
c182 guages are emissive, which I think is sufficient. Where would the
switch for this be?

> > 2) Do you have any reference for where the nav, panel, landling light
> > switches are located in the c182?
> 
> Here's a nice shot of the panel
>   http://www.linkscomputer.com/images/ebay/skydive/c182panel_06.jpg

I can see the switches on the bottom right, and I think there are five,
reading from L-R:

NAV, BEACON, STROBE, TAXI, LANDING.

The problem is where the other light switches are located.

> A lot of the interesting switches are behind the horizontal part of
> the pilot's yoke in that shot, i.e. in a row above the row of
> circuit breakers.  That's a problem, because if the model puts the
> switches in the realistic place, they will be very hard to see.

The easiest way to solve this is to provide an option to make the yokes
invisible. As some people have their own CH Products Yokes, I think that
should be fine. 

<snip>
 
> > BTW, you should be aware that we currently don't have any landing
> light
> > implementation, so I guess landing at night will be quite unrealistic.
> 
> Well, yes, I noticed ... but landing without a landing light is not the
> least bit unrealistic.  I put this near the bottom of the list at
>   http://www.av8n.com/fly/fgfs/c182.notes

OK. I just thought I'd check that lack of landing lights would be a major
issue.

-Stuart

Send instant messages to your online friends http://uk.messenger.yahoo.com 

Send instant messages to your online friends http://uk.messenger.yahoo.com 

Re: [Flightgear-devel] C182 creeping features

[John D. <sf...@av...>]

On 01/08/2007 12:44 PM, Stuart Buchanan wrote:

> OK - I'll probably leave this as a general emissive light. Where is the
> switch located? On the ceiling?

Multiple switches.  Perhaps the most relevant to the model are the
two dimmer knobs (commonly but improperly called rheostats) located
just to port of the electrical rocker switches, just to starboard
and a little down from the magneto/start switch.  One of them
controls the post lights, while the other controls the internal
illumination in the radios.

The brightness and the red-versus-white of the dome light is
controlled overhead.  Not terribly convenient for the model.

A generic nondescript "area lighting" controlled by one of
the dimmer knobs would be just fine IMHO.

> I can see the switches on the bottom right, and I think there are five,
> reading from L-R:
> 
> NAV, BEACON, STROBE, TAXI, LANDING.

OK.

> The problem is where the other light switches are located.

I think we've covered all the important ones.


> The easiest way to solve this is to provide an option to make the yokes
> invisible. ... I think that should be fine. 

That sounds good.  It's expedient, and it solves the problem.
Maybe only 90% invisible, like Casper the ghost????

> As some people have their own CH Products Yokes, 

Or Saitek yokes.  I have a Saitek X52 (yoke and throttle) which has
8 axes and 33 switches.  Cheap and good enough.

And even for those who don't have hardware yokes, a keystroke to
make the yokes /temporarily/ invisible sounds like a fine solution,
especially in the short-to-medium term.

=======================

Don't take the following too seriously:

In the long term, I have fantasies about allowing the point of view
to change ... not just changing the tilt/pan/zoom from a fixed point,
but actually moving the pilot's *point* of view.  That would allow
peering around the yoke to see switches ... and perhaps more importantly,
it would allow moving the PoV to the side to peer around the cowling
to better see what's going on during landing.  I reckon this would be
a royal pain to implement, and inconvenient to use in practice, but it
would be the bees' knees in terms of realism.

Re: [Flightgear-devel] C182 creeping features

[Stuart B. <stu...@ya...>]

--- John Denker wrote:
> On 01/08/2007 12:44 PM, Stuart Buchanan wrote:
> 
> > OK - I'll probably leave this as a general emissive light. Where is
> the
> > switch located? On the ceiling?
> 
> Multiple switches.  Perhaps the most relevant to the model are the
> two dimmer knobs (commonly but improperly called rheostats) located
> just to port of the electrical rocker switches, just to starboard
> and a little down from the magneto/start switch.  One of them
> controls the post lights, while the other controls the internal
> illumination in the radios.

OK. I'll add a knob for dimming the general lights.

> The brightness and the red-versus-white of the dome light is
> controlled overhead.  Not terribly convenient for the model.
> 
> A generic nondescript "area lighting" controlled by one of
> the dimmer knobs would be just fine IMHO.

Will do.

> > The easiest way to solve this is to provide an option to make the
> yokes
> > invisible. ... I think that should be fine. 
> 
> That sounds good.  It's expedient, and it solves the problem.
> Maybe only 90% invisible, like Casper the ghost????

<snip>

> And even for those who don't have hardware yokes, a keystroke to
> make the yokes /temporarily/ invisible sounds like a fine solution,
> especially in the short-to-medium term.


It's trivial to make a key-assignment to toggle yoke visibilty on/off. 90%
transparent is a bit more hassle.

> =======================
> 
> Don't take the following too seriously:
> 
> In the long term, I have fantasies about allowing the point of view
> to change ... not just changing the tilt/pan/zoom from a fixed point,
> but actually moving the pilot's *point* of view.  That would allow
> peering around the yoke to see switches ... and perhaps more
> importantly,
> it would allow moving the PoV to the side to peer around the cowling
> to better see what's going on during landing.  I reckon this would be
> a royal pain to implement, and inconvenient to use in practice, but it
> would be the bees' knees in terms of realism.
> 

Already available - hold down the right mouse-button when in tile/pan mode
and drag the mouse around.

BTW - you'll need OSG CVS FG to make use of most of my changes - there are
dependencies on the new pick animation.

-Stuart

Send instant messages to your online friends http://uk.messenger.yahoo.com 

Re: [Flightgear-devel] C182 creeping features

[Stuart B. <stu...@ya...>]

--- Stuart Buchanan wrote:
> 
> --- John Denker wrote:

<snip>

> > In the long term, I have fantasies about allowing the point of view
> > to change ... not just changing the tilt/pan/zoom from a fixed point,
> > but actually moving the pilot's *point* of view.  That would allow
> > peering around the yoke to see switches ... and perhaps more
> > importantly,
> > it would allow moving the PoV to the side to peer around the cowling
> > to better see what's going on during landing.  I reckon this would be
> > a royal pain to implement, and inconvenient to use in practice, but it
> > would be the bees' knees in terms of realism.
> > 
> 
> Already available - hold down the right mouse-button when in tile/pan
> mode
> and drag the mouse around.
> 

Correction - hold down the middle mouse button.

-Stuart


Send instant messages to your online friends http://uk.messenger.yahoo.com 

[Flightgear-devel] translate PoV up/down left/right

[John D. <sf...@av...>]

On 01/08/2007 02:17 PM, Stuart Buchanan wrote:

>>Already available - hold down the [middle] mouse-button when in tile/pan
>>mode
>>and drag the mouse around.

1) Thanks for the clue.  I've been relying on my joystick (not
 mouse) since Day One, so I had never explored the various
 combinations of mouse functions.

2) This looks like another documentation issue;  even now that I
 know exactly what to look for, I can't find this in the manual
 anywhere.

 I tried grepping for "PoV" and "viewpoint" and finally discovered
 the preferred term is "view point" (two words). The only source of
 information I can find is reading data/mice.xml.  Not very user-
 friendly.

3) I'm thinking I should bind these features to some of the buttons
 on my X52 stick.  Is there a "standard" binding for things like
 this?  If not, I have some ideas I'd like to try........

Re: [Flightgear-devel] C182 creeping features

[John D. <sf...@av...>]

Three more contributions to the bug collection:

*) Weird thing: The model seems never to consume any fuel.  I dumped
  the property list and discovered that engines/engine/fuel-flow-gph
  takes on reasonable values and tracks the throttle setting, while
  engines/engine/fuel-flow_pph remained stuck at zero.  This is a
  particularly bad disconnect, since apparently the latter is what
  gets integrated to calculate engines/engine/fuel-consumed-lbs.

*) Weird thing: No "flags" on the instruments.  The GS needle goes to
  mid-scale if there is no valid signal.  That'll kill you for sure.
  I'm told that the hi-res instruments implement flags, but the lo-res
  ones don't, and the c182 model is using the lo-res versions.

*) Weird thing: Causing failure via the "heading indicator" option on
  the "instrument failures" popup has no discernible effect on the
  HSI.  I dumped the property list and observed that the "serviceable"
  flag on the heading indicator was false, in accordance with the
  desired failure ... but somehow the backend routines are not
  respecting this setting.


I added these to the list at
  http://www.av8n.com/fly/fgfs/c182.notes

Re: [Flightgear-devel] C182 creeping features

[Ampere K. H. <amp...@sy...>]

On Tuesday 09 January 2007 21:19, John Denker wrote:
> <snip>
>
> I added these to the list at
>   http://www.av8n.com/fly/fgfs/c182.notes

It might be a good idea to add these to the c182 page on our wiki:
http://wiki.flightgear.org/flightgear_wiki/index.php?title=Cessna_C182

Ampere

Re: [Flightgear-devel] C182 creeping features

[John D. <sf...@av...>]

On 01/09/2007 09:43 PM, Ampere K. Hardraade wrote:

> 
> It might be a good idea to add these to the c182 page on our wiki:
> http://wiki.flightgear.org/flightgear_wiki/index.php?title=Cessna_C182

Excellent suggestion.

Done just now.

Re: [Flightgear-devel] C182 creeping features

[Jon S. B. <js...@ha...>]

> Three more contributions to the bug collection:
>
> *) Weird thing: The model seems never to consume any fuel.  I dumped
>   the property list and discovered that engines/engine/fuel-flow-gph
>   takes on reasonable values and tracks the throttle setting, while
>   engines/engine/fuel-flow_pph remained stuck at zero.  This is a
>   particularly bad disconnect, since apparently the latter is what
>   gets integrated to calculate engines/engine/fuel-consumed-lbs.

Is this on the JSBSim C-182?

On this one:

    -- However, there is a multiplicative effect: Adding power causes
     a nose-up pitching moment when flaps are in an extended position.
     Or, to say the same thing, extending the flaps causes a nose-up
     pitching moment.  The effect is in proportion to the amount of
     power being developed *times* the amount of flap deflection.

note that I am aware of this, and know how to fix it to add the effect, but
haven't had time. I'll try to post an explanation of the approach in the
next few days.

Jon

Re: [Flightgear-devel] C182 creeping features

[John D. <sf...@av...>]

On 01/09/2007 11:09 PM, Jon S. Berndt wrote:
>>Three more contributions to the bug collection:
>>
>>*) Weird thing: The model seems never to consume any fuel.  I dumped
>>  the property list and discovered that engines/engine/fuel-flow-gph
>>  takes on reasonable values and tracks the throttle setting, while
>>  engines/engine/fuel-flow_pph remained stuck at zero.  This is a
>>  particularly bad disconnect, since apparently the latter is what
>>  gets integrated to calculate engines/engine/fuel-consumed-lbs.
> 
> 
> Is this on the JSBSim C-182?

Yes.



I'm using very a recent data/ tree from cvs.

I'm still using the fsgs binary from May 17  2006, because I still
can't compile anything more recent.  See below




 ./autogen.sh
Host info: Linux i686
 automake: 1.8.5 (18)

Running aclocal
/usr/share/aclocal/lib3ds.m4:4: warning: underquoted definition of AM_PATH_LIB3DS
  run info '(automake)Extending aclocal'
  or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal
Running autoheader
Running automake --add-missing
src/FDM/YASim/Makefile.am:50: bad characters in variable name `'
src/FDM/YASim/Makefile.am:57: bad characters in variable name `'
src/FDM/YASim/Makefile.am:51: yasim_LDADD multiply defined in condition TRUE ...
src/FDM/YASim/Makefile.am:49: ... `yasim_LDADD' previously defined here
src/FDM/YASim/Makefile.am:57:  multiply defined in condition TRUE ...
src/FDM/YASim/Makefile.am:50: ... `' previously defined here
src/FDM/YASim/Makefile.am:58: proptest_LDADD multiply defined in condition TRUE ...
src/FDM/YASim/Makefile.am:56: ... `proptest_LDADD' previously defined here
Running autoconf

======================================
Now you are ready to run './configure'
======================================

Re: [Flightgear-devel] C182 creeping features

[Frederic B. <fre...@fr...>]

Selon John Denker :
> Running automake --add-missing
> src/FDM/YASim/Makefile.am:50: bad characters in variable name `'
> src/FDM/YASim/Makefile.am:57: bad characters in variable name `'
> src/FDM/YASim/Makefile.am:51: yasim_LDADD multiply defined in condition=
 TRUE

try to delete that file and refetch it with CVS

-Fred

--
Fr=E9d=E9ric Bouvier
http://frfoto.free.fr                      Photo gallery - album photo
http://www.fotolia.fr/p/2278/partner/2278  Other photo gallery
http://fgsd.sourceforge.net/               FlightGear Scenery Designer

[Flightgear-devel] compilation contortions : Debian etch

[John D. <sf...@av...>]

On 01/10/2007 02:32 AM, Frederic Bouvier wrote:

>>Running automake --add-missing
>>src/FDM/YASim/Makefile.am:50: bad characters in variable name `'
>>src/FDM/YASim/Makefile.am:57: bad characters in variable name `'
>>src/FDM/YASim/Makefile.am:51: yasim_LDADD multiply defined in condition TRUE
> 
> 
> try to delete that file and refetch it with CVS


Thanks for the suggestion.  That got rid of one bunch of errors.

I fixed another bug myself;  the patch is inline below.

Compilation is proceeding smoothly at the moment ... knock on wood.

Again: Thanks!


--- /usr/share/aclocal/lib3ds.m4        2007/01/10 07:52:19     1.1
+++ /usr/share/aclocal/lib3ds.m4        2007/01/10 07:53:20
@@ -1,8 +1,7 @@
 dnl
 dnl AM_PATH_LIB3DS([MINIMUM-VERSION, [ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND]]])
 dnl
-AC_DEFUN(AM_PATH_LIB3DS,
-[
+AC_DEFUN([AM_PATH_LIB3DS], [

 AC_ARG_WITH(lib3ds-prefix,[  --with-lib3ds-prefix=PFX   Prefix where lib3ds is installed (optional)],
             lib3ds_config_prefix="$withval", lib3ds_config_prefix="")

[Flightgear-devel] more bindings for Saitek X52 stick & throttle

[John D. <sf...@av...>]

I figure if I've got a zillion buttons on my stick/throttle hardware,
I might as well put them to good use.

1) The (D) button on the throttle is the "shift" button. (*)
   That's literally true.  Indeed it's a pun;  see next two items.

2) When the shift button is not pressed, he lower "hat" on the stick will:
    -- pan the view angle left/right, and
    -- tilt the view angle up/down.

3) When the shift button is pressed, the lower "hat" on the yoke will:
    -- shift the view point left/right,(*) and
    -- shift the view point up/down.(*)

I thought long and hard about how to do the bindings for this.
I'm happy with using the (D) button as a shift button;  it feels
natural to me.

Shifting the PoV is not something you need very often, but it does
come in handy in a couple of specific situations:
  -- In some aircraft, there is a whole row of switches hidden
    behind the yoke where you can't see it unless you crane you
    neck to a new view point.
  -- For landing, it helps to move your head to the left (assuming
    you're sitting in the left seat) so you can peer around the
    cowling.

4) The (B) button on the throttle will "zoom out" the view.

5) The (C) button on the throttle instantly resets the view angles
  (tilt/pan/zoom) and also(*) resets the view point (X/Y/Z) back to
  their canonical values.  This feature gets used quite often.

Features marked (*) are new since yesterday.

All of this is implemented here:
  http://www.av8n.com/fly/fgfs/X52.xml.htm
  http://www.av8n.com/fly/fgfs/X52.xml

along with a bunch of more prosaic features: trim, brakes, stopwatch,
et cetera.

[Flightgear-devel] broken radios : KX 165 on Seneca II

[John D. <sf...@av...>]

On the Seneca II model, the KX 165 radios are broken.

 -- When I try to tune 116.0 I get 116.99
 -- When I try to tune 111.7 I get 111.69
 -- But you can't just say everything is off by 0.01 MHz, because
  if I put in 116.01, I get 116.01.  The 116.0 result is skipped,
  i.e. avoided!

I imagine that somewhere in the backend somebody is doing a floor() when
they should be doing a round().  Or some such.

Unless somebody has a better idea, I will add this report to the wiki:
  http://wiki.flightgear.org/flightgear_wiki/index.php?title=Piper_PA34-200T_Seneca_II
within the next day or so.

1) This is using fsgs compiled from a very recent cvs.
   Also using a very recent data/ tree.

2) The same bug (plus additional weirdness) is observed using the fgfs binary
  as distributed back in May.

Re: [Flightgear-devel] broken radios : KX 165 on Seneca II

[Torsten D. <to...@t3...>]

> On the Seneca II model, the KX 165 radios are broken.
>
>  -- When I try to tune 116.0 I get 116.99
>  -- When I try to tune 111.7 I get 111.69
>  -- But you can't just say everything is off by 0.01 MHz, because
>   if I put in 116.01, I get 116.01.  The 116.0 result is skipped,
>   i.e. avoided!
>
> I imagine that somewhere in the backend somebody is doing a floor() when
> they should be doing a round().  Or some such.
That's a known bug and I have no Idea how to get rid of it.Have been digging 
into the source and no result (yet).
As a workaround, I added this to my .fgfsrc

--prop:/instrumentation/comm/frequencies/selected-mhz=126.8501
--prop:/instrumentation/comm/frequencies/standby-mhz=124.2201
--prop:/instrumentation/comm[1]/frequencies/selected-mhz=121.8001
--prop:/instrumentation/comm[1]/frequencies/standby-mhz=132.1201
--prop:/instrumentation/nav/frequencies/selected-mhz=111.5001
--prop:/instrumentation/nav/frequencies/standby-mhz=113.1001
--prop:/instrumentation/nav[1]/frequencies/selected-mhz=113.1001
--prop:/instrumentation/nav[1]/frequencies/standby-mhz=115.1001
--prop:/instrumentation/dme/frequencies/selected-mhz=115.8001

Torsten

Re: [Flightgear-devel] C182 creeping features

[Roy V. O. <roy...@ha...>]

On Monday 08 January 2007 19:12, John Denker wrote:
> Don't take the following too seriously:
>
> In the long term, I have fantasies about allowing the point of view
> to change ... not just changing the tilt/pan/zoom from a fixed point,
> but actually moving the pilot's *point* of view.  That would allow
> peering around the yoke to see switches ... and perhaps more importantly,
> it would allow moving the PoV to the side to peer around the cowling
> to better see what's going on during landing.  I reckon this would be
> a royal pain to implement, and inconvenient to use in practice, but it
> would be the bees' knees in terms of realism.

This was implemented a long time ago. In view mouse mode (two right clicks, 
until the cursor becomes <->) hold the middle mouse button and move the 
mouse.


-- 
Roy Vegard Ovesen