RE: [Flightgear-devel] JSBSim broken?

2005-12-04 Thread Jon Berndt
 I couldn't help but notice that the JSB version of the 747 has a lift-ratio
 which would make a sailplane pilot envious. One can glide about with full
 flaps, gear out etc with AoA at 30--40° in 80 kias and keep it level. ;)

 When running it with --debug-level=debug I get some numbers on JSB's idea
 about drag, for instance:

I appreciate the report. I wanted to let you know I got your email and your bug 
report is
in the queue. I'll put this report in a JSBSim bug report (see 
www.jsbsim.org). I'd like
to emphasize how important it is to get reports from users. THe very best way 
to let us
know about bugs (for JSBSim) is to file a bug report at www.jsbsim.org. That 
way we are
sure it won't get lost.

We've got a lot going on right now, and I'll try to get to that ASAP. Maybe 
someone else
can answer that sooner than I.

Jon

--

Project Coordinator
JSBSim Flight Dynamics Model
http://www.jsbsim.org



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


RE: [Flightgear-devel] JSBSim broken?

2005-12-04 Thread Jon Berndt
 I couldn't help but notice that the JSB version of the 747 has a lift-ratio
 which would make a sailplane pilot envious. One can glide about with full
 flaps, gear out etc with AoA at 30--40° in 80 kias and keep it level. ;)

I've filed the bug as:

http://sourceforge.net/tracker/?func=detailatid=119399aid=1372940group_id=19399

Thanks,

Jon


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


RE: [Flightgear-devel] JSBSim broken?

2005-12-04 Thread Jon Berndt
Log some output parameters. That can be done using the OUTPUT section of the 
config file.
See the X-15 (?) or C-172x config file. I'll get around to it as soon as I can. 
I'm _sure_
there's a simple explanation for this.

Jon


 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] Behalf Of Joacim
 Persson
 Sent: Sunday, December 04, 2005 5:55 PM
 To: FlightGear developers discussions
 Subject: Re: [Flightgear-devel] JSBSim broken?


 On Sun, 4 Dec 2005, Dave Culp wrote:

  As far as the drag values go, the CD0 looks good, and matches aeromatic 
  well.
 ...
  The flap drag looks good.

 Then for some reason all those numbers are ignored. Either in jsbsim
 internally or in the fg--jsbsim interface.

 The plane glides virtually forever. Like overshooting the runway by 15nm
 (after which I got bored) with an attitude of 30° in 90kts at 180' AGL (=no
 ground effect).  (It looks funny though. =)

 I've been testing other jsbsim models tonight apart from the 747-100: 737,
 c150, c182 and they all seem to have extremly low or zero drag. They won't
 stall.

 But since the jsbsim guys are busy preparing a new release which will
 affect the config files anyway(?) I think I'll just drop it for now.


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


RE: [Flightgear-devel] JSBSim broken?

2005-12-04 Thread Jon Berndt
 I've been testing other jsbsim models tonight apart from the 747-100: 737,
 c150, c182 and they all seem to have extremly low or zero drag. They won't
 stall.

Hmmm. I've not heard any complaints about the other aircraft. The 737 has been 
extensively
tested by someone who knows how they fly. Also, if any of these aircraft had 
zero or
artificially low drag, they thrust produced by the engine would propel them to
unbelievably high speeds. Now, I haven't tested these models in a long time 
(yes, I am
incredibly busy right now on many fronts), but if the C182 flew at 400 kts I 
think I'd
hear about it.

Jon


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


RE: [Flightgear-devel] yasim vs jsbsim c310

2005-12-03 Thread Jon Berndt
 I've just tried out the c310 @KSFO, current metar conditions.
 The Yasim one develops 38PSI of manifold pressure, ~2700RPM
 at props and throttle full forward on the ground, brakes applied.
 The JSBsim gives a (more realistic-?) 29PSI. No surprise the ground
 roll at the Yasim one's is much shorter. 25 squared in Yasim
 means the throttle around halfway in at 500agl.
 I've never been in a c310 myself, passenger or pilot, but one of these
 aircraft simulations seems wrong.

It may be a case of input data being different. There may be several slightly 
different
engines that could be used. I've got bigger fish to fry at the moment, but if 
you come
upon some good specification data, post it here. Some tweaking might be in 
order.

Jon


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


[Flightgear-devel] OpenGL and new video card

2005-12-01 Thread Jon Berndt
I've installed a new video card (eVGA 6800, 128mb) in my Windows 2K box. 
Unfortunately,
now OpenGL apps give an application error - they don't even start up. I'm 
trying to get
some answers out of the card and driver manufacturer, but if anyone here has any
suggestions, I'd appreciate hearing them

Jon


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


[Flightgear-devel] OpenGL and new video card

2005-12-01 Thread Jon Berndt
I've installed a new video card (eVGA 6800, 128mb) in my Windows 2K box. 
Unfortunately,
now OpenGL apps give an application error - they don't even start up. I'm 
trying to get
some answers out of the card and driver manufacturer, but if anyone here has any
suggestions, I'd appreciate hearing them

Jon


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


RE: [Flightgear-devel] Re: [Flightgear-cvslogs]CVS:data/Aircraft/Lockheed1049/Models

2005-11-28 Thread Jon Berndt
 That was my understanding of it, but it seemed to not work with ___'s
 Connie model.  Upon further review it looks like ___'s Connie model has
 an x-offset of about 14 meters, and I can't figure out why.  So, I'll drop my
 investigation of it.

 Dave

:-)

Once we get the new JSBSim FDM into FGFS CVS I'll have a look at it (there's 
always
something _just_before_ the good stuff on my todo list).

Jon


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


RE: [Flightgear-devel] Alpha problems with 2.5D panel on C310 and aftCenter of Gravity

2005-11-27 Thread Jon Berndt
 I noticed in the JSBSim file (c310.xml) definitions for pilot, copilot,
 rear passengers and baggage. It all seems to be in the main cabin (i.e. no
 baggage in the nose compartment). To lighten the load I'm going to remove
 the rear pax. Will this automagically bring the CofG forward, or do I need
 to modify something else?

Yes, it will.

Jon


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


[Flightgear-devel] CVS and PLIB

2005-11-27 Thread Jon Berndt
Is there some kind of problem going on with downloading PLIB from CVS? Seems 
there's been
a partial outage in progress on SF.net for weeks. I can't get plib from CVS, 
though ...

:-(

Jon


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


RE: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:data/Aircraft/Lockheed1049/Models

2005-11-27 Thread Jon Berndt
 One thing that may be confusing is that the VRP setting given by aeromatic is
 wrong.   In the JSBSim configuration file If the CG location is X, Y, Z,
 then the VRP location is -X, -Y, -Z.I had thought that AC_VRP defines the
 location of the VRP, however it actually defines the location of the VRP
 *from* the CG (?).   I never noticed it in the T-38 and other smaller
 airplanes because the effect is hard to see.  In a big airplane like the 1049
 you can see it.

 The above may seem authoritative, but I'm really only 90% sure it's correct :)
 I know you have all been waiting impatiently for another VRP thread.

 Dave

No. The VRP defines the location of an agreed-upon reference point in structural
coordinates. The CG, eyepoint, gear locations, etc. are all defined (in JSBSim) 
in
structural frame. By convention, we've agreed that the nose is typically a good 
reference
point, because it is (or should be obvious) to both the 3D model designer and 
the FDM
designer. The CG generally cannot be used, because it moves - sometimes that 
movement
could be profound.

Think of it this way: the structural frame is a fixed, solid, coordinate frame 
that
permeates the aircraft structure. The structural frame we use MUST have X 
positive out the
back, and Y out the right wing. The Z axis completes the right-handed system 
positive
upwards. The _origin_ is what is usually found to be confusing. Often, the 
origin is
located by having the X axis be coincident with the fuselage centerline, with 
X=0 at the
tip of the nose - but THAT IS NOT A REQUIREMENT. If the origin is 200 inches in 
front of
the nose, then the VRP could be defined as (200, 0, 0). If the 3D model designer
understands that, the aircraft model can be placed with the nose at the 
location pointed
to by JSBSim. The VRP is the registration mark that relates what is reported 
by JSBSim
and what part of the 3D model is placed at what location in the 3D world.

Within JSBSim, the equations of motion are all done relative to the CG. 
However, JSBSim
can send to FlightGear the lat/lon/alt of ANY desired point on the aircraft, at 
any time,
in any orientation (it's not hard). We just have to agree on WHICH point is 
being sent.
That's what the VRP is all about.

I pray to God that explains it for the last time! :-)

Jon


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


RE: [Flightgear-devel] Re: [BUG] [PATCH] (announcement) throwingstale exceptions and missing copy ctor/assignment

2005-11-25 Thread Jon Berndt
 I wonder what compiler was JSB using in his string throwing example,
 can you please re-read that thread and see if you can find an alternative
 explanation?

 Vassilii

I use Borland C++, and the g++ compiler in the cygwin distribution. I also 
compile under a
flavor of Linux, just to see what happens. I've been worried that 
try/catch/throw is
something that is not supported similarly on different compilers.

I've got other priorities right now, but please make use of our bug reporting 
mechanism at
www.jsbsim.org. It's really the only way to be sure we don't lose track of 
stuff.

Thanks,

Jon


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


RE: [Flightgear-devel] ATC and aerodynamics docs

2005-11-25 Thread Jon Berndt
 Szabolcs Berecz writes:
  Could you direct me to some good online documentation about ATC and
  aerodynamics of a helicopter?

 Okay, I said I was going to email them privately, but then I looked at
 a 32MB email in my outbound queue and realized that that was beyond
 bad form.

 See:

 http://www.flutterby.com/danlyke/helicoptersimnotes/MinimumComplexityHelicopterS
imulationMathModel.pdf
http://www.flutterby.com/danlyke/helicoptersimnotes/naca-report-824.pdf
http://www.flutterby.com/danlyke/helicoptersimnotes/naca-tn-4357.pdf


