Re: [Flightgear-devel] What's in the job jar?
Quoth Michael Bonar: Hi David. I get a Forbidden error when I try to reach that link. Terribly sorry. The link should have been http://www.more.net/~david/FlightGear-0.9.1/html/ I turned on about every option available, and also built the graphical class hierarchy. Regards, David K. Drum [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?
Quoth David Megginson: 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. I ran FG-0.9.1 through Doxygen the other day. It didn't croak, but it didn't produce much, either. I've put it up at http://www.more.net/~david/FlightGear-0.9.1/ for anyone who is interested. Regards, David K. Drum [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?
Hi David. I get a Forbidden error when I try to reach that link. My testing with Doxygen produced these results: http://members.shaw.ca/mike.bonar/doxygen.html That's with the default parameters. I did another run with Extract_all = YES, but it comes to 27MB, and I can't fit that on my webspace. Without extract_all = yes there are quite a few areas if FlightGear that are undocumented. Let me know if you have any questions on getting better results. SimGear has similar results. See http://www.simgear.org/doxygen/ I have been hunting around for a way to read all the XML files into HTML in a way similar to what doxygen does. There are plenty of open source readers that perform that task one page at a time. I sent a note to Dimitri van Heesch, author of doxygen to see if he had given this extension any thought. No response yet, but I imagine he's got enough on his plate. I didn't try the forums at sourceforge to see if the doxygen community has tried it. That might be something to try. Otherwise, we could always get the Perl books out and see what we can code up. ;-) Cheers, Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David Drum Sent: January 4, 2003 9:00 PM To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] What's in the job jar? Quoth David Megginson: 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. I ran FG-0.9.1 through Doxygen the other day. It didn't croak, but it didn't produce much, either. I've put it up at http://www.more.net/~david/FlightGear-0.9.1/ for anyone who is interested. Regards, David K. Drum [EMAIL PROTECTED] ___ 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?
David Megginson writes: Mike Bonar writes: 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. Yup, there's a black hole full of TODO jobs in there! With regard to AI traffic, the current limit of my ambition is to get light singles to fly circuits and taxi in and out of GA airfields, and light twins to fly straight in approaches between them, mainly to get more than one plane in the sky at once to test the ATC. No-one is working on commercial AI traffic flying IFR flight-plans AFAIK, although James Turner has written some tidy looking flight-plan classes that might come in handy for anyone trying it. I'd be quite happy to add ATC support as needed. With regard to ATC, there's at least one other person working on it besides myself, but AFAIK no-one is attempting to model centre control - I might have the terminology wrong there but I'm referring to control of the airways away from airfield tower/approach/departure control. Additionally, if you're into graphs, movement, shortest paths and all that, which is classical sort of AI stuff really, then there's plenty of that to be sorted to get ground control working robustly. I'm plugging away at some textbooks now, but there's lots of work in that that could be spread about. Just drop me a line if you feel like joining in! Additionally, I don't want what I've done to become a deterrent by inertia to people who could do it better. Particularly the AI traffic is very much an early work in progress, and if you (or others) feel you could do a better job from scatch then I'll quite happily support Curt and David in throwing my stuff out or porting the good bits to another framework if it does turn out better. And since you specifically asked (whats in the job jar?), here's some of the stuff I'd be tempted to do if I ever got the sack and had loads of time: Wrap the windows binary, atlas and the base package up in a GPL compatible installer with some nice info screens including one pointing out that we model prop-torque and wash effects by default whereas in other sims one generally has to switch them on! Write a graphical tool (possibly based on existing code) to layout taxiway logical networks, names, weight limits etc on a background of the existing rendered image. Add a charting facility to atlas to produce imitations of airport layout and IFR charts based on flightgear's internal data. Instant replay of last 60 secs of flight feature. (I'm pretty sure Flightgear has some flight logging now so shouldn't be too hard). Graphical flight analysis. Thats all I could think of for now - I don't have my Flightgear scribble book with me at the moment. Merry Christmas to everyone BTW :-) 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?
David Luff writes: With regard to ATC, there's at least one other person working on it besides myself, but AFAIK no-one is attempting to model centre control - I might have the terminology wrong there but I'm referring to control of the airways away from airfield tower/approach/departure control. Here's how things work in Canada... Control zones are quite small -- usually about a 5-7 nm radius around an airport up to 3000 ft AGL and are class C if there's a tower with radar or class E if there's not. A terminal area (I think the Americans still call it a TRACON) usually has around a 25 nm radius up to, say, 10,000 ft (I don't have the charts with me to check) with increasingly high floors as it moves out, sort-of like an upside-down wedding cake. Terminal areas are most often class D, so everyone (VFR and IFR) still has to get ATC clearances but ATC does not provide positive separation for VFR. Outside of control zones and terminal areas at the lower altitudes we have class E airspace along the airways and terminal area extensions (major approach paths into the terminal areas) and mostly class G elsewhere; I understand that there's little class G in the U.S. In class E, IFR traffic has to be talking to ATC (usually the centre controller), but VFR traffic acts mostly as if it's in class G, except for increased visual minima. VFR traffic can request flight following outside of a terminal area, in which case it talks to centre just like IFR traffic but simply informs center of what it is going to do instead of requesting a clearance (even centre gets confused -- when I inform them that I'm going to climb or descend during VFR flight following, I still sometimes get back new altitude approved). In reality, things are even more complicated; for example, Ottawa terminal has taken over en-route most of the way to Toronto, so almost 100nm out of the Ottawa terminal area I'm still talking to Ottawa terminal for flight following instead of Toronto Centre. Ottawa terminal airspace sort-of collides with Montreal terminal airspace, and there's a pie-shaped chunk carved out of Ottawa terminal airspace up to 4000 ft in the northwest to provide an uncontrolled practice area. There are often also low-altitude corridors to allow planes to fly in and out of satellite airports without having to enter the class C or D airspace of the terminal area or control zone. The charts (U.S. sectional or Canadian VNC) are fascinating reading once you start to get the hang of them. Additionally, if you're into graphs, movement, shortest paths and all that, which is classical sort of AI stuff really, then there's plenty of that to be sorted to get ground control working robustly. I'm plugging away at some textbooks now, but there's lots of work in that that could be spread about. If you read the online aviation discussion forums in the U.S., you'll get the impression that ATC has little to do with shortest paths, either in the air or on the ground. My experience up here has been different, but I don't know how much of that has to do with real differences and how much is cultural (parts of the U.S. have a long-standing cultural paranoia about authority, while we still happily put ER II's face on our money up here). 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?
Norman Vine writes: Question: Is there any reason that ALL of the joysticks from the config files are represented in the 'resident' property tree ?? It's on my TODO list, but it someone else wants to take that over I'll be very happy. 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?
Michael Bonar writes: 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. Many of the code modules I've written have JavaDoc-like comments attached in the *.hxx files -- those might be helpful. 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?
Norman Vine writes: 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 Not everything that is read from an XML file resides in the main property tree; some subsystems also use XML files for initial configuration information. 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: 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 Not everything that is read from an XML file resides in the main property tree; some subsystems also use XML files for initial configuration information. I see that but I thought one of the motivating factors for the 'properties' was to have a central location for all of the 'data' Hence shouldn't the subsytems also stem from global-get_props() too ? Are there reasons that it isn't done this way ? Efficiency isn't a problem as the subsytem can just cache a node to serve as it's local root. Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] What's in the job jar?
They are very helpful, and that's why the first test of Doxygen turned up such good results IMHO. If it's decided that this is the way to go, then a simple code documentation standard would need to be applied to the source to pull out the information we think is valuable. Cheers, Mike On Monday 23 December 2002 08:16, David Megginson wrote: Michael Bonar writes: 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. Many of the code modules I've written have JavaDoc-like comments attached in the *.hxx files -- those might be helpful. 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?
Norman Vine writes: I see that but I thought one of the motivating factors for the 'properties' was to have a central location for all of the 'data' There are different kinds of data. The property tree is meant to represent the shared state of the program; when a subsystem happens to use an XML file to set up its internal state -- information that is of no use to the rest of the program and that cannot be changed without a reinit (i.e. use this texture with these UV coordinates for layer 3 of the instrument) -- it doesn't make sense to clutter the property tree with it. Those trees are usually deleted as soon as the subsystem is set up (i.e. they exist for perhaps 0.1 sec). We could just as easily use another format for internal initialization, but since the XML support is already available, it was the easiest route. 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?
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
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
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] 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] 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] 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
