[Flightgear-devel] C 172 3side view and data
On another forum, Simon Knott gave me these links: http://aar400.tc.faa.gov/aar-430/reports/01-44.pdf http://www.avnet.co.uk/gtaviatn/betashop/categories_category=19023.htm The first includes a 3side view of a C172. Unfortunately, there are no crosssections. There is also a lot of data about te C172 inside, but more about usage statistics than maximum performance. The second one is a book store. Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] DC-3 3-D model (partial)
Wolfram Kuss writes: Have you looked at the profile of the wing yet? :-). I'm trying to keep the tri count down, but it does have sort-of an airfoil profile (i.e. the top curves up). All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] msvc6-win32-0.7.9 Ok
Windows 98 SE ... stock standard stuff.
Tell me about the display car dyou have, how much memory there?
Must search for the 'book' that came with the machine for the actual
'card'
but i remember something like AGP something. The driver is the Intel
810e Chipset Graphics Driver PV 2.1 (as Alex mentioned) ... I guess the
on card mem. would be minimal, maybe 2 or 4 MB max. - Must find
that book! This 'french' Unika pc case is very difficult to open and look
...
I run at 1024x768 at 16-bit colour on my Hyundai P910 19 ins monitor.
Of course I only run FGFS in its 600x400 window. Expanding that
window to full screen really does SLOW things down, but I can get
quite reasonable 'flying' as set up ... I am modestly happy ... :-)(
... Really, the FDM takes a very small amount
of computation time. Most of the time is spent in the display
routines, IIRC.
That is agreed. But i was making a point about how 'rocking' the ac
when the engine/mags are off (and 0 wind) cause the 'display' to be
re-done - that is a small change issued by the FDM can drastically
increase the 'display' ... as it SHOULD. But when we are OFF, and
not 'paused' ... who/what is moving the ac???
As mentioned, and it happened again, after i enter a 'p' key, FGFS
does 'pause', BUT i can never seem to get it started again ... In fact
it seems to go somewhere 'very busy', and I have to use drastic
measures (like a Ctrl+C in the CONSOLE screen) to exit ... Must
try to investigate this more ...
... avoid the 'slower micro-coded on chip' FPU
instructions as much as possible to ...
I loved the two approaches on this -
(a) a question posed -
Do you have some particular examples?
Yes, any time you write double * double, or
(b) some type of agreement, at least in principal -
The maths that are done for magic are *much* simpler and thus require
much less CPU. So it's expected to have the best performance.
ok. I am still of the opinion that floating point maths can take lots of
p-clocks
to complete, so we can see a 'good' example of what i mean in the
'magic' code = try to avoid minimal change
snippet
if ( speed SG_EPSILON )
{
geo_direct_wgs_84 ( get_Altitude(),
get_Latitude() * SGD_RADIANS_TO_DEGREES,
get_Longitude() * SGD_RADIANS_TO_DEGREES,
get_Psi() * SGD_RADIANS_TO_DEGREES,
dist,
lat2, lon2, az2 );
_set_Longitude( lon2 * SGD_DEGREES_TO_RADIANS );
_set_Latitude( lat2 * SGD_DEGREES_TO_RADIANS );
}
end snippet
SG_EPSILON is defined as -
D:\fg79\SimGear\simgear\constants.h(121):#define SG_EPSILON 0.001
Now maybe your FDM code is already liberally sprinkled with such checks,
and if the 'result' is not 'significant' then you do not continue
calculate more
and then change global things by less than 1 millionth of something ...
then
this is good.
And that is all i am talking about. FGFS is the co-operation of many
'components', and each should do its best to not hog the cpu resource, or
cpu(s) for that matter ...
Or in this case, cause another component to hog the resources by altering
the physical world location minimally ...
It is perhaps strange that I do *NOT* think the output of the diagnostic
file is part of the problem at all. Writing quick snippets of formatted
text
to disk can be quite fast, and it does not involve the 'read' cache which
I think is the important io bottleneck ...
One construction i do hate seeing in a routine that is called frequently -
at many times per second - is something like -
setRPM(node-getDoubleValue(rpm));
or worse ... excuse me Curt for jumping on main.cxx here as an
example ...
for ( i = 0; i multi_loop * fgGetInt(/sim/speed-up); ++i ) {
// run something
foo-update( 1 );
}
FGSteam::update( multi_loop * fgGetInt(/sim/speed-up) );
If only the coder would 'trace' such action thru once or twice,
and see the 'massive' overheads involved ... That is using -
D:\fg79\FlightGear\src\Main\fg_props.hxx(151):inline int fgGetInt (const
string name, int defaultValue = 0)
and the like ...
Each time such a text string is used to get a node value, there has
to be an allocation of string structure memory, and a copy of the
'static' data into a string structure, which involves a re-allocation
since the string structure memory was initiated with a buffer length
of 1, then off to fgGetInt( _s_s ) with a string ref -
And after the multiply is completed the string tidier will release this
memory ... for EACH AND EVERY ONE of the for loops.
And then again, after the for, another string allocation will be done,
the 'database' searched with the string reference, and when the
multiply is completed, again this memory has to be released.
i. such strings, and there are 100's throughout FGFS, should be
one time allocated during an init()
foo::init( double dt )
sSimSpdUp = /sim/speed-up;
Then at least, in the main loop -
multi_loop * fgGetInt( sSimSpdUp )
at least avoids a memory allocation,
Re: [Flightgear-devel] msvc6-win32-0.7.9 Ok
... Really, the FDM takes a very small amount of computation time. Most of the time is spent in the display routines, IIRC. That is agreed. But i was making a point about how 'rocking' the ac when the engine/mags are off (and 0 wind) cause the 'display' to be re-done - that is a small change issued by the FDM can drastically increase the 'display' ... as it SHOULD. But when we are OFF, and not 'paused' ... who/what is moving the ac??? The wind will rock the aircraft. If your display card can't keep up with this minimal activity, get a new display card. Really, if you actually have only 2 or 4 MB of video RAM I am surprised you can run at all. There is nothing in the FDMs that is giving you problems, so just put that out of your mind. Your troubles are caused by having a machine that is apparently not up to the task. I found this out myself about a year ago. I could not run FlightGear for many months until I upgraded my machine. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re: YASIM Options
I seeing on TV recently that they have only recently added full computer stabilisation to the Harrier. They had the presenter of the program (a qualified military pilot, but not on the Harrier) flying a two-seater. There was a switch to choose hover or normal flight, in hover mode the throttle controlled elevation and the stick was slip/slide direction control (much like the cyclic in a helicopter), in regular mode, the throttle did speed, and the stick did pitch and roll as usual. The comment was that this would leave the pilot more time to see, and deal with, other things like finding targets and staying alive. Richard 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 operation. But turning (yawing) at the place seems impossible. Is this modeled? How is it done in a real Harrier? With steering jets, coupled to the rudder? This e-mail has been scanned for all viruses by Star Internet. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: YASIM Options
Melchior FRANZ wrote: Andy Ross wrote: There's also a complication with the Harrier. You'll need to map a joystick axis to the /controls/thrust-vector[0] property in order to work the thrust vectoring. Works also reasonably well when mapped to the low/high properties of a joystick hat switch. [:-)] I actually found that this wasn't very satisfactory. The problem is that the thrust vectoring is your foward-back control in hovering flight. A typical end to the approach has the aircraft going 30-40 kts as it approaches the pad. You then have to throw the nozzles to max deflection (which is 10 degrees forward) to slow down, then immediately put them back at 85 degrees* or so for hover. Doing this with up/down only is, well, hard. There's no feedback about where the position of the control is. A cockpit gauge could help that a lot, too. * The aircraft sits on its gear at about 5 degrees AoA. You need to land flat on the gear to avoid a nasty bounce on landing. I've been playing/practicing with the Harrier a lot recently. I really should write up a training guide or somesuch, for folks just getting into it. The learning curve on the VTOL stuff is nasty and steep, kind of like being a real life test pilot on the things. Loads of fun. I can *almost* reliably land vertically now -- but hovering still eludes me. 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. [;-)] Those damn professional pilots make it look so easy. They have a few advantages, though. In addition to much more sensitive controls and vastly better visual distance cueing (you can see things on the ground in a real aircraft, not so (yet) in FlightGear), they can feel the lateral accelerations as they happen. While hovering in the simulator, it's too easy to turn a degree or two of bank into a 10 kt. sideslip by accident, simply because you don't notice it in time. A real pilot would feel this happening. I assume that the real thing is stabilized by a computer, no? Otherwise we would read about crashed Harriers every day. The Harrier is actually a very old design. The early ones (I've modelled a Sea Harrier FRS.1) don't have anything but a mechanical control linkage. No stabilization systems at all. And they *do* have the worst safety record (by far -- something like a factor of two) of all active tactical aircraft in the U.S. military. Dunno about the record the Brits, Spanish, Italians, Indians or Thai have seen, but I suspect it's similar. Lifting off in fgfs is already a hairy operation. But turning (yawing) at the place seems impossible. Is this modeled? How is it done in a real Harrier? With steering jets, coupled to the rudder? Vertical liftoff works pretty well, *if* you get the nozzles pointed in the right direction. If you just point them all the way down you're actually pushing the aircraft backwards. The sudden reduction of braking force from the wheels at liftoff ends up creating a nose down moment and the aircraft pitches forward as it lifts off. Be careful out there. :) A saner way to get off the ground is the rolling vertical takeoff, which is actually the way it's done in real life. Deploy the flaps and the wheel brakes. Point the nozzles downward. Spool the engines up to 85% RPM or so (no more than that, or else you'll lose ground traction and the wheels will slip). Then, in one quick motion, point the nozzles forward and jam the thottle to maximum. After a few seconds (and ~100m of runway) you'll be at 65 kts; now angle the nozzles down at about 45-60 degrees. You're airborn -- retract the gear and gently ease the nozzles forward, retract the flaps at 240 kts or so. I'm not sure about your problems with yaw. It works for me. What you're probably discovering is that hovering is hard. :) If you're not moving at literally zero speed, the aircraft, being an aircraft, will try to weathervane into the wind. At anything more than 10 kts of sideslip, this yaw force will be higher than that pathetic little jets in the tail and you'll lose controllability. Other than don't allow big sideslips in hover, I don't know how to deal with this. The real aircraft, by the way, has a little weather vane in front of the cockpit for exactly this reason. Hover into the wind, or else you'll die. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] CVS trouble
I am again trying to compile the CVS version of FlightGear. I *think* I am following instructions! I have not had any trouble building the version 0.7.8, but with CVS I get the following compile error: Making all in ATC make[2]: Entering directory `/usr/local/src/FlightGear/src/ATC' c++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src -I/usr/loca l/include -g -O2 -c atis.cxx In file included from atis.cxx:47: ../../src/Main/fg_props.hxx: In function `class SGPropertyNode * fgGetNode(const string , int, bool = false)': ../../src/Main/fg_props.hxx:100: no matching function for call to `SGPropertyNod e::getNode (const basic_stringchar,string_char_traitschar,__default_alloc_tem platefalse,0 , int , bool )' /usr/local/include/simgear/misc/props.hxx:681: candidates are: class SGPropertyN ode * SGPropertyNode::getNode(const string , bool = false) /usr/local/include/simgear/misc/props.hxx:687: const class SGPro pertyNode * SGPropertyNode::getNode(const string ) const make[2]: *** [atis.o] Error 1 make[2]: Leaving directory `/usr/local/src/FlightGear/src/ATC' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/src/FlightGear/src' make: *** [all-recursive] Error 1v Any help would be appreciated. Thanks, Mark ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] CVS trouble
I am again trying to compile the CVS version of FlightGear. I *think* I am following instructions! I have not had any trouble building the version 0.7.8, but with CVS I get the following compile error: Did you do a build of plib first, followed by Simgear, then FlightGear? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS trouble
Boslough, Mark B wrote: I am again trying to compile the CVS version of FlightGear. I *think* I am following instructions! I have not had any trouble building the version 0.7.8, but with CVS I get the following compile error: Not to be too snooty, but sometimes it's helpful to actually read the text of the error message. :) In this case, with a little reformatting: no matching function for call to SGPropertyNode::getNode(const basic_string..., int , bool )' candidates are: SGPropertyNode::getNode(const string , bool = false) SGPropertyNode::getNode(const string ) Admittedly, you need to know that the basic_string template yuck is just referring to the underlying type of string in the warped world of the C++ standard library. But once you're over that hurdle, it's not so bad. So the compiler is looking for a function that takes (string,int,bool) and can only find a version in the header that takes (string,bool). So, QED: the SimGear header files you have are the wrong version. In fact, inspecting the CVS logs for exactly that header file (simgear/misc/props.hxx), I find the following smoking gun: revision 1.23 date: 2002/01/19 03:06:22; author: david; state: Exp; lines: +29 -3 Added some new functionality to the property manager: 1. Nodes cache previous relative paths so that they do not have to parse the paths each time. 2. There are new getNode() methods that include indices, so that users do not have to sprintf to a buffer to iterate through indexed nodes. Bingo. Your FlightGear CVS is current (and using the new methods that indclude indices), but your SimGear installation is lacking the update that happened nine days ago. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] CVS trouble
No. That was going to be my next guess. Thanks, I'll try that! Mark I've got a perl script (and I believe Norman also has a script) that automates that whole process for me, in the corret order, with dependencies. If you do a checkout of flightgear, you should also do a checkout of Simgear and plib. FGFS depends on SimGear which depends on plib. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] CVS trouble
Since I already had built plib, this time I downloaded and build the CVS version of Simgear followed by the CVS version of FlightGear. This time I got further, but still ran into this: Making all in GUI make[2]: Entering directory `/usr/local/src/FlightGear/src/GUI' c++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src -I/usr/loca l/include -g -O2 -c apt_dlg.cxx c++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src -I/usr/loca l/include -g -O2 -c gui.cxx c++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src -I/usr/loca l/include -g -O2 -c gui_local.cxx c++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src -I/usr/loca l/include -g -O2 -c mouse.cxx c++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src -I/usr/loca l/include -g -O2 -c net_dlg.cxx c++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src -I/usr/loca l/include -g -O2 -c prop_picker.cxx prop_picker.cxx: In method `fgPropPicker::fgPropPicker(int, int, int, int, int, const char *, const char * = Pick a file)': prop_picker.cxx:354: no matching function for call to `puListBox::puListBox (int , int, int, int)' /usr/include/plib/pu.h:1052: candidates are: puListBox::puListBox(int, int, int, int, char **) /usr/include/plib/pu.h:1057: puListBox::puListBox(const puListBo x ) prop_picker.cxx: In method `void fgPropPicker::find_props()': prop_picker.cxx:509: no matching function for call to `puListBox::newList (char **)' make[2]: *** [prop_picker.o] Error 1 make[2]: Leaving directory `/usr/local/src/FlightGear/src/GUI' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/src/FlightGear/src' make: *** [all-recursive] Error 1 Should I start over with a fresh copy of plib? Thanks, everybody, for your help. Mark -Original Message- From: BERNDT, JON S. (JON) (JSC-EX) (LM) [mailto:[EMAIL PROTECTED]] Sent: Monday, January 28, 2002 1:34 PM To: '[EMAIL PROTECTED]' Subject: RE: [Flightgear-devel] CVS trouble I am again trying to compile the CVS version of FlightGear. I *think* I am following instructions! I have not had any trouble building the version 0.7.8, but with CVS I get the following compile error: Did you do a build of plib first, followed by Simgear, then FlightGear? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] CVS trouble
The downloads page states you need at least plib-1.4.0 to build flightgear. Right now I'm using plib-1.4.2. What version of plib do you have installed? Curt. Boslough, Mark B writes: Since I already had built plib, this time I downloaded and build the CVS version of Simgear followed by the CVS version of FlightGear. This time I got further, but still ran into this: Making all in GUI make[2]: Entering directory `/usr/local/src/FlightGear/src/GUI' c++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src -I/usr/loca l/include -g -O2 -c apt_dlg.cxx c++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src -I/usr/loca l/include -g -O2 -c gui.cxx c++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src -I/usr/loca l/include -g -O2 -c gui_local.cxx c++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src -I/usr/loca l/include -g -O2 -c mouse.cxx c++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src -I/usr/loca l/include -g -O2 -c net_dlg.cxx c++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src -I/usr/loca l/include -g -O2 -c prop_picker.cxx prop_picker.cxx: In method `fgPropPicker::fgPropPicker(int, int, int, int, int, const char *, const char * = Pick a file)': prop_picker.cxx:354: no matching function for call to `puListBox::puListBox (int , int, int, int)' /usr/include/plib/pu.h:1052: candidates are: puListBox::puListBox(int, int, int, int, char **) /usr/include/plib/pu.h:1057: puListBox::puListBox(const puListBo x ) prop_picker.cxx: In method `void fgPropPicker::find_props()': prop_picker.cxx:509: no matching function for call to `puListBox::newList (char **)' make[2]: *** [prop_picker.o] Error 1 make[2]: Leaving directory `/usr/local/src/FlightGear/src/GUI' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/src/FlightGear/src' make: *** [all-recursive] Error 1 Should I start over with a fresh copy of plib? Thanks, everybody, for your help. Mark -Original Message- From: BERNDT, JON S. (JON) (JSC-EX) (LM) [mailto:[EMAIL PROTECTED]] Sent: Monday, January 28, 2002 1:34 PM To: '[EMAIL PROTECTED]' Subject: RE: [Flightgear-devel] CVS trouble I am again trying to compile the CVS version of FlightGear. I *think* I am following instructions! I have not had any trouble building the version 0.7.8, but with CVS I get the following compile error: Did you do a build of plib first, followed by Simgear, then FlightGear? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] CVS trouble
Jon Berndt writes: No. That was going to be my next guess. Thanks, I'll try that! Mark I've got a perl script (and I believe Norman also has a script) that automates that whole process for me, in the corret order, with dependencies. If you do a checkout of flightgear, you should also do a checkout of Simgear and plib. FGFS depends on SimGear which depends on plib. The latest stable Plib (1.4.2 I believe) should also work (It does for me). It shouldn't be necessary to keep checking out CVS Plib. Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] CVS trouble
The latest stable Plib (1.4.2 I believe) should also work (It does for me). It shouldn't be necessary to keep checking out CVS Plib. It takes about 2 minutes (maximum) to check out and build on my machine. I always do it to avoid (and rule out) any build problems. This is one reason why I no longer have many build problems. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] CVS trouble
I went ahead and checked out the CVS plib and it built without error. Thanks again everybody... hopefully there will be no more dumb beginner questions from me again for awhile :-) Mark -Original Message- From: BERNDT, JON S. (JON) (JSC-EX) (LM) [mailto:[EMAIL PROTECTED]] Sent: Monday, January 28, 2002 2:35 PM To: '[EMAIL PROTECTED]' Subject: RE: [Flightgear-devel] CVS trouble The latest stable Plib (1.4.2 I believe) should also work (It does for me). It shouldn't be necessary to keep checking out CVS Plib. It takes about 2 minutes (maximum) to check out and build on my machine. I always do it to avoid (and rule out) any build problems. This is one reason why I no longer have many build problems. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Creating a sub window
Christian wrote: In that case you can have a much simpler solution. Look at PLIBs PUI and create a new (permanet) PUI window that outputs the text. Should be quite easy. Thanks Christian! Pui worked great! Dawn ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] msvc6-win32-0.7.9 Ok
Geoff McLane writes: Yeah! Precisely. perfectly. Can I give you the number of my person-in-charge-of-upgrade of our in-house major system? ... and you tell them (actually her) - err, I only write an fdm for that in which in can run. Get a better capability, or ??? shut up ??? :-))) There have been several concrete, substantive posts describing the minimal flightgear machine. Why don't you forward those along to her and if she has any further questions, we can try to address them as well. only 2 or 4 MB of video RAM I am surprised you can run at all. It does run. It runs well. It is the best since sliced bread! Keep it up forever. I am really for dissemination of knowledge. And being able to 'magic carpet' along a coast line, could really help in geography lessons ... at the very least ... There are really and truely not many (free or otherwise) products out there where you can elevate your self say just 5000 feet above mean sea level above SF, turn south, take on some speed and travel along the 'real' usa coast until say you reach the LA basin, which you 'recognise' from your geography lessons, or on further south ... forever, until the tiles run out !!! So why does this FGFS workable-in-this-tiny-pc-environment scenerio become 'impossible', or at least more/very difficult, if you add in the EOM, 'equation of motion' of an aircraft? You tell me? Have you compared JSBSim against LaRCsim and YASim? I have just agreed i turn OFF another big graphic grabber - the panel - and run only on the HUD - modified as earlier mentioned to ALWAYS show frame rate ... HUD's must do this ... maybe a hud xml changes? The only 'suggestion' i had was that an fdm who did well in the overall scene would have *nothing* to do until eng/mags/wind became 'alive. No trim or ANYTHING until at least all the scenery tiles had been laid ... As mentioned, that can be several 'minutes' into the ride ... The FDM decides the motion of the aircraft. There are always forces acting on it, unless you figure out a way to turn off gravity. I just don't think this optimization would be that useful. Minutes to finish loading the initial tiles? Are you loading from a really slow cd-rom or a slow network share? On my machine with a local hard drive, the tiles are loaded within a second of when the graphics come up. I like JSBSim, at least in its c172 'feel'. I am not so familiar with other ac, but spend at least some of my time c172'ing around airfields. But this ac is not a real mover ... and must try others ... I am sorry none of what i said made any difference ... but it is ok. i enjoyed saying it ... A few questions ... some 'silly' cvs things ... I use the cmd cvs update -dP, but in FlightGear, i constantly get some 'warning' report about a missing 'yasim\util'??? directory ... but is says 'skipped' ... Is this all ok? I thought -P = prune empty. But of course it will NOT be empty until you/i/cvs delete things ... Now i am also getting the same thing in SimGear regarding the dearly recently departed zlib directory ... You mean cvs DOES NOT delete non-existant items in what is now knows as a non-existant directory? Then that seems to miss the point of 'update' ... CVS does not provide for deleting directories from the repository, but I break the rules and do it anyway. Go into the CVS/Entries and simply delete the item that is being complained about. I certainly agree 'certain' iterative memory allocation should have 'no impact' on a well written memory system ... did i not mentions i run win32? :-)) I don't think the problems are necessarily win32 ... I prefer to run Linux of course ... but there are many people out there running win32 without much trouble. Are you configuring --with-logging or --without-logging? Any console output can *REALLY* kill performance of a win32 app, perhaps that's what you are seeing? Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New graphic chip
FWIW, I just bought a GeForce 2 Pro from newegg.com for US$90. It was the Gainward Ti450 and works quite well. Jon On Sunday, January 27, 2002, at 11:52 AM, Elad Yarkoni wrote: Hi Guys, I know you hate it... and this topic seems to be endless on FGFS-Devel group, AND this discussion does not belong in here, but you guys are the only ones I trust... so here goes: am I going to replace my TNT2Ultra with a GeForceMX2 ? (you are going to decide for me) FGFS runs nicely on my TNT2U (I think it's the latets debianized packacge, 0.7.8), but the MX is cheap (60$) and, seems to be a lot better. However, no benchmark actually put both cards on the row and see which performs better. Hope you have some tips for me :) All the best, Elady. ___ Elad Yarkoni (Elady for friends or Oh my god - it's him ! for fans or turbofans) eMail: [EMAIL PROTECTED] WWW: http://www.ee.bgu.ac.il/~elady Dept. of ECE, BGU, Beer-Sheva, Israel. 972-8-647-2417. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASIM Options
Andy wrote Just need to get the turbine data across the link (Assuming that YASIM is generating N1, N2, EGT, EPR, oil pressure, fuel flow, etc) Sure thing: /engines/engine[n]/n1 /engines/engine[n]/n2 /engines/engine[n]/epr /engines/engine[n]/egt-degf /engines/engine[n]/fuel-flow-gph couple of comments and questions: both 747 and f15 seem to be underpowered. or possibly too much drag? Can't hold a vertical climb in the f15 and can only get to mid altitudes in the teens with 747 for f15 should be able to do an idle power loop @ 10K feet with an entry airspeed of around 250 to 300kts engine egt is given in degrees centigrade and fuel-flow for turbines is usually given as #/hr (1 gal ~ 6.5 pounds) Engine data is a little screwy. running jbsim for the c310 no data comes across and for yasim-747 the zeroeth values are missing. Not sure i've got this properties thing all figured out yet. In opengc.cxx data-n1_turbine[0] = fgGetDouble(/engines/engine[0]/n1); data-n1_turbine[1] = fgGetDouble(/engines/engine[1]/n1); // and so forth packs the data into the UDP packet Looks okay? does each each engine have a throttleor is it a single command for all four(two)? regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASIM Options
Engine data is a little screwy. running jbsim for the c310 no data comes across and for yasim-747 the zeroeth values are missing. Not sure i've got this properties thing all figured out yet. In opengc.cxx data-n1_turbine[0] = fgGetDouble(/engines/engine[0]/n1); data-n1_turbine[1] = fgGetDouble(/engines/engine[1]/n1); // and so forth packs the data into the UDP packet Looks okay? does each each engine have a throttleor is it a single command for all four(two)? regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASIM Options
Engine data is a little screwy. running jbsim for the c310 no data comes across and for yasim-747 the zeroeth values are missing. Not sure i've got this properties thing all figured out yet. In opengc.cxx data-n1_turbine[0] = fgGetDouble(/engines/engine[0]/n1); data-n1_turbine[1] = fgGetDouble(/engines/engine[1]/n1); // and so forth packs the data into the UDP packet Looks okay? Found the problem, a couple of the arrays were misaligned in the respective class definitions. New question. controls for teh gear and flaps? will the existinig bindings for the keyboard work? Are the gear and flap values now properties? Regards John W.g ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