Robert Heffley (co-author of the Minimum Complexity ... document) has his 
papers online
(including that one):

http://robertheffley.com/pages/lib.htm

You can also search the NACA technical report server here:

http://naca.larc.nasa.gov

The papers are online there, too.

Jon


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


RE: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:data/Aircraft/Lockheed1049 - New

2005-11-23 Thread Jon Berndt
 The Constellation looks pretty nice, but has a significant drawback:
 The author has forgotten to implement the offset between FDM center and
 visual reference point. This means the aircraft rotates around it's
 nose which makes it almost impossible to accurately rotate for liftoff.
 Furtheron it looks really funny when the aircraft wags the whole
 body when you use the elevator  ;-)

 Syd, I presume this is your work. Would you mind adding this offset ?

 Thanks,
   Martin.

I *think* I know who did this model. I'll notify/ask him abou tit. Thanks for 
noticing the
VRP aspect.

Jon


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


[Flightgear-devel] WARNING: FlightGear / JSBSim changes

2005-11-23 Thread Jon Berndt
As has been mentioned, JSBSim has been undergoing major improvements over the 
past year
(see the newsletters) centering on added capabilities and improved XML 
well-formed-ness.
The majority of those improvements have been completed and tested, both in a 
standalone,
scripted mode, and in the previous release of FlightGear itself.

We will be moving the new code into FlightGear development CVS shortly. My 
goals during
that process are as follows:

 A-1) Don't break FlightGear compilation for other FDMs.

2) Provide replacement models for JSBSim aircraft as soon as practical.
3) Make sure that existing JSBSim aircraft models function correctly  as soon 
as possible.
4) Provide documentation on the new format, and a converter.

We've done all we can in the way of testing and validation of our code prior to 
the next
step. However, once that is accomplished and refined, I think we'll see some 
real benefits
to this.

The new config file spec (the new format) is pretty nice. It was designed to 
be
compatible with the emerging AIAA standard for aircraft flight model exchange, 
to be
called AeroML (see: http://daveml.nasa.gov). I have heard from at least two 
other flight
model programmers who have expressed a desire to use the JSBSim config file 
format as
their own spec. So, I believe the new spec (v2.0 - that's the version number 
for the
config spec - not JSBSim itself) may lead to more aircraft eventually being 
available for
FlightGear and other sims.

I'm not sure exactly when the changes will be incorporated into FlightGear (I 
have to
discuss this with the other JSBSim developers - particularly Erik). But, this 
serves as a
heads-up and an open period for questions and comments.

Jon
--
Jon S. Berndt
Project Coordinator
JSBSim Flight Dynamics Model
http://www.jsbsim.org



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


RE: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 31, Issue 101

2005-11-23 Thread Jon Berndt
  Syd, I presume this is your work. Would you mind adding this offset ?
 
  Thanks,
  Martin.
 
 
 I *think* I know who did this model. I'll notify/ask him abou tit. Thanks for 
 noticing the
 VRP aspect.
 
 Jon
 
 
 Hi guys  no that one isn't mine.

As they say: The issue is being worked.

:-)

Jon


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


[Flightgear-devel] Speaking of carriers ...

2005-11-23 Thread Jon Berndt

A nice shot of a carrier landing:

http://www.airliners.net/open.file/961401/M/

Jon



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


RE: [Flightgear-devel] Re: Release of v0.9.9 source code

2005-11-19 Thread Jon Berndt
 And if none of this is possible, then I'm afraid I don't have a
 TODO list and this will be the most boring release cycle ever.

 m.

Heh. Maybe. Maybe not. I hope that from your point of view it turns out to be a 
boring
release cycle. In one respect, it should not be very noticeable to users what 
has
happened, apart from the fact that none of the existing JSBSim aircraft, 
engines, or
thrusters will work in their current form. They will have to be converted to 
the new
JSBSim config file format. A conversion helper tool is available.

For over a year myself and others have discussed refining the JSBSim config 
file format to
a more well-formed design. I have also tried to consider what was done by the 
guys working
on the AIAA standard for aircraft simulation model exchange, to be called 
AEROML (formerly
known as DAVEML, see daveml.nasa.gov).

As part of the config file format change, new capabilities were added. The 
version of
JSBSim to be added to FlightGear developer CVS in the coming weeks will be a 
major change.
I'll describe the new features in the JSBSim developer list soon.

I'm also fixing up the comments in the code to reflect the new changes, and 
will be
publishing a document on the new config file format, as well.

Jon


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


RE: [Flightgear-devel] error:Unknown exception in the main loop

2005-11-19 Thread Jon Berndt
 I'm now working on the unsafe throws/catches in the
 SimGear/FlightGear/Atlas/fgrun codebase.

 A hefty amount of things to change is in the scope of the JSBsim code.
 What should I do --- ignore them and hope for JSB doing a correct cleanup
 upstream, or patch these as well?

 Vassilii

If you are aware of unsafe throw/catch code in JSBSim, go ahead and either 
email me or
post a message in the JSBSim mailing list. I'll be glad to take a look. Thanks,

Jon


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


RE: [Flightgear-devel] Re: Release of v0.9.9 source code

2005-11-19 Thread Jon Berndt
 I agree with Franz Melchior.
 And my question is, why it is so essential to call the next version release
 1.0?
 What's wrong with version numbers like 0.9.10, 0.9.11, 0.9.12 etc. until the
 above issues are fixed?

That's what's been getting done for years. The question now is, why not? Curt's 
been
working on FlightGear for ... what ... about ten years, now?

To turn the argument around, there's nothing to fear from calling it 1.0, 
either. The next
release would be a fitting v1.0, IMHO.

Jon


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


[Flightgear-devel] RocketCam / PlaneCam

2005-11-19 Thread Jon Berndt
Does FlightGear have the capability to specify a camera viewpoint ON the 
aircraft. For
instance, could a camera be mounted on the vertical stabilizer, pointing 
forward? It
would be nice to see the aerosurface movements.

Jon


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


RE: [Flightgear-devel] Re: Release of v0.9.9 source code

2005-11-19 Thread Jon Berndt
 I think the issue can be argued both
 ways, but time (and version numbers) marches on.

 Curt.

Here's another for argument: when we go to v1.0, it's a great excuse for a 
HUGE virtual
party. ;-)

Then there's the obligatory First International FlightGear Technical 
Conference. I
recommend the first one be held in Tahiti. ;-)

Jon


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


RE: [Flightgear-devel] try ... catch ... throw (up)

2005-11-12 Thread Jon Berndt
 Vassilii Khachaturov wrote:

 I am unsure it is OK to through a temporary object like this.
 It's created on the stack right there at the same frame where it's thrown,
 but IIRC, as throw unwinds the stack, it is auto-destructed. You should
 be throwing an object that has lifetime encompassing the outer catch
 handler.

Ah! Yes, that sounds correct. I'll have to go back and change my throws.

Thanks,

Jon


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


[Flightgear-devel] try ... catch ... throw (up)

2005-11-11 Thread Jon Berndt
I've been trying to use exception handling in a particularly appropriate place 
in JSBSim,
but am having little success, and it's got me confused.

I have a section where I am reading in some data. If it is inappropriate, I 
need to let
the user know and exit.

Here's what I'm doing:

In the Table class:

In FGTable constructor:

if (operation_types.find(parent_type) == string::npos) {
  internal = true;
} else {
  throw(string(An internal table cannot be ...));
}

Now, this seems to work OK - I throw an exception if a situation occurs that is 
invalid.

Here's where the above code is originally called from:

In FGFunction constructor:

try {
  Parameters.push_back(new FGTable(PropertyManager, element));
} catch (...) {throw;}

This is supposed to pass the exception on up the chain to here the code that 
calls the
above:

In FGAerodynamics::Load():

try {
  variables.push_back( new FGFunction(PropertyManager, function_element) );
} catch(string msg) {
  return false;
}

Execution seems to get to the throw in FGFunction and dies. Execution never 
gets to the
handler in FGAerodynamics. I get a segfault.

I'm probably missing something fundamental here. Anyone have any suggestions?

Jon


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


RE: [Flightgear-devel] 737 nosewheel animations

2005-11-10 Thread Jon Berndt
 Hi,

 attached are two small patches for giving the 737 nosewheel some
 animations. Namely it rotates when steering and compresses on breaking.
 For the latter I attached a one line patch that let's JSBsim expose
 compression-norm to the property tree just like YaSim.

 I don't know if this is in any way correct, but it gives some plausible
 movement visually. Now if there were some skid sounds you could get an
 impression how such a large plane feels like on the ground ;)

 Nine

I've got these slated to go into the new JSBSim code, as well. I hope to 
implement the
changes today.

Jon


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


RE: [Flightgear-devel] (electrical) Flightgear-devel Digest, Vol 30, Issue 24

2005-10-11 Thread Jon Berndt
Curt wrote:

 The nasal script is specific code to impliment a specific aircraft's
 electrical system, but the overall structure could be copied and adapted
 to new aircraft.  But each aircraft will need it's own aircraft specific
 script.

I'll add that there are probably several ways to do various 
mechanical/electrical system
models. You may recall from Summer 2005 JSBSim newsletter an article about the 
L410
aircraft model done by Jiri Javurek. They use the JSBSim flight control 
components to
model various systems in ways I had not considered before. For example (and 
this is old
format - the current format in FlightGear CVS - JSBSim specification):

 FLIGHT_CONTROL NAME=l410

  !--Stav baterii--

  COMPONENT NAME=battery-all-ok TYPE=SWITCH
TEST LOGIC=DEFAULT VALUE=0
/TEST
TEST LOGIC=AND VALUE=1
/systems/l410/battery1-ok == 1
/systems/l410/battery2-ok == 1
/TEST
  /COMPONENT

  COMPONENT NAME=battery-one-ok TYPE=SWITCH
