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
> 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
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
> 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. (
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
> 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. :-)
> 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
> 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
> 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
_
> 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
> 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'
> 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
> 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
> 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
> > 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
> --- 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
>
> 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
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
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
> 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?
> 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
> 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,
> 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
> 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%,
> > 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
> 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
> > 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
> 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
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
___
> > 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
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
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
> 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
> 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
__
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
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
> 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
> 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
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
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
> 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
> >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
> 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,
> 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
> > 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
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
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
> 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
> 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
> 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
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
> > 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
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!
>
>
>
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
> 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).
> 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(
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?
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
> > > 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
> 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.
If you are near a TV ... the shuttle goes up momentarily.
Jon
smime.p7s
Description: application/pkcs7-signature
> 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.
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
> 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
> 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
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
> 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
> 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 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
> 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
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
> 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
> > 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
>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
> 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
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
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
> 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
> 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
> 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
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
> 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
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
> 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
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
> 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,
> > 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
> ? 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
> 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
> 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
Never mind.
I need to start waiting two minutes later than I normally would to send
emails complaining of faults. That's how long it usually takes me between
the time I think of writing until I find where I screwed up.
:-/
Jon
smime.p7s
Description: application/pkcs7-signature
> I agree -- JSBSim is reporting a positive normalized position for a
> negative input (and vice-versa). Obviously, we've made allowances for
> that in the model animations, but it's inconsistent with the behaviour
> elsewhere. I'll look into fixing it.
Before making changes, can you elaborate
No elaboration needed. Thanks David.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Jon Berndt
> Sent: Tuesday, May 28, 2002 6:38 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [Flightgear-devel] Rudder inverted again in yasim
>
&g
-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of David
> Megginson
> Sent: Tuesday, May 28, 2002 7:14 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [Flightgear-devel] Rudder inverted again in yasim
>
>
> Jon Berndt writes:
>
> > > I agree -- JSB
> > Which Roskam did you find the Cherokee numbers in?
>
> Oops. I was mistaken. It's not Roskam -- it's McCormick,
> "Aerodynamics, Aeronautics and Flight Mechanics", Appendix C. Cameron
> Munro sent me copies of it.
It's a very complete example.
> > You could rough-in a Cherokee in YASim fi
> Not at all unlike being a test pilot. :)
This is the analogy I like to use, as well. It's one reason I'd really
like to see us model EAFB well. Where else would we test our models? We
wouldn't want to cause virtual property damage anywhere else!
;-)
Jon
smime.p7s
Description: application/
> The goal is by using a set of standards one could hyper-jump ones
> spacecraft between star systems, much the way one
I'm not really interested in anything outside of earth orbit, for now.
smime.p7s
Description: application/pkcs7-signature
> Some of the models are awful. Some are very much not. There's far
> too much variation across our flight models (across different code
> bases and even between individual aircraft in the same FDM) to permit
> a blanket statement like this one. It's just kibitzing. If he had
> specific compla
For the process of starting a turbine engine, this is what I have
identified, so far:
Actions:
---
1) engage the starter
2) throttle at ground idle setting
3) ignition on (at ~8% ground idle rpm)
4) fuel on
5) at ignition, engine begins to produce torque
6) when torque produce by engine equa
I've got a problem with an undefined reference. I've set up a function
template in one of my classes. The declaration is:
template
T IntegrateAB4(double delta_t, T& vLast, T* vLastArray);
The definition is:
template
T FGState::IntegrateAB4(double delta_t, T& vLast, T *vLastArray)
{
T
1 - 100 of 896 matches
Mail list logo
