> Jonathan Polley writes:
> > I noticed that the latest version of main.cxx references a macro
> > SG_COMPILER_STR, which doesn't seem to be defined anywhere. Is this
> > suppose to be referencing SG_COMPILER from simgear/compiler.h?
>
> Ooops, my fault, missed committing a change. It should
> Are there any plans for adding support for the interesting bits of
> weather to this model? (ie, storms, realistic winds that actually
> relate to the rest of the weather model, etc)
Yes. We've got hooks in JSBSim to add in the effects of turbulence, but
the math model driver for turbulence can
> ? I don't see any harm in sticking with the integer value, but I
> agree that a better name, proper documentation, and some debugging is
> essential.
This is true - particularly about documentation. Inline comments would
help, too. I prefer (and we will continue to do this for JSBSim) that "d
> > This is ridiculous. "dt" is short for delta T. In a 100 Hz
> simulation, the
> > corresponding dt is 0.04. For 120 Hz it's 0.00833. For people that do
> > simulation for a living this is one of the *most* recognized
parameters
> > around.
>
> Jon almost assuredly meant dt = .01 for 100 Hz or d
> So, is dt recording elapse time or set to the current step time? If a
sharp
> programmer like Andy is getting confused about what dt really is, then
> perhaps the variable should be called "ms_elapsed" or "t_stepsize",
etc.?
This is ridiculous. "dt" is short for delta T. In a 100 Hz simulation,
I'd prefer to get away from using _snprintf, snprintf, or whatever. The
only reason we use them (IIRC) is to limit the length of an output string.
This can be done in other ways, such as using the string class. Since they
would not be used in performance critical areas, maybe that's an option?
Jo
> Jon Berndt writes:
>
> > can you use a sphere?
>
> That's a lot of triangles for each tree.
Oh, blast it! That's right. OGL has no "real" sphere.
Jon
smime.p7s
Description: application/pkcs7-signature
can you use a sphere?
> What about overhead? Should I plop one more rectangle on the top?
> You don't usually look straight down from a plane, but it will happen
> during aerobatics.
>
smime.p7s
Description: application/pkcs7-signature
> In order to test JSBSim compilation across different platforms, I've
been
> giving some initial thought to use of the sourceforge compile farm. Does
> anyone here have any experience with that? Good idea? No?
This *is* cool. I tried it: tried compiling JSBSim on the Mac. uname -a
returns:
Darw
In order to test JSBSim compilation across different platforms, I've been
giving some initial thought to use of the sourceforge compile farm. Does
anyone here have any experience with that? Good idea? No?
Jon
smime.p7s
Description: application/pkcs7-signature
> Curtis L. Olson writes:
>
> > What we have been referring to as the CG is a bit of misnomer. We
> > really want the FDM to produce the location of a *fixed* "reference
> > point" of the aircraft (in world coordinates).
>
> The FAA TCDS's call this the "reference datum". We might as well
> a
> Norman Vine wrote:
>
> Jonathan Polley writes:
> >
> >The biggest problem I see with C++ and the FAA is that it is VERY hard
to
> >guarantee that C++ will not do any dynamic memory allocation.
>
> Agreed -- this is the 'crux' of the issue for long running 'critical'
> software.
> AFAIK most of
> John Wojnaroski wrote:
> >
> > Do the FDMs account for the fact that the down aileron creates more
drag
> > than the up aileron thereby
> > creating a yawing moment about the z-axis?
>
> At least JSBSim should do this. It's in the aero data.
>
> Erik
Correct. If the flight test or analytical d
Do you think - just for grins - it might be worth making a post to the
rec.aviation.simulation newsgroup (land of MSFS and X-Plane talk)?
Jon
> For screen shots - if you don't mind my showing off a bit ;-)
>
> Night time - http://www.spiderbark.com/fgfs/u3anight.png
smime.p7s
Description: app
Wow. This is lookin' good. I surmise the extra reference points close up
will give a new perspective on flying the -310.
> For screen shots - if you don't mind my showing off a bit ;-)
Show off more. This is very inspiring. It's great PR, too.
> Night time - http://www.spiderbark.com/fgfs/u3ani
> I should point out that ...
>
> Many multihead capable video cards will only do 3D acceleration on the
main
> head. If the instrument panel is placed on the second head, it had
better
> use 2D GL calls. Therefore, the panel has to intrinsically be a 2D
database.
I had heard this before, so I
>On Behalf Of Cameron Moore
> What exactly do we want 1.0 to be? Here are some things I'd like to see
> in 1.0:
>
> - Runway lighting
> - Sane gear model in JSBSim
In work, as we "speak". Of course, this has been "in work" for months, and
is likely to continue to be for at least days if not wee
> > 3. Flaps in c172JSBsim still doesn't animate.
>
> JSBSim isn't reporting the flap position -- it's a JSBSim-specific bug
> (you should still see the flaps move with YASim).
Bug? This would surprise me as the aero effects are there. Could be that
we just haven't gotten around to providing a p
> I agree that this was how it was originally coded, but something has
> changed in the last week or so and the propellor definitely spins an
> order of magnitude slower than reported rpm.
Did someone get rps and rpm mixed up?? ;-)
smime.p7s
Description: application/pkcs7-signature
Can you describe your matrix?
Is this of any use to you?:
http://jsbsim.sourceforge.net/quaternions.html
> If someone shows me how to use my matrix directly, I'll do that. For
> now I've written a conversion function that I'll probably stick into my
> matrix class.
smime.p7s
Description: a
> Setting the environment variable __GL_SYNC_TO_VBLANK to a non-zero value
> will force glXSwapBuffers to sync to your monitor's vertical refresh
rate
> (perform a swap only during the vertical blanking period) on GeForce or
> newer hardware (ie: everything but TNT/TNT2 products).
>
> For windows
> The manual contains performance charts, detailed w&b breakdown
> and subsystem descriptions among other things.
>
> I hope I can be of help to get this plane into FlightGear. What I
> need is a postal address to mail the manual to, if anyone is interrested
in
>
> Let me know if this is of interr
> To be fair, however, what many people call "unflyable" around here isn't
> anywhere near the case. The most recent JSBSim complaint, for example,
> only took two clicks of keyboard aileron to correct at climbout speeds.
I was talking to a pilot friend of mine the other day. He was telling me
t
> The convention for moving models for flight simulation visual system
> is for the origin to be at the CG location for aircraft models. The
The *initial* CG location? The CG location can change.
Jon
smime.p7s
Description: application/pkcs7-signature
Sorry about that. I've got to find a darned editor that doesn't do that to
me. I'm guilty!
Jon
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Frederic
> Bouvier
> Sent: Thursday, April 11, 2002 6:03 AM
> To: FlightGear Development
> Subject: [Fli
> I wonder if the EAA would be willing to share their research data with
> the rest of us? Any EAA members here?
IIRC it's not the EAA that's sponsoring the research. I think the model
was tested extensively in the wind tunel at Langley.
http://quest.arc.nasa.gov/aero/wright/tunnels/
I am thin
> Why not translate nonlinear model of Pioneer to JSBSim?
Why not?
> http://amber.aae.uiuc.edu/~jscott/sis/models/
The data is all there. In fact, the model files the UIUC guys use present
pretty much the same information that JSBSim does. Perhaps someone could
write a translator? :-)
> I noti
These
items should not be limited, anyhow. Where is this done???
-Original Message-From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Jonathan
PolleySent: Monday, April 08, 2002 9:24 PMTo:
[EMAIL PROTECTED]Subject: [Flightgear-devel] MSVC
Still not Building
> Commercial or open source?
>
> Regards
> John W.
Very early stage demonstration of displays. We might have need for
something quick and dirty. This is all speculative. Might never pan out,
but I am trying to get my superiors interested for use as a tool for
potential future work.
Jon
smime.
If you are near a TV ... the shuttle goes up momentarily.
Jon
smime.p7s
Description: application/pkcs7-signature
> Jon mentioned something about using the glass displays for a possible
app?
> The program now has both file-based and command line initialization so
it's
> a bit more user friendly and the linux build is clean once the library
fonts
> are installed. And there is a short tutorial and install doc.
> > > from JSBSIm.cxx:
> > >
> > > FCS->SetLBrake( globals->get_controls()->get_brake( 0 ) );
//left
> > > FCS->SetRBrake( globals->get_controls()->get_brake( 1 ) );
//right
> > > FCS->SetCBrake( globals->get_controls()->get_brake( 2 ) ); //
center
> > --
> Do aircraft really have nose
Never mind. Seemed to work after I did:
1) Deletion of flightgear tree
2) recheck out
3) Surprise! JSBSim.[c|h]xx no longer in fgfs cvs! (??)
4) aclocal;autoconf;etc.
5) make
Jon
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Jon Bern
MAJOR FRUSTRATION MODE:
I did a complete checkout and rebuild of FlightGear. Again, it gets all
through compile and fails at the link stage. This is with a clean CVS
checkout.
fg_init.o(.text+0x4c57):fg_init.cxx: undefined reference to
`FGJSBsim::FGJSBsim(double)'
Is no one else seeing this?
> Right now our wheels are stored in an array. Is there anywhere that
> defines which position corresponds to which wheel ... something along
> the lines of:
>
> wheel[0] == nose
> wheel[1] == left
> wheel[2] == right
>
from JSBSIm.cxx:
FCS->SetLBrake( globals->get_controls()->get_brake(
> On Behalf Of Jon Berndt
>
> Got this error while linking latest flightgear from CVS:
>
> fg_init.o(.text+0x4c57):fg_init.cxx: undefined reference to
> `FGJSBsim::FGJSBsim(double)'
>
> Anyone else see this? I'm going to have a look now (I'm home today).
Got this error while linking latest flightgear from CVS:
fg_init.o(.text+0x4c57):fg_init.cxx: undefined reference to
`FGJSBsim::FGJSBsim(double)'
Anyone else see this? I'm going to have a look now (I'm home today).
Jon
smime.p7s
Description: application/pkcs7-signature
Try searching the nasa tech reports sites:
http://techreports.larc.nasa.gov
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Gene Buckle
> Sent: Monday, April 08, 2002 11:18 AM
> To: [EMAIL PROTECTED]
> Subject: [Flightgear-devel] [OT] Jon!
>
>
>
> > The property system currently publishes the value using US gallons,
> > but think that almost everyone agrees that using a volume measurement
> > is wrong, since volume is relative to temperature and air pressure.
>
> For the big iron, yes, but for small piston planes I personally think
> volu
We use pounds.
Jon
Jon S. Berndt
Coordinator,
JSBSim Project
http://jsbsim.sf.net
> Curtis L. Olson writes:
>
> > What units are we measuring fuel quantity in these days? If not
> > gallons, can someone give me a rough conversion from what we are
using
> > to gallons (ignoring issues such as
> You might check the property tree for any rudder or
> aileron biases. In other words, the cmd is zero and
> the pos is not.
Tony, are you seeing the roll?
smime.p7s
Description: application/pkcs7-signature
> approach. She then said '...and this is how we slow down in a
> hurry'. Adjusting the prop RPM lever and throttle to get us from
> 145 knots to 80 in around 4 seconds. Very impressive! Is this
> modelled in FGFS?
It *should* be, however we have a possible reported a bug in our propeller
model
> Give it another chance or four. You'll begin to enjoy it. If you've
got
> vertigo or motion sickness problems, a Drammamine tab probably wouldn't
> hurt before you take off.
I've been really lucky this way. When I was taking lessons some twenty
years ago one thing the instructor did was to pu
If someone wants to namespace-ize JSBSim this would be a nice thing to do.
I don't have time, myself.
Jon
smime.p7s
Description: application/pkcs7-signature
Wow. Thanks for the feedback. This is really the only _best_ way to making
sure the feel of the flight modeling is right - getting the qualitative
reports from many people is even better.
P-Factor is definitely one of those effects we need to adjust based on the
qualitative judgment of people who
> > We'll be glad to honor any sane request ...
> >
> > Recommendations?
>
> ..ignore planet Earth? Spool the movie back?
> Autofire big recoilless tunnel-maker gun?
Someone's been in the cold too long. ;-)
Jon
___
Flightgear-devel mailing list
> Curt hits the nail on the head --- I'd just like to continue on, and I
> ...
> crashes. Yes, I could restart, but it would be easier to plow along with
We'll be glad to honor any sane request ...
Recommendations?
Jon
___
Flightgear-devel mailing
> Ack, really? I was honestly under the impression that you were
> handing out the coordinate frame too; I thought I had checked this in
> code when writing YASim.
Perhaps this is related to the misunderstanding of our gear model and how we
determined where we were?
> Why c.g.? Since it moves,
> >for more information. The socket approach is nice for real
> >time stuff. Flightgear may have some or all (and more)
> >capabilities than this for logging, but perhaps not all of
> >the desired flight dynamics data is available that way.
> >
> Yes, It is.
> I would better if the socket appr
> like this feature too. The current deal where the aircraft freezes on
> crashes is not so handy to me. Why not have some sort of realism feature
> that at one extreme does not freeze on crashes and allows for some sort
of
> slew to altitude feature and then on the other extreme you've got to
The definition of a positive aileron deflection is when the right-hand
aileron deflects according to the right hand rule - that is, trailing edge
down (TED). Unfortunately, this results in a negative roll rate - it would
be nice if our choice of coordinate system caused a positive aileron
deflecti
It comes with FlightGear. Go to this page and read up on how to get the code
via anonymous CVS:
http://flightgear.sourceforge.net/cvsResources/anoncvs.html
Jon
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Julius
> Sent: Monday, April 01, 2002
> make[4]: Entering directory
> `/home/david/flightgear/FlightGear/src/FDM/JSBSim'
> c++ -DFGFS -I../../.. -I../../../src -I/usr/local/include
> - -I/usr/X11R6/include -g -O2 -D_REENTRANT -c JSBSim.cpp
> JSBSim.cpp: In method `bool FGJSBsim::copy_from_JSBsim()':
> JSBSim.cpp:530: no matching fun
> Could we please add a feature for the next release that allows
> FGFS to find
> the location of every person on earth and then render that on the
> scenery?
> Thanks,
>
> David
I think Norman already has a Python script to do this.
:-/
___
Fli
I saw this on OpenGL.org:
http://www.billardgl.de/index-en.html
It is an astoundingly real looking billiards game. Lots of fun.
Jon
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Well ...
I haven't built FGFS in a long while, but it sure looked good tonight. I
don't recall the lights looking so good. What has changed?
Jon
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgea
> So, I read the README.metakit. Eventually I'll find time to look into this
> new (to me) process, but until that time: can any CygWin users tell me if
> there are any roadblocks to building this successfully - any gotchas you
> have found?
Never mind. It was a total piece of cake.
Jon
__
> I hear there's Windows binaries on the FGFS website 8-)
I may try and build it, anyhow.
> Would it make things easier, long term, if the JSBSim core were to migrate
> into a shared library that is used by both the FGFS binary and
> the standalone JSBSim binary ?
Could be. But right now the co
I tried building FlightGear for the first time in months and months and
found that I failed at the "metakit not found" error with simgear. Aaarrghh!
Metakit?! So much for a quick and easy build.
So, I read the README.metakit. Eventually I'll find time to look into this
new (to me) process, but un
Behalf Of Norman VineSent:
Sunday, March 24, 2002 10:55 PMTo:
[EMAIL PROTECTED]Subject: RE: [Flightgear-devel]
Problems Building JSBSim using MSVC 6.0
FGFilter.cpp: In method `void
FGFilter::Debug(int)':FGFilter.cpp:224: warning: use proper
indentationFGFilter.cpp:224: warning: you
> > Assuming Jon does not object, I will accept patches that look like the
> > above.
>
> Okay, I'll make the changes to the current JSBSim cvs snapshot (not the
> one in FlightGear) and send you the patches. However I might try a
> typedef instead of a macro.
I'm not quite ready to "not object
Any chance someone could post a screen shot???
Jon
> [mailto:[EMAIL PROTECTED]]On Behalf Of David
> Megginson
>
> I've just checked in Jim's latest viewer improvements and I encourage
> everyone to update the main source tree and the base package, then try
>
> fgfs --aircraft=c172-3d
___
> from: [EMAIL PROTECTED]
You aren't at Flight Dynamics division, are you?
> error. Does specifying '--pedantic' on the gcc command line cause any
> other warnings?
> Jonathan Polley
If I try using the --pedantic option I get this:
--- start --
g++ -I../ --pedantic -Wall -oFGD
> > Adding an ugly cast fixes the problem:
> >
> > PropertyManager->Tie("forces/fbx-aero-lbs", this,1,
> > (double (FGAerodynamics::*)(int) const) &FGAerodynamics::GetForces);
>
> I'll roll that change into my copy until it gets made permanently. While
We'll do a little investigating, fir
> Compiling...
> FGAerodynamics.cpp
> c:\src\flightgear\src\fdm\jsbsim\fgaerodynamics.cpp(229) : error C2661:
> 'Tie' : no overloaded function takes 4 parameters
>
> Adding an ugly cast fixes the problem:
>
> PropertyManager->Tie("forces/fbx-aero-lbs", this,1,
> (double (FGAerodynamics::*)(i
> > Tony -
> >
> > Did you come up with any recommendations on what we should do
> with inlining
> > given your test results?
>
> Not really, I was just after trying to find out how much inlining is
> worth to us.
>
> It did look like we might benefit from un-inlining some of the tied
> methods, t
> I have to back off of the 15 minutes I quoted earlier -- that was
> running over NFS, and with other stuff hammering on the same drive.
> Still, it's quite clear that inlining is our problem here. The
> difference between inlined-but-optimized code and completely
> unoptimized code is only 13%,
> Try the version in FlightGear, not the standalone one. I think my
> theory about you guys having optimization disabled is sounding more
> correct. The one that gets built out of FlightGear's CVS uses the
> standard -O2 flag, and is dog slow.
OK, I ran a test using the -O2 setting just to see
> How about compile time? I've been meaning to bug you about this. :)
>
> The new version of FGState.cpp, as checked in a few days ago, takes
> five (!) minutes to build on my machine. Yikes. The whole of JSBSim
> is running well over 15 minutes of compile time now. Turning off
> optimization,
> The other possibility is that the new multi-FDM stubs are slowing
> things down, but that seems unlikely.
There's very little there that's being used - and nothing being used unless
it's defined in the config file as a multi-body sim.
Jon
___
Fligh
> The only way I can get SimGear to build is to replace
>
> SG_USING_STD(sort);
>
> with
>
> SG_USING_NAMESPACE(std);
>
> Nothing else seems to work. I have tried cleaning and rebuilding from
> scratch *multiple* times.
Are there any other stdlib function calls in there from std namespace?
Is this with the most recent JSBSim? Tony made some changes related to
properties and perhaps there is some tweaking to do.
Jon
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Martin Spott
> Sent: Thursday, March 21, 2002 5:30 AM
> To: [EMAIL PROTE
What was the RPM reading?
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Jim Wilson
> Sent: Wednesday, March 20, 2002 10:44 PM
> To: [EMAIL PROTECTED]
> Subject: [Flightgear-devel] c310 lawn dart
>
>
> With the newly accessible JSBSim properties I
>
> nhv@SFDEV3::/src/FlightGear% time ./bootstrap.sh
> ..
> real19m42.347s
> user17m30.419s
> sys 2m18.101s
>
> So it looks like < 20 minutes is a reality on somewhat 'modest' machines
> And Cygwin is a slow poke :-)
>
> FWIW_2 with above tricks for optimized YASIM build ti
> --- David Megginson <[EMAIL PROTECTED]> wrote:
> > Tony Peden has been working quietly for the last couple of weeks
> > incorporating the property manager into JSBSim itself.
Quietly!? I'll say. This is the first I've heard of it.
just kidding.
Yes, he's done some good stuff. This is cool. Pl
> > I'm not familiar with our XML parser, but could we get away with using
> > this instead?:
> >
> >
>
> In other words, you'd like
>
>
I've had some thoughts along those lines, too. Note that I am not so
familiar with proper XML, but I wondered if this might be legal or
advisable,
In
> I had been concerned
> that SGPropertyNode::getDoubleValue was showing up at the top of the
> profiling output for JSBSim, but I think that that was masking the
> object methods it was invoking in other JSBSim code.
Could very well be.
> properties, but not much for anything else. The biggest
> One of the main goals we would like to work on is Martian
> terrain. I'm not
> sure how much of the Earth's parameters are hard coded, but I'm imagining
> it shouldn't be TOO difficult to produce Mars scenery for the sim. I have
> done it a little bit with MS's Flight Sim, and the initial resu
> Some of the other XML files are rather easy to figure out (i.e,. keyboard.
> xml), but others are not (i.e., the FDM specific files). Does anyone have
> anything written that describes these? The materials.xml file has quite a
> nice description at the top.
Can you let us know what is unclear
> This is where we disagree -- keeping it in makes the code much harder
> for new (and existing) contributors to read and understand, gives
> false hits when searching for variables and method calls, etc. etc.
> With CVS, it's trivially easy to look at or restore old code later if
> we need to; I'
> On Behalf Of Jim Wilson
> Sent: Friday, March 15, 2002 7:38 PM
> Oh yes, in fact I'm interested in the same promised release. We used
formerly
> watcom's powerbuilder where I work for some billing and accounting stuff
and
> it is great. We've got one power user/self taught programmer that does
> Erik Hofman writes:
> >
> >I'm realy impressed by the effect of the code. The higher I get, the
> >higher the framerate! This makes me believe we could actually enlarge
> >the view range when getting at a higher altitude.
This would be really nice for very high flying ("X") aircraft.
Jon
_
> You have a chicken-and-egg bug here: The tire contact point is
> *defined* as the intersection of the gear compression vector with the
> ground. You can't possibly ask for the elevation beneath it until you
> know it. Going back to the same diagram, the point of the wheel is
> the "result" of
> You know, the code to do both what you want and what Andy wants is
> already done and like Norman said, has been in place for about a year
> now.
Holy! ...
Man, you guys are *fast*.
I guess I missed that somewhere along the way in months past. Or, it could
be that we got the gear to be "good
> Forget anything else you might think I want. I don't want that. I
> want the above interface. That is all I want. I no longer claim
> (publically) that this interface is better. I no longer claim that
> any other interfaces are wrong. I just want them, OK?
Thank you for playing nice. :-)
JSBSim in CVS is in an intermediate state.
Note that you will have to define NOSIMGEAR to get things to compile
correctly in Builder.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of ÕÅÐÛ
> Sent: Wednesday, March 13, 2002 7:28 PM
> To: [EMAIL PROTEC
> 1. Aerodynamic coefficients
>
> You probably won't be able to find these anywhere, unless your
> airforce once did wind-tunnel tests on a DC-3/Dakota, but these are
> what JSBSim needs to model a DC-3 correctly. There will be a lot of
> numbers or tables with headings like CLo, CLa, CDo, etc. (
little behind the
> origin, apply the euler pitch, and convert it to a rotation matrix it'll
> move more realistically:
This might be helpful from the JSBSim site:
http://jsbsim.sourceforge.net/quaternions.html
Jon
Jon Berndt
Coordinator,
JSBSim
> Where can I get the 3D models with .3ds format? or how can I translate
them to .3ds?
> Is there anyone convert the model of the Pioneer UAV into the JSBSim
format?
This would be nice to have - that is, a small program to convert the format
from one to ther other. Perhaps someday. It would be ni
This sounds ideal! I vote that you submit it! :-)
What are the code dependencies? SimGear?
Jon
> I have a stand-alone real-time and off-line plotting
> tool written in C/C++ (tested in Cygwin/WinNT/Win2K &
> Linux) that is meant to be used as a flight test
> engineer's station. It has just been
>I've found that each "%f" format conversion is relatively expensive, and
>(under linux) many sprintf followed by a single write is much faster than
>a lot of successive fprintf. I'd assume that the C++ version has the same
>performance impact.
Right now, FGOutput.cpp uses cout. We direct output
>It's really nice to play with it! I once watched a Harrier at an airshow.
>It didn't really look like it were difficult to fly. ;-) I assume that
>the real thing is stabilized by a computer, no? Otherwise we would read
>about crashed Harriers every day. Lifting off in fgfs is already a hairy
O
>JSBSim actually works very hard to simulate realistically and uses
>the processor; with logging turned on, it does significant disk I/O.
>If you're short of memory and having to swap, the extra disk load
>can crucify the performance of Windows to keep the application running.
And we are investig
>IMO, the logging options should be moved off to a separate file and
>no version of that file should be committed to base CVS.
>That way, no user will ever get logging when they don't want it and
>developers can set things up the way they like for *all* JSBSim
>aircraft.
This is probably true, bu
>You can 'see' that it took some 2 minutes -
>130.792 secs to be exact - before i got the
>engine rolling ... so that's some 1310
>lines (@ 10 HZ) of csv that yield little ...
>
>One can be puzzled why the last column,
>very largely labeled engine[?].RPM starts
>at 1071.807 RPM, but over the next
>JSBSim stops after the QNAN's,
>and now YASim c172 seems unable to get speed to lift off ...
>Just one of those days ...
... only in MSVC ...
Christian: are you seeing this, too?
Jon
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.f
801 - 896 of 896 matches
Mail list logo