TEST LOGIC=DEFAULT VALUE=0
/TEST
TEST LOGIC=OR VALUE=1
/systems/l410/battery1-ok == 1
/systems/l410/battery2-ok == 1
/TEST
  /COMPONENT

  COMPONENT NAME=battery-all-ok2 TYPE=PURE_GAIN
 INPUT   fcs/battery-all-ok
 GAIN 1
 OUTPUT  /systems/l410/battery-all-ok
  /COMPONENT

  COMPONENT NAME=battery-one-ok2 TYPE=PURE_GAIN
 INPUT   fcs/battery-one-ok
 GAIN 1
 OUTPUT  /systems/l410/battery-one-ok
  /COMPONENT

  !-- specialni nasobne sbernice --

  COMPONENT NAME=spec-turn TYPE=SWITCH
TEST LOGIC=DEFAULT VALUE=0
/TEST
TEST LOGIC=AND VALUE=1
/systems/electrical/outputs/bus28v  10
/systems/electrical/outputs/bus36v  10
/systems/electrical/outputs/bus115v  10
/TEST
  /COMPONENT
  COMPONENT NAME=spec-turn2 TYPE=PURE_GAIN
 INPUT   fcs/spec-turn
 GAIN 1
 OUTPUT  /controls/switches/specbus_28v_115v_36v
  /COMPONENT

  etc.

It's quite an impressive use of the components.

Jon


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


RE: [Flightgear-devel] Source code

2005-10-08 Thread Jon Berndt
 The version of FlightGear used for the MIADC show in May contains a
 fan/turbine model based on physics and thermo equations, a different
 approach to tank/engine selection to handle the 747 fuel system, changes
 in the control packet, and an update to the data packets.  It might not
 be practical to try and incorporate these into the CVS baseline .I'm not
 sure and not all that conversant on how to create all the ifdefs and
 other compile/run time options or xml files to handle all the deltas.
 However, the source is there for anyone brave enough have a go at it or
 just to consider if it might be feasible.  As I recall, Curt first
 created a diff file against the then current CVS baseline, next ran
 patch, and IIRCC the build was very clean.  Go to http://www.lfstech.com
 and browse over to the download page. The file is miadc.tgz.

 John W.

Hi, John:

Very nice. I looked at FGTurbine.cpp. A couple of things:

1) Of course, it would be nice to incorporate the JSBSim changes into the 
current JSBSim
CVS. However, as you may know, JSBSim has undergone major revisions compared to 
the
version now in FlightGear CVS. Within weeks (maybe sooner) we should be moving 
the new
JSBSim code into FlightGear development CVS. So, to incorporate your changes, 
the Load()
method will need to conform to the use of the new XML parsing method.

2) Question: Is your turbine model generic, or specific to the 747?

3) Did you make note (in code or whatever) of exactly which files you modified?

Jon


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


RE: [Flightgear-devel] Source code

2005-10-08 Thread Jon Berndt
 Out of interest, did Mathias ever manage to fix the gear jitter at stationary
 with his fancy integration scheme, and if so will it be going into FlightGear
 when you merge up next?

 Cheers - Dave

No. (I hope this doesn't open up a can of worms ...)

Though it is acknowledged that Mathias' fix would have worked well, and is 
mathematically
precise, the code overhead was sophisticated, large-ish, and somewhat complex - 
an
evaluation that is, of course, open to interpretation and difference of 
opinion. The
quandary I always face as development coordinator is in balancing design goals 
and actual
capabilities. I had to consider the needs  and perceived comfort level of the 
target
audience[s], as well as myself. It led to a lot of really excruciatingly 
uncomfortable
choices, some of which were so personally vexing that I continually put them 
off.

At this point, yes, the gear still jitters, and it is still a high priority to 
be
addressed. The route I prefer to take - at this time - is best described this 
way: The EOM
and integration scheme now in use (which Mathias also adeptly refined) works 
quite well
for almost anything that anyone wants to do with JSBSim. The single most 
important
remaining problem that involves the dynamic math model is the same problem that 
the
literature shows afflicts many other simulators: landing gear modeling at low 
and zero
velocity. I do not feel it is the best solution at this time to consider a new 
and major
change to the integration scheme in order to address this one problem.

There are probably a few good approaches to fixing the gear problem - and it 
does need to
be fixed. One good one is presented in an AIAA paper (AIAA-200?-4303). In that 
paper, the
tricycle approximation is described.

At some point, the integration scheme in JSBSim will probably be revisited, 
after some
other approaches in JSBSim are modified. The gear jitter problem will be 
addressed. Right
now there are other pressing needs.

I don't know what else to say ...

Jon


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


RE: [Flightgear-devel] Source code

2005-10-08 Thread Jon Berndt
John Wojnaroski wrote:

 It's generic, but needs some massaging to handle things like 
 compressor/turbine maps, engine parameters such as inlet area, fan size. 
 Point in fact, the model is based on John Reed's paper for LeRC, but the 
 actual numbers are my best guess to obtain some reasonable numbers for 
 engine performance and response. The start sequence is kind of nice with 
 the EGT showing the typical rise to a peak and then settling into the 
 idle range.

Is this the paper:

---
A Java simulator for teaching gas turbine operation 

John A. Reed and Abdollah A. Afjeh (Toledo, Univ., OH) 
AIAA-1997-850 
Aerospace Sciences Meeting and Exhibit, 35th, Reno, NV, Jan. 6-9, 1997 
---

I can't find it anywhere online.

 The FGTurbine code is replaced en masse.  No, sorry did not, but you 
 should be able to run a diff. It's been a few months since I worked in 
 that area, recall some changes in the FGEngine, and a few other areas to 
 handle loading in the other engine parameters from the xml files.  
 Probably makes more sense to wait for the next JSBSim release.
 I'll probably revisit that code in the next few months for another 
 project and update it as needed.

Sounds good.

Jon


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


[Flightgear-devel] Rita

2005-09-20 Thread Jon Berndt
I'll likely be relatively sparse on the Internet for the next week or so - 
perhaps much,
much longer depending on how things go in League City, due to Rita. I'm about 
14 feet
above sea level, about a mile inland from Galveston Bay.

Anyone else look like they're going to be affected by this?

Jon


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


RE: [Flightgear-devel] Release 0.0.7 of Digitrak Autopilot

2005-09-18 Thread Jon Berndt
 To everyone who has helped, thanks. My goal is to model the behaviors
 and capabilities of the Digitrak with as much accuracy is possible
 given my ability and the limitations of Flight Gear. I doubt it would
 be possible or desirable to model the electrical characteristics of
 the sensors or reverse engineer the actual code. The short term goal
 is to model the basic behavior of the autopilot, to get the basic
 modes working, then see what is possible. My long term goal is to
 model the building blocks, the gyros, the magnetic compass and let
 those feed into the autopilot's calculations. This will help model the
 autopilot without depending on any of the other instruments. The
 ultimate goal  would be to model it well enough to use as a training
 tool.

Just out of curiosity, have you looked at the flight control system modeling 
capabilities
in JSBSim? I realize that limits you to JSBSim aircraft, which in itself might 
be a
show-stopper. Also, the newest and most useful features are in the codebase 
which has not
yet quite made it into FlightGear CVS.

However, it still might be interesting for you. the JSBSim FCS model that will 
be
[shortly?] placed into the FlightGear branch features:

- Sensor modeling (for scalar values - not vectors, yet) that features some 
failure modes
controllable via properties.
- Sensors can output quantized values of arbitrary bit width.
- Sensors can feature noise and drift.
- The flight control system components include generic filters and an 
integrator.
- There is a function component that can model a user-defined function that 
includes sine,
cosine, abs, etc. functions.
- Other components include summers, gains, scheduled gains, scale-mapping, 
switches, and
kinematic controls (for modeling landing gear, aerosurfaces, etc.)

You can read about the flight control system more in some of the JSBSim 
newsletters.

I've already implemented a test autopilot. It's a lot of fun to play with. The 
point is
that you have complete control.

Just an idea.

Jon


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


RE: [Flightgear-devel] EasyXML.cxx

2005-09-17 Thread Jon Berndt
 I'm not surprised it breaks with malformed XML files.
 A suggested fix is below.
 
 if (!input.good()) {
sg_io_exception ex(Problem reading file,
  sg_location(path,
  XML_GetCurrentLineNumber(parser),
  XML_GetCurrentColumnNumber(parser)),
  SimGear XML Parser);
XML_ParserFree(parser);
throw ex;
  }
 
 --Richard


Has the disposition of this been resolved, yet?

Jon


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


[Flightgear-devel] JSBSim aircraft

2005-09-15 Thread Jon Berndt
In [further] preparation for installing the new JSBSim code and config file 
format into
mainline FlightGear, I'd like to know which JSBSim aircraft are considered 
important
enough to do some really good testing on before making the move to the new 
codebase.
Please let me know which JSBSim aircraft are important to you. (Saying: Oh, we 
use other
FDM exclusively. is not an allowed response - even if it's true. If it _is_ 
true, you
should make something up so I will feel needed. ;-) ;-)

The C-172p/r are assumed to be needed.

Please reply only to one list.

Jon


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


[Flightgear-devel] [OT] Newsletter

2005-08-25 Thread Jon Berndt
This is off topic for FlightGear specifically, but I also am the Editor and a 
writer for
another newsletter in addition to the JSBSim newsletter. The July/August issue 
was just
posted. I thought you might be interested to read the newsletter for the 
Houston chapter
of the American Institute of Aeronautics and Astronautics:

www.aiaa-houston.org/newsletter

There's lots of aerospace in there!

Jon


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


[Flightgear-devel] [EMAIL PROTECTED] Conference

2005-08-21 Thread Jon Berndt
I'd give a lot to know what these two papers are presenting! See below:

Jon

---

[EMAIL PROTECTED] Conference
26 - 29 Sep 2005
Hyatt Regency Crystal City
Arlington, Virginia

Session 71  COTS Software in Mission Critical Systems

