Re: [Flightgear-devel] Problems Compiling clouds3d
Paul Deppe wrote: Paul Deppe wrote: When compiling CVS simgear/sky/clouds3d I am getting numerous warnings: WIN32 redefined, initialization from int to float, ... is implicitly a typename, and many others, and finally the following error when compiling SkyTextureState.cpp: SkyTextureState.cpp:94: `glActiveTextureARB' undeclared (first use this function) Erik wrote: I know there is a fix in SimGear to include glext.h for windows platforms. Maybe one of the ifdefs fails (because a version number changed or something like that)? Erik, Here are some of the references to EXTGL_NEEDED in the SimGear root directory: -- configure.ac: AM_CONDITIONAL(EXTGL_NEEDED, test x$ac_cv_header_windows_h = xyes) It looks like this is for windows/MSVC compilers only, but Norman might know more about it. extgl.h is #include'd by SkyTextureState.cpp via SkyTextureState.hpp via SkyContext.hpp. It looks like all the ifdef's are working properly. So I am stumped here - why can't the compiler see the declaration of glActiveTextureARB() when compiling SkyTextureState.cpp? I'm missing something. Could it be you are linkijg against a wrong OpenGL library? It looks like glActiveTextureARB is an OpenGl 1.3 extension, on the other hand, I have included a (compile time) check to see if glActiveTextureARB is actually supported by the system and neglect this code otherwise. Could you check if GL_ARB_multitexture is defined in your gl.h header file? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] What's in the job jar?
Mike Bonar wrote: Okay, I have completed step one. I am up and running with the latest cvs snapshot on Suse 8.1. What's in the job jar? Give me something easy to start out with since it's been awhile since I have done any coding. Some background if you are interested, I spent a good chunk of last year and and early this year as a beta tester for the F4UT working on SP2 and SP3 of the Falcon4 Superpak. That was fun, but development is where I want to play. I have been mostly interested in AI and terrain rendering, but I am open to working on anything. Well, terrain generation can always use some help: http://www.terragear.org Otherwise, just try out the sim and see what you want to change ;-) Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] What's in the job jar?
Mike Bonar writes: Okay, I have completed step one. I am up and running with the latest cvs snapshot on Suse 8.1. What's in the job jar? Give me something easy to start out with since it's been awhile since I have done any coding. Cleanup is always, always needed -- my only suggestion is to make your changes in tiny steps so that you don't waste time if you head off in the wrong direction. We are slowly trying to get all of the parts of FlightGear to extend FGSubsystem (defined src/Main/fgfs.hxx) and to simplify the top-level loop in src/Main/main.cxx. I have been mostly interested in AI and terrain rendering, but I am open to working on anything. You can also take a look at Dave Luff's ATC code in src/ATC/ -- he might have some TODO jobs. Thanks, and all the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] AT6 Cockpit Photos
Someone on the Piper mailing list had a chance to crawl into a couple of AT6's visiting his home field and snap some pics. Here they are, for anyone interested in the modelling: http://xcski.com/gallery/album02 All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] What's in the job jar?
David Megginson wrote: Cleanup is always, always needed -- ... We are slowly trying to get all of the parts of FlightGear to extend FGSubsystem (defined src/Main/fgfs.hxx) and to simplify the top-level loop in src/Main/main.cxx. That sort of top-level stuff really is best done by the top-level guys and gals who are familiar with the whole project - you, Curt, etc. - in order to encapsulate the subsystems, to enable other people (especially new-comers) to work more easily on any one subsystem. Not that Mike couldn't do some of it, but in general I wouldn't recommend it. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] What's in the job jar?
On Sun, 2002-12-22 at 07:09, David Megginson wrote: We are slowly trying to get all of the parts of FlightGear to extend FGSubsystem (defined src/Main/fgfs.hxx) and to simplify the top-level loop in src/Main/main.cxx. Where would I find documentation about code-layout of FGFS? I did a quick scan of flightgear.org and I didn't see a document that looked like it addressed this object does this and relates to the other objects like that question. Thanks, -Luke -- Luke Scharf, Jack of Several Trades http://www.ccm.ece.vt.edu/~lscharf ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] cvs logs
Any chance we could get back cvs logs from prior to the changeover? The lack of them is making it hard to track down regressions introduced prior to. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] missing CVS log (base package)
Last night I did an update to three of the Wright Flyer files, but only two showed up in the log. The one that did not show up in the log was the file: ~/fgfsbase/Aircraft/UIUC/wrightFlyer1903-v1-nl/aircraft.dat For the record, the message for it: Wright Flyer update: Reduced wing warp to rudder coupling per original, added better thrust model, other minor changes. Did I do something that prevented it from showing up in the log file? The one thing that was different about this commit (vs all of my others) is that the commit message was long (cvs commit -m long string file). With other developers, I sometimes see a long update message on some files. Is there a way to do this without using a long commit -m message? Regards, Michael ps Messages that I got when I committed the files: Checking in UIUC/wrightFlyer1903-v1-nl/aircraft.dat; /home/cvsroot/FlightGear/FlightGear/Aircraft/UIUC/wrightFlyer1903-v1-nl/aircraft.dat,v -- aircraft.dat new revision: 1.4; previous revision: 1.3 done Checking in UIUC/wrightFlyer1903-v1-nl/README.wrightFlyer1903.html; /home/cvsroot/FlightGear/FlightGear/Aircraft/UIUC/wrightFlyer1903-v1-nl/README.wrightFlyer1903.html,v -- README.wrightFlyer1903.html new revision: 1.5; previous revision: 1.4 done Checking in wrightFlyer1903-v1-nl-uiuc-set.xml; /home/cvsroot/FlightGear/FlightGear/Aircraft/wrightFlyer1903-v1-nl-uiuc-set.xml,v -- wrightFlyer1903-v1-nl-uiuc-set.xml new revision: 1.7; previous revision: 1.6 done ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] What's in the job jar?
Luke Scharf writes: Where would I find documentation about code-layout of FGFS? I did a quick scan of flightgear.org and I didn't see a document that looked like it addressed this object does this and relates to the other objects like that question. Come to think of it, that sounds like a worthy project. There are snippits here and there (including under docs-mini in the source dir), but no big master document. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] What's in the job jar?
David Megginson writes: Luke Scharf writes: Where would I find documentation about code-layout of FGFS? I did a quick scan of flightgear.org and I didn't see a document that looked like it addressed this object does this and relates to the other objects like that question. Come to think of it, that sounds like a worthy project. There are snippits here and there (including under docs-mini in the source dir), but no big master document. A worthy project indeed but IMHO an even worthier project would be to collect all of the various properties into a single document that included 1) a short description of what it controlled 2) which xml file it resided in 3) which 'C' file set its default if applicable 4) which 'C' files used it Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] What's in the job jar?
Norman Vine writes: A worthy project indeed but IMHO an even worthier project would be to collect all of the various properties into a single document that included 1) a short description of what it controlled 2) which xml file it resided in 3) which 'C' file set its default if applicable 4) which 'C' files used it We'd have to find a way to automate that, or it would go out of date too fast to be useful, at least until the code base is a lot more stable. In fact, there are now many properties that no C++ file uses at all. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] What's in the job jar?
David Megginson writes: Norman Vine writes: A worthy project indeed but IMHO an even worthier project would be to collect all of the various properties into a single document that included 1) a short description of what it controlled 2) which xml file it resided in 3) which 'C' file set its default if applicable 4) which 'C' files used it We'd have to find a way to automate that, or it would go out of date too fast to be useful, at least until the code base is a lot more stable. In fact, there are now many properties that no C++ file uses at all. All vaild points which just strengthen the arguments for why such a document is needed and FWIW sounds very familiar to programmers writing conventional code who 'chafe' at having to document what they do :-) Computer programs are a mix of algorithm and data and just because you take the data out of the 'C' code and stash it externally does nothing to alleviate the need to document it !! Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problems Compiling clouds3d
Paul Deppe writes: When compiling CVS simgear/sky/clouds3d I am getting numerous warnings: WIN32 redefined, initialization from int to float, ... is implicitly a typename, and many others, and finally the following error when compiling SkyTextureState.cpp: SkyTextureState.cpp:94: `glActiveTextureARB' undeclared (first use this function) I think the problem stems from GL/gl.h being included before extgl.h Note GL/glu.h and GL/glut.h both include GL/gl.h so extgl.h must precede these also Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] What's in the job jar?
Norman Vine writes: Computer programs are a mix of algorithm and data and just because you take the data out of the 'C' code and stash it externally does nothing to alleviate the need to document it !! Agreed -- I'm simply pointing out the challenges. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] ATC Sound
David Megginson writes: The new ATIS sound is great, Thanks! but I'm having volume problems with it. Oh dear :-( It's not possible to make it out at all at the default volume; when I change the volume from 2 to 10 in ATCmgr.cxx simple-set_volume(10.0); I can just make it out over the idling engine in the C172P. Is this a local problem on my system? FWIW, I found 1 a bit quiet, although audiable over the idling engine, so I set it to 2, which was audiable over the full throttle engine. Thats on windows though, although I could certainly make it out over the idling engine when I tested on Linux at 2. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] What's in the job jar?
Michael Selig
As it relates to documenting things, I'd like to ask this again: Is this
file property-api.html still around somewhere? This doc described the
property tree. It was a draft from Curt I believe.
It seems to me like the property stuff is the most important part of
FGFS. If one does not understand how to use this and code for it (both in
xml and cpp), then you're never going to get anywhere. Ok, maybe I
exaggerate (some).
I don't know if this exists or not
For my own understanding of the properties I dump out the
entire property tree every time the program starts
This doesn't document where things are in the code or the config files
but it at least lets you see what is there and is what I use in lieu of better
documentation
Question:
Is there any reason that ALL of the joysticks from the config files are
represented in the 'resident' property tree ??
Norman
// main.cxx
static bool fgMainInit( int argc, char **argv )
{
...
// ADD THIS LINE OF CODE TO DUMP THE PROPERTIES
writeProperties (props, globals-get_props(), true);
// pass control off to the master GLUT event handler
glutMainLoop();
// we never actually get here ... but to avoid compiler warnings,
// etc.
return false;
}
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] What's in the job jar?
MSVC6 has a Visio add-on that allows you to reverse engineer C code into UML diagrams. Anybody have experience with it? I was thinking of giving that a try to see what it looks like. In the meantime, I will see what I can find on code documentation. Cheers! Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David Megginson Sent: December 22, 2002 12:01 PM To: [EMAIL PROTECTED] Subject: re: [Flightgear-devel] What's in the job jar? Luke Scharf writes: Where would I find documentation about code-layout of FGFS? I did a quick scan of flightgear.org and I didn't see a document that looked like it addressed this object does this and relates to the other objects like that question. Come to think of it, that sounds like a worthy project. There are snippits here and there (including under docs-mini in the source dir), but no big master document. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ 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] What's in the job jar?
Michael Bonar wrote: MSVC6 has a Visio add-on that allows you to reverse engineer C code into UML diagrams. Anybody have experience with it? I was thinking of giving that a try to see what it looks like. It probably looks a lot like UML generated automatically from C code. :) I've never been able to understand the appeal of CASE tools like this. How on earth is a machine going to read your code for you and tell you how the design works? The whole point behind overview documentation is that it captures the *intent* behind the code -- that is exactly the part of the design that is not actually found in the code. By its very definition, it can't be automatically extracted. It has to be either written down by the designer or intuited by the reader. At best, a tool like this could make source navigation easier. Having tools to answer questions like who calls this? or where are these made? is useful. But that's best done at the level of C syntax, IMHO, not in a separate diagramming language. A lot of this, to be quite honest, is just me being a luddite or an elitist. It's been my experience that elaborate documentation schemes really aren't worth it. There seems to be an inverse relationship between a programmer's penchant for fancy design tools/methodologies and their ability to understand a design presented to them. The really productive coders I have known are happy with a one page README file for documentation, and tend to be able to dive into existing undocumented code and figure stuff out very well. The folks who insist on having pick your jargon available tend to struggle whether they get it or not. All in my experience, of course. None of this is to say that documentation is a bad thing. But elaborate documentation and design work is, IMHO, largely useless or self-defeating. In the professional world it tends to hamstring the best workers for the benefit of the worst, thus running afoul of Fred Brook's (The Mythical Man Month) observations about productivity. Really good examples of sane documentation can be found in the Documentation directory of the Linux kernel. The files there tend to tell you exactly what you need to know, and give you enough hints to discover the rest on your own and/or clue you in on what questions to ask of the people who know. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] What's in the job jar?
On Sun, 2002-12-22 at 13:01, David Megginson wrote: Luke Scharf writes: Where would I find documentation about code-layout of FGFS? I did a quick scan of flightgear.org and I didn't see a document that looked like it addressed this object does this and relates to the other objects like that question. Come to think of it, that sounds like a worthy project. There are snippits here and there (including under docs-mini in the source dir), but no big master document. Sounds like a good way for me to get started with the FlightGear code. Don't consider me as having claimed this task, though, until I actually upload something. Who should I send documentation patches to? Thanks, -Luke -- Luke Scharf, Jack of Several Trades http://www.ccm.ece.vt.edu/~lscharf ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] What's in the job jar?
Yes, I see where you are coming from, Andy. In the spirit of openness, I don't think that's the way to go either. However, I did run doxygen against the source code, and that is very cool. It's clean, simple, fast, and open. We could run a cron against the cvs directory each night, and voila!: instant, browsable html class hierarchy. The output in html format (it also spits out latex format) is 5MB. I could send it to anyone who is interesting. Mike On Sunday 22 December 2002 19:33, Andy Ross wrote: Michael Bonar wrote: MSVC6 has a Visio add-on that allows you to reverse engineer C code into UML diagrams. Anybody have experience with it? I was thinking of giving that a try to see what it looks like. It probably looks a lot like UML generated automatically from C code. :) ...snip lots of good stuff tell you exactly what you need to know, and give you enough hints to discover the rest on your own and/or clue you in on what questions to ask of the people who know. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ 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] What's in the job jar?
At 12/22/02, Norman Vine wrote:
Michael Selig
As it relates to documenting things, I'd like to ask this again: Is this
file property-api.html still around somewhere? This doc described the
property tree. It was a draft from Curt I believe.
It seems to me like the property stuff is the most important part of
FGFS. If one does not understand how to use this and code for it (both in
xml and cpp), then you're never going to get anywhere. Ok, maybe I
exaggerate (some).
I don't know if this exists or not
For my own understanding of the properties I dump out the
entire property tree every time the program starts
This doesn't document where things are in the code or the config files
but it at least lets you see what is there and is what I use in lieu of better
documentation
Question:
Is there any reason that ALL of the joysticks from the config files are
represented in the 'resident' property tree ??
Norman
// main.cxx
static bool fgMainInit( int argc, char **argv )
{
...
// ADD THIS LINE OF CODE TO DUMP THE PROPERTIES
writeProperties (props, globals-get_props(), true);
Thanks. That's pretty handy. I notice that this does not seem to include
all of the property information in some files, eg sound.xml (and several
other .xml files seen when searching through the props file).
Regards,
Michael
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] What's in the job jar?
_Interested_ ;-) On Sunday 22 December 2002 20:48, Mike Bonar wrote: Yes, I see where you are coming from, Andy. In the spirit of openness, I don't think that's the way to go either. However, I did run doxygen against the source code, and that is very cool. It's clean, simple, fast, and open. We could run a cron against the cvs directory each night, and voila!: instant, browsable html class hierarchy. The output in html format (it also spits out latex format) is 5MB. I could send it to anyone who is interesting. Mike ...snip ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Problems Compiling clouds3d
I think the problem stems from GL/gl.h being included before extgl.h Note GL/glu.h and GL/glut.h both include GL/gl.h so extgl.h must precede these also Norman I inserted the following in SkyTexture.hpp at line 36: #ifdef WIN32 # include extgl.h #endif ... and it worked - thanks. But I still wonder if there is some configuration issue with my system because no one else seems to be getting this error. I'll also try this fix with plib/examples/src/ssg/water/water.cxx, which also has the same compile error. Also... Could it be you are linking against a wrong OpenGL library? It looks like glActiveTextureARB is an OpenGl 1.3 extension, on the other hand, I have included a (compile time) check to see if glActiveTextureARB is actually supported by the system and neglect this code otherwise. Could you check if GL_ARB_multitexture is defined in your gl.h header file? Erik I found that Cygwin installs TWO copies of gl.h: opengl package installs: /usr/include/GL/gl.h (which declares glActiveTextureARB) and w32api package installs: /usr/include/w32api/GL/gl.h, (which does not). The w32api gl.h is dated later but does not declare glActiveTextureARB. Aha... it works _without_ the above patch when I hide /usr/include/w32api/GL! Is this a Cygwin bug? Paul Paul R. Deppe Veridian Engineering (formerly Calspan) Flight Aerospace Research Group 150 North Airport Drive Buffalo, NY 14225 (716) 631-6898 (716) 631-6990 FAX [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] What's in the job jar?
Michael Selig writes:
At 12/22/02, Norman Vine wrote:
Michael Selig wrote:
It seems to me like the property stuff is the most important part of
FGFS. If one does not understand how to use this and code for it (both in
xml and cpp), then you're never going to get anywhere. Ok, maybe I
exaggerate (some).
For my own understanding of the properties I dump out the
entire property tree every time the program starts
This doesn't document where things are in the code or the config files
but it at least lets you see what is there and is what I use in lieu of better
documentation
// main.cxx
static bool fgMainInit( int argc, char **argv )
{
...
// ADD THIS LINE OF CODE TO DUMP THE PROPERTIES
writeProperties (props, globals-get_props(), true);
Thanks. That's pretty handy. I notice that this does not seem to include
all of the property information in some files, eg sound.xml (and several
other .xml files seen when searching through the props file).
Yes I noticed that this is not a *complete* dump too :-(
I find that massaging this file a little is even handier, for example the attached
script creates this from the file the above patch produces and can be easily
modified to do other things with the properties
Norman
cut
FlightGear Key Map
Key: 'Ctrl-A' Toggle autopilot altitude lock.
Key: 'Ctrl-C' Toggle clickable panel hotspots
Key: 'Ctrl-D' Dummy dialog
Key: 'Ctrl-G' Toggle autopilot glide slope lock.
Key: 'Ctrl-H' Toggle autopilot heading lock.
Key: 'Enter' Move rudder right or increase autopilot heading.
Key: 'Ctrl-N' Toggle autopilot nav1 lock.
Key: 'Ctrl-R' (Temporary) Toggle winding-ccw
Key: 'Ctrl-S' Toggle auto-throttle lock.
Key: 'Ctrl-T' Toggle autopilot terrain lock.
Key: 'Ctrl-U' [Cheat] Add 1000ft of emergency altitude.
Key: 'ESC' Prompt and quit FlightGear.
Key: 'SPACE' Fire Starter on Selected Engine(s)
Key: '!' Select first engine
Key: '#' Select third engine
Key: '$' Select fourth engine
Key: '+' zoom in (decrease field of view)
Key: ',' Left brake
Key: '-' zoom out (decrease field of view)
Key: '.' Right brake
Key: '0' Move rudder left or increase autopilot heading.
Key: '1' Decrease elevator trim.
mod-shift Look back left
Key: '2' Increase elevator or autopilot altitude.
mod-shift Look back.
Key: '3' Decrease throttle or autopilot autothrottle.
mod-shift Look back right.
Key: '4' Move aileron left.
mod-shift Look left.
Key: '5' Center aileron, elevator, and rudder.
Key: '6' Move aileron right.
mod-shift Look right.
Key: '7' Increase elevator trim.
mod-shift Look front left.
Key: '8' Decrease elevator or autopilot altitude.
mod-shift Look forward.
Key: '9' Increase throttle or autopilot autothrottle.
mod-shift Look front right.
Key: '=' Reset zoom to default
Key: '@' Select second engine
Key: 'A' Decrease speed-up.
Key: 'B' Toggle parking brake on or off
Key: 'M' Decrease warp.
Key: 'P' Toggle panel.
Key: 'T' Decrease warp delta.
Key: 'W' (Temporary) Toggle fullscreen for 3DFX only.
Key: 'X' Increase field of view.
Key: 'Z' Decrease Visibility
Key: '[' Decrease flaps.
Key: ']' Increase flaps.
Key: 'a' Increase speed-up.
Key: 'b' Apply all brakes.
mod-up Release all brakes.
Key: 'c' Toggle 3D/2D cockpit
Key: 'g' Toggle gear down.
Key: 'l' Toggle tail-wheel lock.
Key: 'm' Increase warp.
Key: 'p' Toggle the pause state of the sim.
Key: 's' Swap panels.
Key: 't' Increase warp delta.
Key: 'v' Cycle view
Key: 'x' Decrease field of view.
Key: 'z' Increase Visibility
Key: '{' Decrease Magneto on Selected Engine
Key: '}' Increase Magneto on Selected Engine
Key: '~' Select all engines
Key: 'F1'
Key: 'F2'
Key: 'F3' Capture screen.
Key: 'F4'
Key: 'F5'
Key: 'F6'
Key: 'F7'
Key: 'F8'
Key: 'F9'
Key: 'F10'
Key: 'Enter' Move rudder right or increase autopilot heading.
Key: 'Keypad 5' Center aileron, elevator, and rudder.
Key: 'Left' Move aileron left.
mod-shift Look left.
Key: 'Up' Increase elevator or autopilot altitude.
mod-shift Look forward.
Key: 'Right' Move aileron right.
mod-shift Look right.
Key: 'Down' Decrease elevator or autopilot altitude.
mod-shift Look backwards.
Key: 'PageUp' Increase throttle or autopilot autothrottle.
mod-shift Look front right.
Key: 'PageDown' Decrease throttle or autopilot autothrottle.
mod-shift Look back right.
Key: 'Home' Increase elevator trim.
mod-shift Look front left.
Key: 'End' Decrease elevator trim.
mod-shift Look back left.
Key: 'Insert' Move rudder left or decrease autopilot heading.
#! /usr/bin/env python
$ID: fgfs_keymap.py
Create the current KeyMap for FlightGear by parsing the property tree
This requires Fredrik Lundh's (Simple)ElementTree
available at
Re: [Flightgear-devel] Problems Compiling clouds3d
Paul Deppe writes: I think the problem stems from GL/gl.h being included before extgl.h Note GL/glu.h and GL/glut.h both include GL/gl.h so extgl.h must precede these also Norman I inserted the following in SkyTexture.hpp at line 36: #ifdef WIN32 # include extgl.h #endif ... and it worked - thanks. But I still wonder if there is some configuration issue with my system because no one else seems to be getting this error. FWIW - I did not get this error because I do not use the Cygwin OpenGL headers see my other post on this subject Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] copying properties
Is there a way to copy a block of properties (ie an equivelent to cp -ax dir1 dir2)? IIRC this was discussed at one time, and I'm wondering if it has been implemented yet. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] properties documentation
This may sound like a lame idea. I am not all that versed on xml technology, but it seems to me that there is a standard form for something like this. In the database world there is something called a Data dictionary that works as a central repository for data items, their types, default values, short descriptions, long descriptions, etc. Is this the sort of thing that a standard DTD document provides? Or could we develop our own dictionary of sorts? I'm suggesting that this could provide the documentation we need (if it is centralized). If it assumed an active role in the property system, then it could be used as a resource to simplify coding individual xml files, since default values, types, and other properties could be sourced from the central dictionary. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] copying properties
Jim Wilson writes: Is there a way to copy a block of properties #include simgear/misc/props_io.hxx copyProperties (const SGPropertyNode *in, SGPropertyNode *out) But AFAIK this requires that the 'out' nodes exist i.e. this copies but does not construct the nodes I think the easiest way to 'clone' a branch is to write the branch out to a temp file then read the 'clone' in Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