0930
AIAA-2005-7108
Open Source Software: Cheap Isn't Exactly Free!
B. Calloni, J. McGowan, and R. Stanley, Lockheed Martin Corporation, Fort 
Worth, TX

1000
AIAA-2005-7106
Bazaar Meets Cathedral: Concerns About Open Source Software in Mission Critical 
Systems
[invited]
R. Kwan, Lightsaber Computing, Fremont, CA



___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] 3D Cockpit view, L410 Turbolet

2005-08-11 Thread Jon Berndt
 We used red and green in Europe :-(

 Erik

Did you look at it, anyhow? The blue and green channels both are set for the 
right eye.
Red/Green glasses should work, too.

Jon


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


RE: [Flightgear-devel] 3D Cockpit view, L410 Turbolet

2005-08-11 Thread Jon Berndt
 I have, and would love to see it added to the FG collection - it appears to be
 a thoroughly thought-out model.  However, it's just too much trouble for me
 to keep a third copy of FG for the sake of one model.

 What is the general opinion of the modifications done to the FG source in
 particular - are they likely to be introduced into CVS any time soon?  It
 seems a pity for such an amount of work to miss wider exposure.

 Does the new JSBSim version do what their model requires?

 AJ

I've given a quick view to the changes that were made to JSBSim. I'm way busy 
right now,
but I do want to incorporate their changes. It's going to be a little bit of a 
trick,
because their changes were made to the older version of the code. Still, it 
ought to be
possible, and it is my intention to work with them to incorporate their changes 
as soon as
possible.

Jon


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


RE: [Flightgear-devel] 3D Cockpit view, L410 Turbolet

2005-08-11 Thread Jon Berndt
 I had a look with a red / green pair and it's quite an impressive effect. I'd
 love to have a go at making a true stereo HMD (dual display) because the
 immersion effect 'feels' great.

 The cockpit itself is stunning; top marks to its creators.

 Just one point on the anaglyph; the difference in the seats is too great
 (doesn't work visually) - I think this is probably down to the selected FOV
 and proximity of the viewpoint to the seats.

 Dave Martin.

The red and green/blue images could be registered better in the post-processing 
phase.
However, had I done that, I would have had to crop the images more 
horizontally. I didn't
feel like doing that at the time. It was sort of a quick-and-dirty 
post-processing effort.
I agree, though, that it would be cool to have a stereo flight simulator. I've 
got no idea
on the mechanics of the visuals though - how that could be implemented.

Jon


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


[Flightgear-devel] New JSBSim release; New JSBSim Newsletter

2005-08-10 Thread Jon Berndt
JSBSim v0.9.9 has been released and is available at www.jsbsim.org. JSBSim is 
an open
source flight dynamics model written in C++. JSBSim is one of the flight models 
used in
the open source flight simulator, FlightGear, but JSBSim is also used in other 
flight
simulator projects around the world. JSBSim can also be run by itself in a 
standalone
mode.

The major new features in v0.9.9 can be seen in the latest issue of the JSBSim 
newsletter,
Back of the Envelope (also just released). The newsletter can be viewed at 
the project
web site at www.jsbsim.org.

Jon Berndt


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


RE: [Flightgear-devel] New JSBSim release; New JSBSim Newsletter

2005-08-10 Thread Jon Berndt
 JSBSim v0.9.9 has been released and is available at www.jsbsim.org. JSBSim is 
 an open
 source flight dynamics model written in C++. JSBSim is one of the flight 
 models used in
 the open source flight simulator, FlightGear, but JSBSim is also used in 
 other flight
 simulator projects around the world. JSBSim can also be run by itself in a 
 standalone
 mode.

Note: This new version has been tested successfully with the latest version of 
FlightGear,
but has not yet been officially integrated with it.

Jon


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


[Flightgear-devel] 3D Cockpit view, L410 Turbolet

2005-08-10 Thread Jon Berndt
Those of you who have read the newsletter have probably seen (and drooled over) 
the
wonderful 3D model of the L410 Turbolet created by Jiri and Jiri Javurek. Jiri 
created a
left and right view of the cockpit, and I created a stereo anaglyph using the 
images. If
you have red/blue glasses, you might have a look at the two images (one is 
color, one is
black and white):

http://www.jsbsim.org/L410Cockpit3DBW.png
http://www.jsbsim.org/L410Cockpit3DColor.png

Jon


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


RE: [Flightgear-devel] OT: Mojave, CA

2005-08-07 Thread Jon Berndt
 But, an FDM interface needs to do more than shove a datastructure back
 and forth.  There needs to be some higher level communication to tell
 the remote FDM when it should reset it self or when it should trim for
 in air or on the ground, and what trim conditions are requested (i.e.
 start in air at 4500' MSL, 98 kts, 10 degree flaps, gear up, in a 20
 degree right banking turn.)

Also, it should be able to handle any number of engines (0 ... n), various 
arbitrary
control surface arrangements, any number of landing gear or ground contacts, 
arbitrary
flight control system, etc.

Jon


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


RE: [Flightgear-devel] config.sub ?

2005-08-02 Thread Jon Berndt
 Jon Berndt wrote:

  I've tried these both. This seems to be fatal no matter what I do:
 
  [EMAIL PROTECTED]:~/JSBSim$ ./configure
  configure: error: cannot run /bin/sh ./config.sub

 There are two things: Is is a symbolic link (and does the target exist)
 and is it marked executable?

 Erik

I finally got it working. I just copied config.guess and config.sub from the 
autotools
location where they were to the build directory I was running from (JSBSim/). I 
was doing
this on Sourceforge's compile farm server for Mac OSX-2. The make process went 
very well,
the executable built, and the test run went OK.

This is in preparation for announcement of v0.9.9, the release of the 
newsletter, and
executables for several platforms.

Jon


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


RE: [Flightgear-devel] JSBSim: Failed to tie propertypropulsion/c-thrust[0] to a pointer

2005-08-01 Thread Jon Berndt
 When the JSB a/c model has several engine+propeller we get
  that JSB message error:
 Failed to tie property propulsion/c-thrust[0] to a pointer
 What must be defined in Aircraft.xml to solve it.
 --
 Gerard

Which version of JSBSim are you using? Is it the one currently in FlightGear 
CVS?

You'll need to tell me more about your aircraft/propeller config files (or 
email them to
me).

Jon


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


[Flightgear-devel] config.sub ?

2005-07-30 Thread Jon Berndt
I'm trying to build JSBSim on one of Sourceforge's compile farm boxes, this one 
running
Linux. After running aclocal;automake;autoconf I try to run configure and get 
this:

configure: error: cannot run /bin/sh ./config.sub

I don't see a config.sub. Where does that come from?

Jon


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


RE: [Flightgear-devel] Free simulator of the Frecce Tricolori aerobaticjet

2005-07-28 Thread Jon Berndt
 Since the MB-339 PAN is an on-going project, we plan to release 
 an improved version of the aircraft (with smokes?). If anyone
 at flightgear.org would like to link our MB-339 PAN project in
 the Related Projects section, we would be very happy.  
Bye, Augusto.


I will mention it in the upcoming JSBSim newsletter, too.

Jon


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


RE: [Flightgear-devel] jsbsim won't start with w110n40 or w110n30airports

2005-07-27 Thread Jon Berndt
 FGLGear.cpp line 507 
  Here's the code: 
  // Crash detection logic (really out-of-bounds detection) 
  if (compressLength  500.0 ||
  vForce.Magnitude()  1.0 ||
  vMoment.Magnitude()  50.0 ||
  SinkRate  1.4666*30)
  {
PutMessage(Crash Detected: Simulation FREEZE.);
Exec-Freeze();
  }
 The undercarriage definition is very flexible. It gives the facilities
 to manage an aircraft customised crash animation with the help of a
 nasal script.
 If an improvement must be done it could be done on the old existing code
 with specifics properties like that one which is coming from a Dave
 mail.
 crash-detection
   altitude-agl0/altitude-agl
g-z-max11.0/g-z-max
g-z-min5.0/g-z-min
g-x-max20/g-x-max
g-x-min20/g-x-min
qbar1089.0/qbar
pitch-rate3.7/pitch-rate
yaw-rate3.5/yaw-rate
mach0.99/mach
  /crash-detection

The out-of-bounds detection logic was a development piece of code, really. That 
can be removed if it is causing a problem.

Jon


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


[Flightgear-devel] Property Tree Catalog

2005-07-27 Thread Jon Berndt
Well, without the benefit of SimGear as a whole, I've crafted a [probably 
non-optimal]
property tree cataloging function for use in JSBSim. Thought you might like to 
see it:

//%%

struct PropertyCatalogStructure {
  string base_string;
  FGPropertyManager *node;
};

void FGFDMExec::BuildPropertyCatalog(struct PropertyCatalogStructure* pcs)
{
  struct PropertyCatalogStructure* pcsNew = new struct PropertyCatalogStructure;
  int node_idx = 0;
  char int_buf[10];

  for (int i=0; ipcs-node-nChildren(); i++) {
pcsNew-base_string = pcs-base_string + / + 
pcs-node-getChild(i)-getName();
node_idx = pcs-node-getChild(i)-getIndex();
sprintf(int_buf, [%d], node_idx);
if (node_idx != 0) pcsNew-base_string += string(int_buf);
if (pcs-node-getChild(i)-nChildren() == 0) {
  PropertyCatalog.push_back(pcsNew-base_string + 
pcs-node-getChild(i)-getName());
} else {
  pcsNew-node = (FGPropertyManager*)pcs-node-getChild(i);
  BuildPropertyCatalog(pcsNew);
}
  }
  delete pcsNew;
}

//%%

It's called like this:

//%%

  struct PropertyCatalogStructure masterPCS;
  masterPCS.base_string = ;
  masterPCS.node = (FGPropertyManager*)master;

  BuildPropertyCatalog(masterPCS);

  cout  endl  Registered properties:   endl;
  for (int i=0; iPropertyCatalog.size(); i++) cout  PropertyCatalog[i]  
endl;

//%%



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


RE: [Flightgear-devel] sprintf

2005-07-26 Thread Jon Berndt
  No, you can't format (the f in printf) the string using the default C++
  string class).

 You have to use the I/O manipulators (Stroustrup: 21.4.6.2, page 633ff.)
 like std::setprecision().

The string class cannot create a string representation of a floating point 
number as far
as I can tell. The next best thing (IMHO) is sprintf().

I wish we could do this:

string myString=
double myValue=3.1415;

myString = The value of pi is:  + string(myValue) + \n;

I've had enough trouble with stringstreams that I don't want to go that path.

Jon


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


[Flightgear-devel] Properties, by position

2005-07-25 Thread Jon Berndt
In props.cxx I find this code:

  /**
   * Get a child node by position (*NOT* index).
   */
  SGPropertyNode * getChild (int position);


Can anyone differentiate for me the concept of position as contrasted to 
index in this
situation?

Jon


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


RE: [Flightgear-devel] jsbsim won't start with w110n40 or w110n30airports

2005-07-25 Thread Jon Berndt
 I don't know if there are others that use fgfs from front range 
 locations in Colorado, but I use it to practice instrument approaches in 
 this my home area and my two favorite aircraft for this are the c172p 
 and c310, both jsbsim models.  _The yasim aircraft still work fine with 
 this scenery._  By the way, I downloaded both w110n30.tgz and 
 w110n40.tgz and reinstalled both with no change to this bug.  I have not 
 seen this issue with airports not from these scenery files.
 
 This bug showed up about 10 days ago with an update from cvs.  Any ideas 
 what is broken?
 
 Regards,
 Dave Perry

I've got a hunch. Dave Culp may have an idea. I'll take a look, too.

Thanks,

Jon


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


[Flightgear-devel] sprintf

2005-07-25 Thread Jon Berndt
IIRC, sprintf was a problem for some. Is that still the case? I've compiled 
under Cygwin,
Borland C++, and I think I've also compiled code that uses sprintf under IRIX.

Jon


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


RE: [Flightgear-devel] New super/turbo MP code is in

2005-07-18 Thread Jon Berndt
 All the 3350s had this turbo/super setup. You can see it in some of
 these images:


http://www.enginehistory.org/GjJBrossett/RAFCosford/Wright%20Cyclone%20R-3350%20cutaway.J
PG

http://www.enginehistory.org/GjJBrossett/RAFCosford/Wright%20Cyclone%20R-3350%20cutaway%2
0view.JPG
 http://www.saunalahti.fi/sariri/Img/UKRAFC05/Eng/slides/P2060078.html
 http://www.midwaysailor.com/eddiemiller/eddiemiller-761b.jpg



** Please ** trim your quotes.

Also, for sending emails in text mode that include long links, you might try 
going to
www.tinyurl.com and making shorter links to include in emails.

Jon


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


RE: [Flightgear-devel] New super/turbo MP code is in

2005-07-18 Thread Jon Berndt
 But that's not the only way to do it.  I've been preparing a series of
 articles on supercharging reciprocating engines.   Is there any
 interest for me to pull some of it out and present it here?

 --
 Pete Stickney

Hmm. This might be interesting for the next issue of the JSBSim newsletter, 
Back of the
Envelope - even if it is not strictly JSBSim-related.

Jon


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


RE: [Flightgear-devel] Diamond Katana model

2005-07-17 Thread Jon Berndt
 Hi, folks,
 
 I'm trying to build a Katana model (the flight model, at least) so I don't
 have to perpetually terrorize the airfield's neighbors and my CFI while I
 practice touch  go's.  I went through the Aero-Matic and came out with a
 starting set of files, which I've been combing through and changing where
 appropriate.  I can't find a reference for the properties in the 'metrics'
 element, however.  Can anyone tell me what they are?
 
 I also see a lot of 'coefficient' elements in there, a number of which
 look important to someone landing a plane (dCLflap -
 Delta_Lift_due_to_flaps, for instance, looks rather important).  Anyone
 know where these might be published, if at all?
 
 Thanks!
 
 -joe

I'm going to forward this one to the JSBSim list and answer it there sometime 
today.

Jon


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


RE: [Flightgear-devel] how do I access GetCoefficientValuesfromFGAerodynamics?

2005-07-06 Thread Jon Berndt
 With the potential of exposing my C++ knowledge deficiency, I'll explain how
 far I got ;-)
 As mentioned in the last post, I have two variables I can access through the
 existing code I have.
 One variable is cur_fdm_state which is of type FGInterface. FGInterface is a
 parent class of JSBSim so accessing accessing the said 'get_fdmex()' method
 isn't easily done. I tried declaring a virtual method in FGInterface and
 defining it in JSBSim, but this only got ugly. The other variable is
 'globals', but I haven't had much luck here either.
 With your knowledge of flightgear, do you know if it is possible to access
 methods from the JSBSim object via either of these variables? If so, could
 you provide suggestions?

In FGJSBSim (the JSBSim object derived from FGInterface) there is a private 
member called
Aerodynamics that points to the FGAerodynamics object of JSBSim. If you have 
your own
cur_fdm_state object, however, the Aerodynamics object won't be accessible 
unless you
change the Aerodynamics object to be protected instead of private, or unless 
you provide a
getter such as GetAerodynamics() that returns the pointer to the Aerodynamics 
object.
Then, you could simply do:

my_string = cur_fdm_object-Aerodynamics-GetCoefficientStrings(delimiter);

-or-

my_string = cur_fdm_object-GetAerodynamics()-GetCoefficientStrings(delimiter);

 With the other option of using the XML file, could you give me an example of
 how the values would be retrieved?

  output name=localhost type=SOCKET port=1139 rate=10
  coefficients ON /coefficients
  /output

If you were to do the above (i.e. place it in your aircraft config file) you 
would have to
have a listening socket somewhere ready to receive the data. In another shell 
window you
could type:

nc -l -p 1139

to listen to the data output by the sim. I've only done this with JSBSim 
standalone - not
with FlightGear.

Jon


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


RE: [Flightgear-devel] how do I access GetCoefficientValues fromFGAerodynamics?

2005-07-05 Thread Jon Berndt
 Can anyone suggest a way of accessing the methods:
 GetCoefficientValues(...) and
 GetCoefficientStrings(...)
 from a --native socket?

 I have a piece of code within flightgear which uses 'globals' and
 'cur_fdm_state' via a socket similar to the --native socket
 provided with flightgear.
 I'd need to access internal JSBSim data but am at a loss how to
 do it from that socket.

 any suggestions?

You can access JSBSim aero data via properties if you know the property names. 
Problem is,
the aero properties are sort of internal, and there's not a simple way (that I 
know of) to
get all aero properties. So, I see you want to try (from FlightGear) to get the 
strings
via the FGAerodynamics calls. To do that, you'd need to know the FGFDMExec 
pointer in the
interface (FGJSBSim). The value you need is a private attribute, fdmex. You 
could add a
getter for that, GetExec(), perhaps. Then you could use that:

my_string = GetExec()-GetAerodynamics()-GetCoefficientStrings(delimeter);

I haven't tried this, but I think this should work. Is this what you are 
looking for?

On the other hand, JSBSim does have a socket output capability, too. Using the 
new code
(almost ready for commit to FlightGear CVS) you could do the following and get 
all aero
properties:

output name=localhost type=SOCKET port=1139 rate=10
coefficients ON /coefficients
/output

The above would go in your aircraft config file at the bottom.

I'll be glad to clarify this if you need more info.

Jon

--

Project Coordinator
JSBSim Flight Dynamics Model
http://www.jsbsim.org



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


[Flightgear-devel] Strange goings-on: Simgear, ReadXML

2005-07-01 Thread Jon Berndt
I've noticed two things about easyXML.cxx.


1)

There is a function or macro called sg_io_exception(). This exception gets 
thrown in my
development version due to an as-yet unidentified problem with readXML(). 
However, the
message that emanates from FlightGear is simply:

FlightGear aborting

That doesn't seem right, given the arguments passed into sg_io_exception. Is 
there a
compile setting, runtime option, or environment variable that needs to be set 
in order to
get useful error messages out of simgear-thrown exceptions?

2)

ReadXML() (easyxml.cxx) contains code that is exhibiting apparently wierd 
behavior.
readXML() takes an input stream reference as an argument (among other things), 
and from
within a while loop, reads from the input stream. However, prior to reading 
from the input
stream, a check for the state of the input stream is made:

if (!input.good())
  // print message and throw

For some reason when the engine files is read for a JSBSim aircraft (and using 
the new XML
code) this check returns false and funnels execution through the thrown 
exception code. I
have checked, and the path name is valid, the XML engine spec is valid, the file
permissions are OK, the file is not corrupt, etc. In addition, this failed 
check for
input.good() occurs before any IO occurs. input.good() should return true if 
the FAIL bit
is not set, the EOF flag is not set, and the BAD bit is not set (as I recall). 
I have not
yet found why the state of the input stream is bad, but this is very strange and
frustrating.

Jon


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


[Flightgear-devel] Strange goings-on: Simgear and easyXML

2005-07-01 Thread Jon Berndt
I've noticed two things about easyXML.cxx.

1)

There is a function or macro called sg_io_exception(). This exception gets 
thrown in my
development version due to an as-yet unidentified problem with readXML(). 
However, the
message that emanates from FlightGear is simply:

FlightGear aborting

That doesn't seem right, given the arguments passed into sg_io_exception. Is 
there a
compile setting, runtime option, or environment variable that needs to be set 
in order to
get useful error messages out of simgear-thrown exceptions?

2)

ReadXML() (easyxml.cxx) contains code that is exhibiting apparently weird 
behavior.
readXML() takes an input stream reference as an argument (among other things), 
and from
within a while loop, reads from the input stream. However, prior to reading 
from the input
stream, a check for the state of the input stream is made:

if (!input.good())
  // print message and throw

For some reason when the engine files is read for a JSBSim aircraft (and using 
the new XML
code) this check returns false and funnels execution through the thrown 
exception code. I
have checked, and the path name is valid, the XML engine spec is valid, the file
permissions are OK, the file is not corrupt, etc. In addition, this failed 
check for
input.good() occurs before any IO occurs. input.good() should return true if 
the FAIL bit
is not set, the EOF flag is not set, and the BAD bit is not set (as I recall). 
I have not
yet found why the state of the input stream is bad, but this is very strange and
frustrating.

Jon


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


[Flightgear-devel] Strange goings-on: Simgear and easyXML

2005-07-01 Thread Jon Berndt
I've noticed two things about easyXML.cxx.


1)

There is a function or macro called sg_io_exception(). This exception gets 
thrown in my
development version due to an as-yet unidentified problem with readXML(). 
However, the
message that emanates from FlightGear is simply:

FlightGear aborting

That doesn't seem right, given the arguments passed into sg_io_exception. Is 
there a
compile setting, runtime option, or environment variable that needs to be set 
in order to
get useful error messages out of simgear-thrown exceptions?

2)

ReadXML() (easyxml.cxx) contains code that is exhibiting apparently weird 
behavior.
readXML() takes an input stream reference as an argument (among other things), 
and from
within a while loop, reads from the input stream. However, prior to reading 
from the input
stream, a check for the state of the input stream is made:

if (!input.good())
  // print message and throw

For some reason when the engine files is read for a JSBSim aircraft (and using 
the new XML
code) this check returns false and funnels execution through the thrown 
exception code. I
have checked, and the path name is valid, the XML engine spec is valid, the file
permissions are OK, the file is not corrupt, etc. In addition, this failed 
check for
input.good() occurs before any IO occurs. input.good() should return true if 
the FAIL bit
is not set, the EOF flag is not set, and the BAD bit is not set (as I recall). 
I have not
yet found why the state of the input stream is bad, but this is very strange and
frustrating.

Jon


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


[Flightgear-devel] test

2005-07-01 Thread Jon Berndt
test

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


RE: [Flightgear-devel] readXML problems

2005-06-30 Thread Jon Berndt
Here's an update to what I've discovered - hopefully someone can give me a hint 
on some
questions I have.

First, I've added some output statements in easyxml.cxx, in this version of the 
readXML()
function:

---
-- start --
---

void
readXML (istream input, XMLVisitor visitor, const string path)
{
  XML_Parser parser = XML_ParserCreate(0);
  XML_SetUserData(parser, visitor);
  XML_SetElementHandler(parser, start_element, end_element);
  XML_SetCharacterDataHandler(parser, character_data);
  XML_SetProcessingInstructionHandler(parser, processing_instruction);


  visitor.startXML();

  char buf[16384];
  while (!input.eof()) {
cout  A-1  endl;

if (!input.good()) {
cout  A-2  endl;

  XML_ParserFree(parser);
cout  A-3  endl;

  throw sg_io_exception(Problem reading file,
sg_location(path,
XML_GetCurrentLineNumber(parser),
XML_GetCurrentColumnNumber(parser)),
SimGear XML Parser);
cout  A-4  endl;

}

---
--  end  --
---

The above code fails when called from the JSBSim Load() function on FGPropulsion
(simplified):

---
-- start --
---

  Element* engine_element = el-FindElement(engine);

  while (engine_element) {
engine_filename = engine_element-GetAttributeValue(file);
...
engine_file_parser = new FGXMLParse();
engine_filename = FindEngineFullPathname(engine_filename);
readXML(engine_filename, *engine_file_parser);
...
Element* engine_element = el-FindNextElement(engine);
  }
---
--  end  --
---

When I run FlightGear I get this:

 A-1
 A-2
 A-3
 FlightGear aborting

And that's all I get. I'm wondering why I don't get a message from the thrown 
simgear
exception? Why would input.good() return false?

Let me restate that this all works fine in JSBSim standalone.

Jon


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


RE: [Flightgear-devel] readXML problems

2005-06-30 Thread Jon Berndt
  void
  readXML (istream input, XMLVisitor visitor, const string path)
  {
XML_Parser parser = XML_ParserCreate(0);

  ...

XML_ParserFree(parser);
  cout  A-3  endl;
 
throw sg_io_exception(Problem reading file,
  sg_location(path,
  XML_GetCurrentLineNumber(parser),


 What happens to parser after the call to XML_ParserFree(parser)?  Can it still
 be referenced after that?

 Dave

That's interesting. I wonder. Still, I think the problem is occurring earlier, 
because for
some reason the check for input.good() is returning bad. I have no idea why.

Jon


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


RE: [Flightgear-devel] readXML problems

2005-06-30 Thread Jon Berndt
  void
  readXML (istream input, XMLVisitor visitor, const string path)
  {


  engine_filename = FindEngineFullPathname(engine_filename);
  readXML(engine_filename, *engine_file_parser);


 The parameters don't match up for one thing.  engine_filename is a string?

 Dave


Sorry - there's an intermediate step. Propulsion calls readXML with a string 
filename,
then another variation of readXML() is called with the input stream. Everything 
executes
fine up until call to readXML(istream ...

The item I see as most suspect now is the false result from the call to 
input.good().

Jon


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


[Flightgear-devel] readXML problems

2005-06-28 Thread Jon Berndt
I'm continuing to install the new JSBSim code. I've run into a strange problem. 
After I
start up FlightGear and begin to parse an aircraft, I'll be humming along just 
fine until
I get to the point where the engine file is specified. When the engine file is 
specified,
it causes the file to be opened and read using a call to the easyXML routine, 
readXML().
It's the same routine, of course, that is being used to successfully parse the 
main
aircraft config file. This works fine in JSBSim standalone, but in FlightGear, 
when this
second call to readXML() is made, the program dies:

FlightGear aborting

I'm wondering if I missed something in the build process?

Jon


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


RE: [Flightgear-devel] help: .cxx extension not processed inMakefile.am

2005-06-28 Thread Jon Berndt
 As far as I know, none. This is the first time I heard of this behavior
   ?!??

 Erik

It's frustrating as hell. I don't see that I am doing much different from the 
Makefile.am
from the previous build.

Jon


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


RE: [Flightgear-devel] readXML problems

2005-06-28 Thread Jon Berndt
 I'm continuing to install the new JSBSim code. I've run into a strange 
 problem. After I
 start up FlightGear and begin to parse an aircraft, I'll be humming along 
 just fine
until
 I get to the point where the engine file is specified. When the engine file is
specified,
 it causes the file to be opened and read using a call to the easyXML routine, 
 readXML().
 It's the same routine, of course, that is being used to successfully parse 
 the main
 aircraft config file. This works fine in JSBSim standalone, but in 
 FlightGear, when this
 second call to readXML() is made, the program dies:

 FlightGear aborting

 I'm wondering if I missed something in the build process?

 Jon

Here's my call to readXML:

--- start ---

bool FGPropulsion::Load(Element* el)
{
  string type, engine_filename;
  Element* document;
  FGXMLParse *engine_file_parser;
  ifstream* engine_file;

  Element* engine_element = el-FindElement(engine);
  while (engine_element) {
engine_filename = engine_element-GetAttributeValue(file);

if (!engine_filename.empty()) {
  engine_file = FindEngineFile(engine_filename);
  if (!engine_file-is_open()) {
return false;
  }
} else {
  cerr  Engine definition did not supply an engine file.  endl;
  return false;
}

engine_file_parser = new FGXMLParse();
readXML(*engine_file, *engine_file_parser); // -- dies here

--- end ---

Anyone else out there use readXML()?

Jon


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


RE: [Flightgear-devel] readXML problems

2005-06-28 Thread Jon Berndt
 Norman Vine wrote:
  Erik Hofman writes:
 
 Are you calling readXML while another call to readXML is in progress?
 
 
  Can't be done unless this other call is in a different thread :-)

 Hmm, that makes sense. I had the detached method of reading XML files
 (non-easyXML) in mind where you had to do everything yourself.

 Erik

I'm doing it in standalone JSBSim (calling readXML from within another 
readXML()). I
thought you simply had to provide new arguments. Why would it work perfectly in 
standalone
JSBSim, but not within FlightGear?

I could probably get around that, but it would require some tedious re-work.

Jon


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


RE: [Flightgear-devel] readXML problems

2005-06-28 Thread Jon Berndt
Erik: Are you calling readXML while another call to readXML is in progress?

Norman: Can't be done unless this other call is in a different thread :-)

Jon:

 I'm doing it in standalone JSBSim (calling readXML from within another 
 readXML()). I
 thought you simply had to provide new arguments. Why would it work perfectly 
 in
 standalone JSBSim, but not within FlightGear?

Doh!!! Of course Norman is right - and JSBSim is not calling ReadXML() while 
another call
to readXML() is in progress.

I still don't know what could be causing our abort, though. In standalone 
JSBSim we use
our own compiled easyXML and eXpat code - though I would assume it's the same 
code SimGear
uses. When building with FlightGear we resolve the references at link time with 
the
simgear libs like everyone else. Seemed to work fine. Until it died when called 
from the
propulsion loading code.

Jon


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


RE: [Flightgear-devel] Linking order problems?

2005-06-27 Thread Jon Berndt
 Obviously, this doesn't seem optimal. I'm not sure how I could possibly
 arrange the files so there is only a single link reference to each library.
 Yet, I don't know how I should modify the Makefile.am to produce a multiplely-
 referenced library - or even if that is possible.

 Jon

I wonder if I ought to try the same order that is used (successfully) in the 
JSBSim
standalone build process? That's as follows:

--- start ---
JSBSim_DEPENDENCIES = \
   $(top_builddir)/src/libJSBSim.a \
   $(top_builddir)/src/initialization/libInit.a \
   $(top_builddir)/src/models/libModels.a \
   $(top_builddir)/src/models/flight_control/libFlightControl.a \
   $(top_builddir)/src/models/atmosphere/libAtmosphere.a \
   $(top_builddir)/src/models/propulsion/libPropulsion.a \
   $(top_builddir)/src/input_output/libInputOutput.a \
   $(top_builddir)/src/math/libMath.a \
--- end ---

As I recall, though, link order has not been terribly important in JSBSim 
standalone. Why
should it be different in FlightGear?

Jon


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


[Flightgear-devel] New JSBSim Config File Format Partial Documentation Online

2005-06-27 Thread Jon Berndt
I've placed an early copy of the new JSBSim config file format documentation 
online. It's
incomplete, but I thought it was better to get something out there than wait 
until it's
all done.

You can find it here:

http://www.jsbsim.org/Overview.pdf

Comments welcome.

Jon


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


[Flightgear-devel] RE: New JSBSim Config File Format Partial Documentation Online

2005-06-27 Thread Jon Berndt
 You can find it here:
 
 http://www.jsbsim.org/Overview.pdf
 
 Comments welcome.

Note, however, that rate_groups are not yet implemented for the flight 
control system.

Jon

___
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


[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_stringchar, std::char_traitschar,
std::allocatorchar )'
../../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 

RE: [Flightgear-devel] Re: New turbo/supercharger code

2005-06-25 Thread Jon Berndt
 That all looks very good. Does your implementation of the Boost Control just
 control the pressure, or does it act on the throttle as I understand was the
 way it worked in the Merlin? In simulation terms the outcome is probably the
 same.

 V.

Hi, Vivian:

That would be a question for Dave Luff, who wrote that engine model for JSBSim. 
If I had
time I'd look at the FGPiston.cpp code, but I've got really limited time today 
and
tomorrow; I'm getting the new JSBSim code integrated with FlightGear, among 
other things
I've got to do.

The last post I see from Dave was about 6 months ago on the JSBSim list.

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-25 Thread Jon Berndt
 Beware instrument failure !
 C172r  and others aircraft have a turn coordinator out of order  :=(
 seems to be property:
 /instrumentation/turn-indicator/indicated-turn-rate

I noticed that. I wonder when that happened?

Jon


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


RE: [Flightgear-devel] Re: New turbo/supercharger code

2005-06-24 Thread Jon Berndt
 Thanks, 
 My question could be a question to Jon, Dave, and any JSB specialist.
 I just wonder, about, the opportunity to get profit of your work for
 developments on the JSB branch. The properties should be the same  on
 the global FG level.  
 Both FDM -YASim -JSBSim with a different philosophic approach should
 give the same end results.
  
 -- 
 Gerard

See the FGPiston.h file in JSBSim. See the constructor in FGPiston.cpp for 
exact specification in the new XML format (documentation pending). Here is some 
data on what can be specified:

Models Dave Luff's Turbo/Supercharged Piston engine model.
Additional elements are required for a supercharged engine.  These can be
left off a non-supercharged engine, ie. the changes are all backward
compatible at present.

- NUMBOOSTSPEEDS - zero (or not present) for a naturally-aspirated engine,
  either 1, 2 or 3 for a boosted engine.  This corresponds to the number of
  supercharger speeds.  Merlin XII had 1 speed, Merlin 61 had 2, a late
  Griffon engine apparently had 3.  No known engine more than 3, although
  some German engines apparently had a continuously variable-speed
  supercharger.

- BOOSTOVERRIDE - whether the boost pressure control system (either a boost
  control valve for superchargers or wastegate for turbochargers) can be
  overriden by the pilot.  During wartime this was commonly possible, and
  known as War Emergency Power by the Brits.  1 or 0 in the config file.
  This isn't implemented in the model yet though, there would need to be
  some way of getting the boost control cutout lever position (on or off)
  from FlightGear first.

- The next items are all appended with either 1, 2 or 3 depending on which
  boost speed they refer to, eg RATEDBOOST1.  The rated values seems to have
  been a common convention at the time to express the maximum continuously
  available power, and the conditions to attain that power.

- RATEDBOOST[123] - the absolute rated boost above sea level ambient for a
  given boost speed, in psi.  Eg the Merlin XII had a rated boost of 9psi,
  giving approximately 42inHg manifold pressure up to the rated altitude.

- RATEDALTITUDE[123] - The altitude up to which rated boost can be
  maintained.  Up to this altitude the boost is maintained constant for a
  given throttle position by the BCV or wastegate.  Beyond this altitude the
  manifold pressure must drop, since the supercharger is now at maximum
  unregulated output.  The actual pressure multiplier of the supercharger
  system is calculated at initialisation from this value.

- RATEDPOWER[123] - The power developed at rated boost at rated altitude at
  rated rpm.

- RATEDRPM[123] - The rpm at which rated power is developed.

- TAKEOFFBOOST - Takeoff boost in psi above ambient.  Many aircraft had an
  extra boost setting beyond rated boost, but not totally uncontrolled as in
  the already mentioned boost-control-cutout, typically attained by pushing
  the throttle past a mechanical 'gate' preventing its inadvertant use. This
  was typically used for takeoff, and emergency situations, generally for
  not more than five minutes.  This is a change in the boost control
  setting, not the actual supercharger speed, and so would only give extra
  power below the rated altitude.  When TAKEOFFBOOST is specified in the
  config file (and is above RATEDBOOST1), then the throttle position is
  interpreted as:

- 0 to 0.95 : idle manifold pressure to rated boost (where attainable)
- 0.96, 0.97, 0.98 : rated boost (where attainable).
- 0.99, 1.0 : takeoff boost (where attainable).

A typical takeoff boost for an earlyish Merlin was about 12psi, compared
with a rated boost of 9psi.

It is quite possible that other boost control settings could have been used
on some aircraft, or that takeoff/extra boost could have activated by other
means than pushing the throttle full forward through a gate, but this will
suffice for now.

Note that MAXMP is still the non-boosted max manifold pressure even for
boosted engines - effectively this is simply a measure of the pressure drop
through the fully open throttle.


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


RE: [Flightgear-devel] FGFS 0.9.8 Compilation Error #2

2005-06-22 Thread Jon Berndt
 [EMAIL PROTECTED] wrote:
   I typed make and I got the following error:
 
   FGNozzle.cpp: In method 'JSBSim::FGNozzle(JSBSim::FGFDMExec *,
   JSBSim::FGConfigFile *, int =0)':
 
   FGNozzle.cpp:74: implicit declaration of function 'int
   JSBSim::snprintf(..)'
 
   Does someone knows what is wrong?

 Platform?  Compiler?  As always, more information is better than less.
 Surely you did more than just type make to get this far. :)

Yes, this is important. If you grep our source code (JSBSim) you'll see this in 
some
places (notably FGFCS.cpp):

 #if defined(WIN32)  !defined(__CYGWIN__)
 #  define snprintf _snprintf
 #endif

I remember there is an issue with snprintf(), I just can't remember the details 
offhand,
nor why the above fix seems to work.

As a WAG, you might try adding the above three lines to the top of FGNozzle.cpp.

Jon


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


RE: [Flightgear-devel] FlightGear Wind and Turbulence

2005-06-20 Thread Jon Berndt
 I used this command line:

 fgfs [EMAIL PROTECTED] --aircraft=c172r --turbulence=0.0

 This set up the winds as I wanted. However, even though turbulence was set 
 to zero,
 there was still lots of noise present in the wind velocity coming from 
 FlightGear. The
 wind seemed to vary +/- 5 to 10 ft/sec. Also, the variance rate of chance was 
 on the
order
 of tens of milliseconds. I was logging data at 20Hz, and at one time step the 
 wind
 velocity would be at 10 ft/sec, the next it would be at 20, and the next it
 would be back at 10. Obviously, that's physically impossible.

 Jon

Never mind  :-/  The spikes I was seeing were artificial, and due to the test 
setup I was
using.

Jon


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


[Flightgear-devel] Property Manager enumeration of properties

2005-06-20 Thread Jon Berndt
Is anyone aware of a [simple?] way to print out the property tree once it has 
been
populated? It seems to me that there ought to be a class attribute in the 
property manager
somewhere that is a pointer to a linked list, or a vector, or whatever, that 
contains the
properties, each of which may contain it's own child properties. No?

Jon


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


[Flightgear-devel] Short Reference Document error?

2005-06-19 Thread Jon Berndt
This short reference:

http://www.flightgear.org/Docs/FGShortRef.pdf

shows the rudder control on the numeric keypad as being the 0 and , (comma) 
keys. There
is no comma on the numeric keypad. This is confusing.

Jon


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


[Flightgear-devel] Landing Gear Jitters: Resolved?

2005-06-19 Thread Jon Berndt
I am testing out a small preliminary fix for the landing gear jitter seen in 
various
JSBSim aircraft. Curt has relayed that the default C-172 does have this problem 
- and I
have now seen that. The preliminary fix does seem to have fixed that, although 
when brakes
are applied while at rest there is some weird dynamics going on. I think I can 
fix that,
too. So, I believe we are well on our way to having the appearance of a much 
better gear
action. I hope I can get this resolved in the next day or two.

Which of the JSBSim models show this problem most noticeably, besides the 
default C-172?

Jon


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


RE: [Flightgear-devel] FlightGear Wind and Turbulence

2005-06-19 Thread Jon Berndt
 What does FlightGear do in the way of wind and turbulence? I assume that winds
 are set in
 FlightGear in NED coordinates and that those change slowly? Turbulence is 
 modeled in the
 FDMs, but parameters are passed in? FlightGear does not model turbulence
 itself, does it?


What is WEATHER_CM? I am looking in JSBSim.cxx and wonder what the defined 
WEATHER_CM is
set to by default. I'm determining which code is compiled in in the atmosphere 
code.

Jon


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


RE: [Flightgear-devel] FlightGear Wind and Turbulence

2005-06-19 Thread Jon Berndt
 I am debugging the gear jittering in JSBSim and I am seeing
 windNED spike every so often and I have commented out turbulence
 code in JSBSim, so I am wondering if these wind spikes are
 coming from FlightGear.

OK, in working to fix the gear jitter I've discovered some things about the 
winds modeled
in FlightGear.

I used this command line:

fgfs [EMAIL PROTECTED] --aircraft=c172r --turbulence=0.0

This set up the winds as I wanted. However, even though turbulence was set to 
zero,
there was still lots of noise present in the wind velocity coming from 
FlightGear. The
wind seemed to vary +/- 5 to 10 ft/sec. Also, the variance rate of chance was 
on the order
of tens of milliseconds. I was logging data at 20Hz, and at one time step the 
wind
velocity would be at 10 ft/sec, the next it would be at 20, and the next it 
would be back
at 10. Obviously, that's physically impossible.

Can someone shed some light on FlightGear's modeling of winds and turbulence?

BTW, I'm using current code out of FlightGear CVS.

Jon


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


RE: [Flightgear-devel] Re: FlightGear Wind and Turbulence

2005-06-19 Thread Jon Berndt
 WeatherCM is the old weather system that has been removed from
 cvs for fgfs 0.9.4. It's in the old repository's hidden Attic/. I
 think it's safe to remove all traces to it.
 
 m.

Thanks. Will do. That simplifies looking at the code.

Jon


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


RE: [Flightgear-devel] Short Reference Document error?

2005-06-19 Thread Jon Berndt
 So there's nothing wrong with it, it's just that every user has another kind
 of keyboard layout. ;)

 Best Regards,
  Oliver C.

Aha! Well, yes, I understand, now, but for newbies from the U.S. it will be 
wrong. I'll
modify the PDF and send it to Curt (or whoever maintains that doc). It needs to 
be clear.

Jon


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


RE: [Flightgear-devel] Re: Short Reference Document error?

2005-06-19 Thread Jon Berndt
 Modify the PDF? Of course, you mean the TeX source file from which it was
 generated, not the PDF itself, right? It's in the docs module.

 m.

I already modified the PDF (I have Acrobat). I didn't know where the doc came 
from
originally, and I don't know TeX.

If I have time later I'll take a look at the TeX file, too, though.

Jon


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


RE: [Flightgear-devel] Short Reference Document error?

2005-06-19 Thread Jon Berndt
 Aha ? In fact the notation in the cheat sheet _is_ correct and clear,
 why the hell do you want to break it ? It's just a matter of point of
 view an I assume there are _many_ FlightGear users out there that have
 a comma as a decimal separator - it's just that they probably don't
 live in the US.

I think you are making a disingenuous assumption, here, on what I am saying. It 
IS correct
and clear for*European*users, yes. All that I did to the PDF document was to 
add a _note_
in the appropriate section in brackets that says: [U.S. keyboards use . 
instead of
,]

Are you opposed, in principle, to providing U.S. users with accurate 
information? I don't
understand what's got you so hot about this. It's an international project. 
Let's be clear
for everyone.

Jon


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


RE: [Flightgear-devel] Tail dragger trouble.

2005-06-19 Thread Jon Berndt
 I have been trying to make the JSB flight model for my PA-25 pawnee for over
 a week now, however, I can not get it to steer on the ground.  Every time I
 start my take off roll the plane goes in circles.

 Has anybody encountered any similar problems?

I am working on trying to resolve the landing gear issues now. There are a 
couple of
aspects to this. I'll try and describe those later, as well as to provide some 
fixes.

Jon


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


RE: [Flightgear-devel] Short Reference Document error?

2005-06-19 Thread Jon Berndt
 So, you think the UK is part of Europe, eh? We use the same convention as
 the US for ./,

 Vivian.

Heh. :-) What's above the number 4 (not on the numeric keypad)? Is it a $ 
or a ?
(not sure that will print correctly)?

Jon


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


RE: [Flightgear-devel] Short Reference Document error?

2005-06-19 Thread Jon Berndt
 This complies entirely with my intention. Please excuse me for missing
 the point - from reading your comment I had the impression you simply
 changed the comma to a dot in the PDF. Please send me a copy of your
 PDF and I'll change the TeX source accordingly.

Thanks - will do.

 I'm currently thinking of some sort of a small FlightGear
 internationalization project to avoid such confusion. I'll comment of
 this the next day 

Sounds like a great idea.

Jon


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


RE: [Flightgear-devel] Native-Ctrls UDP packet structure

2005-06-18 Thread Jon Berndt
 bass pumped

 3.  I send 0s for all the other properties that I do not want to
 control.  I realize now that it was a bad idea...  the aircraft sits
 frozen (none of the usual JSBsim vibration either) on the runway.

Can you give me a good example case of where an aircraft is sitting on the 
runway and
jittering a lot? I know that problem existed at one point with the C-172, but 
it does not
seem to happen for me now. I have a possible fix I wanted to try out, so I need 
a good
example.

Jon



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


RE: [Flightgear-devel] Native-Ctrls UDP packet structure

2005-06-18 Thread Jon Berndt
 Can you give me a good example case of where an aircraft is sitting on the 
 runway and
 jittering a lot? I know that problem existed at one point with the C-172, 
 but 
 it does not
 seem to happen for me now. I have a possible fix I wanted to try out, so I 
 need a good
 example.
   
 
 The default c172 with default wind jitters all over the place if you let it 
 sit 
 for a few seconds.
 
 Curt.

With default wind ...

Has that been removed? I tried the default startup:

fgfs

a few days ago and let the C172 sit there. It seemed fine to me.

Jon


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


[Flightgear-devel] Cygwin and FlightGear startup

2005-06-18 Thread Jon Berndt
It's taking about 3 minutes to initialize FGFS under CygWin. I seem to recall a
conversation about that a few weeks ago. Is that something that is being 
worked, or can it
be resolved? Is there something I can do to my setup?

Jon


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


RE: [Flightgear-devel] SP_FMDS

2005-06-16 Thread Jon Berndt
 ..speaking of which; Are those Big-Overhaul-So-Lay-Off-cvs jobs
 done in the FG and JSBSim cvs trees?

Sorry. Yes. I thought I made a small announcement that I had gotten that taken 
care of.
Maybe not.

Jon


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


RE: [Flightgear-devel] OpenAL for CygWin

2005-06-14 Thread Jon Berndt
 I have placed a compiled tarball of yesterdays OpenAL CVS files @
 http://www.vso.cape.com/~nhv/files/cygwin/cyg_openAL.tgz

 you might want to test these against the current FGFS before
 blindly overwriting your currrent installation

Is this distribution modified for use with CygWin as discussed in this thread 
recently?
Namely, the _WIN32 - WIN32 issue, as well as the #define MVC?

I suspect these statements could be modified in OpenAL CVS to support CygWin 
without
trouble. Has anyone approached them about this? If not, I wonder if I ought to?

Jon


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


[Flightgear-devel] Gear jitter

2005-06-14 Thread Jon Berndt
I was looking at the gear jitter in the latest version of FlightGear with the 
current C172
(JSBSim). I didn't notice much jitter at all - really very little. Is that 
because winds
are off by default, now? Is there a particular setup where I can see it most 
noticeably? I
have a possible fix that I want to try out.

Jon

--

Project Coordinator
JSBSim Flight Dynamics Model
http://www.jsbsim.org



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


[Flightgear-devel] New JSBSim Branch

2005-06-13 Thread Jon Berndt
It appears as though JSBSim CVS is in a good state, with the new code, and new 
directory
structure.

Notes:

1) No attempt has yet been made to test this with FlightGear - that will take a 
little bit
of work. Things are different: the directory structure, the code, the aircraft 
config
files, etc.

2) I have only attempted to build this under Cygwin and Borland C++BuilderX.

3) Some aircraft, engine, script, etc. files have not been validated against 
the new
config spec.

4) Documentation for the new spec is forthcoming.

5) More information on the converter is pending.

Jon


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


RE: [Flightgear-devel] OpenAL for CygWin

2005-06-13 Thread Jon Berndt
 Hmmm ... we had to fiddle with it to make it work some months ago ... I
 forget exactly what we did

This seems really unfortunate for FlightGear - that we have to rely on another 
package
where some of us have to fix the code to work for CygWin users. Is this even 
documented
anywhere?

jon


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


RE: [Flightgear-devel] OpenAL for CygWin

2005-06-13 Thread Jon Berndt
 In the developers' list archives is the best we have. Cygwin wouldn't work
 at all if it were not for the excellent work by Norman Vine. There's no sign
 of OpenAL being ported to Cygwin at the moment, so this is the best we have.
 We are in constant danger of being left behind.

 Have you got it to work yet??? I guess I could tarball up my version here
 for you, when I have a bit more time.

Yes. I now have a FlightGear executable - though I won't have time to try it 
until this
evening at the earliest.

I'd like to submit the text below to a FAQ or wherever it should be on the
FlightGear/SimGear site:

--- start ---

For Cygwin users, OpenAL needs to be retrieved from this site:

ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/openal_cyg.tgz

I placed this file in the /usr directory and untar'ed it, though some place it 
in the
/usr/local/ directory tree - which might be more appropriate. Some library and 
dll files
are untar'ed into your bin/ and lib/ subdirectories.

Once the files are untar'ed, you must cd to the include/AL/ subdirectory and 
modify all
the files where _WIN32 is present (use grep) and change it to simply WIN32 
(that is,
remove the underscore). Also, in alc.h you must change the code at top to look 
like this:

#ifdef WIN32  --- CHANGE TO THIS
 #ifdef _OPENAL32LIB
  #define ALCAPI __declspec(dllexport)
 #else
  #define ALCAPI __declspec(dllimport)
 #endif

#ifdef WIN32 --- CHANGE TO THIS
 typedef struct ALCdevice_struct ALCdevice;
 typedef struct ALCcontext_struct ALCcontext;
#endif

Once these changes are made, you should be able to compile simgear.

--- end ---

Jon


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


  1   2   3   4   5   6   7   8   9   >