Re: [Flightgear-devel] Virtual cockpit notes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I would guess this is a major factor in the relatively small amount of aircraft development for Fly! ... I know of several people who have exterior models, but can't contemplate the effort required to assemble a working panel. I think this is a major flaw in developers of aircraft for MSFS and Fly! If you're going to make an aircraft, that means make an aircraft, with a model, panel, sounds and everything. Thanks, David -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8izZRF2H7v0XOYBIRAiSqAKCPy+TlCrDbXu5jV1tV9KLP0/YtOQCfR6Ik NDDiDF66jzuz6rAjaDWJBdo= =2ypv -END PGP SIGNATURE- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Virtual cockpit notes
On Sunday 10 March 2002 05:23 am, you wrote: On Sat, 2002-03-09 at 22:08, Jim Wilson wrote: Fly! uses a 3D cockpit. They use 2D for most of the instrumentation, switches and knobs, and 3D models for the things that really need it like levers. More than likely the legability problem is your LCD at 1600x1200 ;-) In any case we'd be doing great to come up with something as nice and usable as the Fly! cockpits. I'm not trying to start an argument here, but I'm reasonably sure this is not the case. The fly cockpits are simply an enormouse collection of 2D images. The best ones are made by doing a very high detail model in a 3D suite, and then generating all the images as non-perspective-correct (orthographic?) renders. If you look at the throttle levers moving on the PMDG 7x7s, you can see the quality is far too high to be happening in realtime (unless you used lots of special extensions and really high detail meshes on high end hardware). The alternative would be prerendered frames if I undrstand what you are saying. I think what Jim was saying is that the, for example, throttle quadrant, would be a separate 3D model with a separate scene graph. Of course I could be talking out my ass I'd hazard a guess that external light sources aren't applied. The reason I'm going on about this is I'd like to mention a serious downside of the Fly! approach (even though I think the fly cockpits are the best I've ever seen): it takes an awful lot of time and committment to produce even a slightly useable cockpit. I would guess this is a major factor in the relatively small amount of aircraft development for Fly! ... I know of several people who have exterior models, but can't contemplate the effort required to assemble a working panel. I can't really say about Fly, but FGFS 2D panels/instruments are not *that* big a deal to put together. Our current virtual cockpit is the 2D panel overlayed on polygons that represent the vertical surface of the panel, and as such don't have the overhead of a fully 3d rendered (in the sense that every component of every instrument is a 3d model. My experience is that the actual artwork is the hard part. HH James ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Virtual cockpit notes
On Sunday 10 March 2002 05:32 am, you wrote: I would guess this is a major factor in the relatively small amount of aircraft development for Fly! ... I know of several people who have exterior models, but can't contemplate the effort required to assemble a working panel. I think this is a major flaw in developers of aircraft for MSFS and Fly! If you're going to make an aircraft, that means make an aircraft, with a model, panel, sounds and everything. Thanks, David Could possibly be that instrument makers need to get into actual code on these sims, instead of markup like FGFS. I dunno, I've no experience with either ___ 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] Virtual cockpit notes
So David Findlay says: I think this is a major flaw in developers of aircraft for MSFS and Fly! If you're going to make an aircraft, that means make an aircraft, with a model, panel, sounds and everything. If you're saying what I think you're saying (don't bother creating an aircraft unless you're going to create the whole package) I have to say I don't agree. Someone could be an aircraft nut who just wants to recreate a cool paintjob he saw on an aircraft once. Someone else might be a pilot who doesn't like the available panels for an aircraft and decides to make one himself. Someone else might be an aeronautical engineer who decides to improve the flight model for an aircraft. I think it would be an enormous waste if all these people were forced to also provide all the other parts of the package, because in that case they probably wouldn't bother at all. Then there's the element of re-use. The airframe, panel, FDM and sounds for a given aircraft probably don't change much from one individual aircraft to the other, so why create those if you just want to paint an aircraft. You'd be better of re-using what's already there. Provided you give credit where it's due, of course. I think this is one area where MSFS got it right: decouple all the individual pieces of the puzzle, so people can concentrate on their area of expertise, and allow the end-user to pick and choose their favourite elements. My 2 cents. Groeten,- Jacco -- Think about it: | In Real Life: Jacco van Schaik If the wheel had never been | Mail me at: [EMAIL PROTECTED] reinvented, we'd still be | Spam bait:postmaster@localhost driving on logs...| See also http://www.frontier.nl/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Rationalizing view
Michael Selig writes: With respect to the chase view (2), three potential options come to mind: These are excellent suggestions, but I think that we'll want them to end up in the view manager (or elsewhere) rather than in the viewer proper. As long as we tell the viewer, for each frame, what its reference point, orientation, offsets, etc. are, it doesn't need to know whether we're modelling a control tower, chase view, etc. Eventually we might even control some of the views through external scripting. 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] UIUC models update
Where can I get the 3D models with .3ds format? or how can I translate them to .3ds? Is there anyone convert the model of the Pioneer UAV into the JSBSim format? If anyone has them, I'd like to get publicly released 3D models for: - Wright Flyer (I have one, but we have not yet got permission to give it out) - SGS 1-36 - Pioneer UAV - Marchetti S-211 - Learjet 24 - Piper Cherokee I included a link to Wolfram's site for all of the other 3D models. Back to more modeling! Regards, Michael ___ 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] Virtual cockpit notes
Jim Wilson writes: Fly! uses a 3D cockpit. They use 2D for most of the instrumentation, switches and knobs, and 3D models for the things that really need it like levers. I have no experience with FLY2K or FLY2, so I cannot comment on those, but FLY1 definitely uses a 2D cockpit. Granted that there might be a couple of small, animated 3D objects, but the panel is a flat picture projected in its own coordinates that slides in the X/Y axes independently of the outside scene -- that's exactly the definition of a 2D panel. Unlike FlightGear, FLY1 limits the viewing direction to fixed viewpoints and has a separate 2D picture to project for each one. The pictures are beautiful, but there is nothing 3D about it. More than likely the legability problem is your LCD at 1600x1200 ;-) No, it's a 1600x1200 LCD trying to do 1024x768. Unlike CRTs, LCDs have a fixed number of pixels, so they have to double or leave out individual pixels when changing resolutions. The picture is clearer in some ways when I change FLY! to 800x600, but now I've lost 75% of my resolution. Again, I cannot comment on later FLY! versions, except that when I go to window mode (and lose 3D acceleration), the panel becomes clear. In any case we'd be doing great to come up with something as nice and usable as the Fly! cockpits. Artistically, I agree -- they're beautifully rendered and pay a lot of attention to detail. From a modelling perspective, however, they're years out of date, and I think we should aim a lot higher than fixed 2D renditions. Try the Battle of Britain demo to see what a 3D cockpit is like, and you won't want to go back. 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] UIUC models update
Where can I get the 3D models with .3ds format? or how can I translate them to .3ds? Is there anyone convert the model of the Pioneer UAV into the JSBSim format? This would be nice to have - that is, a small program to convert the format from one to ther other. Perhaps someday. It would be nicer if a standard useful to describe aircraft for simulation purposes was already in use. This *is* something which is currently being worked, at least. Jon If anyone has them, I'd like to get publicly released 3D models for: - Wright Flyer (I have one, but we have not yet got permission to give it out) - SGS 1-36 - Pioneer UAV - Marchetti S-211 - Learjet 24 - Piper Cherokee ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Rationalizing view
David Megginson [EMAIL PROTECTED] said: In every case, we want to be able to specify offsets for all six degrees of freedom. I think that it makes sense to put all of this in a single, configurable viewer class, rather than having separater viewer_lookat, viewer_rph, and (eventually) viewer_tower classes that duplicate most of each-others' code. At first look this doesn't seem all that bad. The hardest part is going to be cleaning up the hard coded bits out there. The routines basically all produce the same thing with different methods which helps. Right now what I need to do is map out all the calculations that are being applied and will come up with a proposal to post here. But it should be too bad once I get my head around the whole thing. Basically what I'm going to look at is modularizing the calculation for each matrix component (camera, center, up) so that new methods like some of what Michael described can be easily added. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim changes
[... Tony wrote ...]: OK, after discovering that my original implementation was horribly buggy, I have now committed a better version of the normalized control surface position code to JSBSim and FG cvs. There is a new set of properties for these: /surface-positions/flap-pos-pct [...] Hmmm, would anyone be so kind to add these controls to the 'External(NET)' FDM some time ? I am designing some flight control system for a private model aircraft project and I'd love to use FlightGear for visualization. To be honest: I found my way to the FlightGear project when I was looking for some code that I could steal in purpose to drive a remote display. Unfortunately I had to find out that I don't have the skills to do the 'real' coding myself - except from the very little time critical prototyping in Perl So I am now in the stage of examining the External interface and I would love to use FlightGear visualization to see if I'm correct. There is much more motivation in having visual feedback instead of having numbers only ;-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] UIUC models update
Michael wrote: If anyone has them, I'd like to get publicly released 3D models for: - Wright Flyer (I have one, but we have not yet got permission to give it out) - SGS 1-36 - Pioneer UAV - Marchetti S-211 - Learjet 24 - Piper Cherokee Wright flyer: You can use the one from www.flightsim.com, see my homepage. I am fairly certain there is no pioneer UAV, Schweizer 1-36 and Marchetti 211. But there are Marchetti 205, 208, and 260, maybe they are similar enough in the 3D? The others should be easy. Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Rationalizing view
Jim Wilson writes: At first look this doesn't seem all that bad. The hardest part is going to be cleaning up the hard coded bits out there. Here are most of the required outputs, from an analysis I did earlier: - the VIEW matrix, a matrix containing the transformations to put the view in the correct position and orientation (as as the argument to ssgSetCamera) - the UP matrix, rotation matrix to the current notion of up (opposite of gravity) - the current absolute view position in fgfs coordinates - the current view position in fgfs coordinates, relative to the scenery center - the world-up vector - the surface-east vector - the surface-south vector All of the others are byproducts of the VIEW calculation, used for convenience by various bits of the code. The routines basically all produce the same thing with different methods which helps. Right now what I need to do is map out all the calculations that are being applied and will come up with a proposal to post here. But it should be too bad once I get my head around the whole thing. Basically what I'm going to look at is modularizing the calculation for each matrix component (camera, center, up) so that new methods like some of what Michael described can be easily added. Yes, I've been playing with some of that myself. You'll see that I've already moved some of the common code into the temporary FGViewPoint class -- it gets as far as calculating the absolute and relative view position and the world-up vector. 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] UIUC models update
Wolfram, Thanks for posting the ASW-20 and Wright Flyer 3D models! http://home.t-online.de/home/Wolfram.Kuss/FGFS1/FGFS1.htm My project starting tonight is to get the ASW-20 working. Regards, Michael At 3/10/02, you wrote: Michael wrote: If anyone has them, I'd like to get publicly released 3D models for: - Wright Flyer (I have one, but we have not yet got permission to give it out) - SGS 1-36 - Pioneer UAV - Marchetti S-211 - Learjet 24 - Piper Cherokee Wright flyer: You can use the one from www.flightsim.com, see my homepage. I am fairly certain there is no pioneer UAV, Schweizer 1-36 and Marchetti 211. But there are Marchetti 205, 208, and 260, maybe they are similar enough in the 3D? The others should be easy. Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ** Prof. Michael S. Selig Dept. of Aero/Astro Engineering University of Illinois at Urbana-Champaign 306 Talbot Laboratory 104 South Wright Street Urbana, IL 61801-2935 (217) 244-5757 (o), (509) 691-1373 (fax) mailto:[EMAIL PROTECTED] http://www.uiuc.edu/ph/www/m-selig http://www.uiuc.edu/ph/www/m-selig/faq.html (FAQ) ** ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Virtual cockpit notes
On Sat, 9 Mar 2002, David Megginson wrote: Jim Brennan jjb - writes: The photorealistic instruments in some simulators are good to have, but (IMHO) not as importaint as proper flight modeling. I personally see NO need for the nice views of the airplane, and its moving parts as seen from other airplanes except if one is flying formation or shooting at the airplane. ... or replaying a finished flight to study it, or watching a student's progress in external view on a second monitor, or watching OK, I'll grant you the validity of those two points. the propeller from inside the airplane. but not that one grin! snip While this is nice to have for some limited purpose, it adds nothing to the realism of the simulator from the perspective of the person flying the sim. No, but it might be useful for the instructor to watch, or for the student during a replay of a failed flight. Ok I'll grant you that. These efforts could better be used in improving the flight models, and the functionality of the sim to interface to other sims and external programs and more realistic views (such as those for KSJC). It's not a zero-sum game. The people who are good at flight models (Jon, Tony, Andy, etc.) are already spending pretty-much all their time on flight modelling; contributions to other areas from other people aren't taking away from that. Well, I'll even agree (mostly) with that. I guess my point is that work being done on exterior views of the airplane is not as valuable (from the pilots point of view) as as would work doine to produce more detailed airport areas (as is the case with KSJC). Just IMHO. jj All the best, David -- David Megginson [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] Virtual cockpit notes
Jim Brennan jjb - writes: OK, I'll grant you the validity of those two points. the propeller from inside the airplane. but not that one grin! To start a DC-3 engine, I read that you count 12 blades before you release the starter. I'm not sure whether, in an engine-out on a twin, you're supposed to try to get visual confirmation of which prop is spinning more slowly. 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] Virtual cockpit notes
David Megginson writes: Jim Brennan jjb - writes: OK, I'll grant you the validity of those two points. the propeller from inside the airplane. but not that one grin! To start a DC-3 engine, I read that you count 12 blades before you release the starter. I'm not sure whether, in an engine-out on a twin, you're supposed to try to get visual confirmation of which prop is spinning more slowly. Hey, sort of on the same subject, all of you tracking cvs source/base should do a cvs update -d and check out the new engine starting sequence/sounds. Really cool on the DC-3, especially when watching from an outside view. Good work Eric! If I can get something going with runway lights in the next week or two we might have to start thinking about the next release. :-) 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] Virtual cockpit notes
On Sun, 2002-03-10 at 12:08, David Megginson wrote: Jim Brennan jjb - writes: OK, I'll grant you the validity of those two points. the propeller from inside the airplane. but not that one grin! To start a DC-3 engine, I read that you count 12 blades before you release the starter. I'm not sure whether, in an engine-out on a twin, you're supposed to try to get visual confirmation of which prop is spinning more slowly. In a twin, you'll definitely know which engine is out without looking. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Virtual cockpit notes
Tony Peden writes: In a twin, you'll definitely know which engine is out without looking. If you are well trained and practiced at it ... otherwise if there is a lot of other stuff going on at the time it really may not be so intuitive. 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] ANN: first experimental 3-D cockpit
David Megginson writes:
3. The orientation is incorrect when the view is not straight forward
and the plane is not flying level (waiting for a fix from me, but I
don't understand matrix math well enough) -- that means that when you
look out the side window during a climb or turn, the model will not be
tilted correctly.
Further to this point, could someone who understands matrix math take
a look at src/Main/model.cxx, in the update() method? Where I have
if (view_number == 0) {
// FIXME: orientation is not applied
// correctly when view is not forward
sgMakeRotMat4( sgROT, -pilot_view-get_view_offset()
* SGD_RADIANS_TO_DEGREES, pilot_view-get_world_up() );
sgPreMultMat4( sgTRANS, sgROT );
}
I'm trying to keep the model from following the view around.
Obviously, I have to do some rotations in other planes as well, but
I'm not quite sure how to do it.
Thanks, and all the best,
David
--
David Megginson
[EMAIL PROTECTED]
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Help with XML and preferences.xml
Does anyone have some documentation on how to build the preferences.xml file? I would like to write a preferences manager, if such a tool does no already exist, to make it easier to manage multiple aircraft configurations and settings. The goal for tool is as follows: Language: python 2.x (I know the language and it has good XML tools) GUI: Tk (Tkinter is the standard GUI interface for python) Features: Load XML file, edit it, provide save/save as. I also need to know how FDM specific the preferences file is. I have some experience with Tkinter. but my GUIs tend to be a bit functional (OK, ugly), and I will be learning XML at the same time. Any, and all, help will be greatly appreciated. Thanks, Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Plib Compiling problem
FWIW (probably not much): I think you need the Mesa or OpenGL and glut *developer* package (is that the word?). In the packet manager or somewhere there is a huge list of things you can check and you should probably tell the SuSE packet manager to install it for you. I do not think it is a path problem, although this does happen (but IIRC in other distros). By the way am I right in thought SuSE 7.2 already comes with Glut and Mesa support ? IMHO yes, but maybe you did not enable it. Thanks for any help. Sergio Roth Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Help with XML and preferences.xml
Jonathan Polley writes:
I have some experience with Tkinter. but my GUIs tend to be a bit
functional (OK, ugly), and I will be learning XML at the same
time. Any, and all, help will be greatly appreciated.
If you know LISP (CommonLISP, InterLISP, Scheme, E-LISP, or what-have
you), you're most of the way there.
Think of an XML document as a single toplevel LISP list containing any
number of nested sublists. The top-level list and every sublist are
called 'elements' in XML, and each starts with NAME and ends with
/NAME, where NAME represents the name of the element. So, what you
might represent in LISP as
('person ('name David Megginson) ('citizenship Canadian))
you can represent in XML as
person
nameDavid Megginson/name
citizenshipCanadian/citizenship
/person
An element name must begin with an alpha or '_', and may contain only
alphabetic characters (actually, most Unicode ones, including Chinese,
Arabic, etc.), numerals, '_', '-', or '.'. Technically, they can also
include ':', but that can cause conflicts and should be avoided.
The text inside an element can contain pretty-much all printing
characters, but '' and '' (and sometimes '') must be escaped, like
this:
amp; =
lt; =
gt; =
So in XML text, for a b c d, you'd have
a lt; b amp;amp; c gt; d
It's a bit ugly, but it works.
Comments in XML start with !-- and end with --; they may not contain
the string -- in-between.
You can attach variables, called 'attributes', to each element by
putting a name=value pair in the start tag, like this:
a href=http://www.flightgear.org/;FlightGear/a
The attribute name is href (follows the same rules as element
names), and the value is http://www.flightgear.org/;. The value must
always be quoted with ... or '..', and in addition to the special
character escapes I mentioned above, you can also use the following:
apos; '
quot;
To encode
He said it's best to buy ATT
in an attribute value, you'd do something like
quotation text=He said quot;it's best to buy ATamp;Tquot;/
or
quotation text='He said itapos;s best to buy ATamp;T'/
How elements and attributes are interpreted is almost entirely up to
the application -- XML says how to encode data, but not what the data
means or how it should be processed. In the property manager, we've
decided to treat the XML document like a file system: the root element
(PropertyList) is the filesystem root, and everything else is a
subdirectory or a file (leaf data).
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] Help with XML and preferences.xml
On Sunday, March 10, 2002, at 07:02 PM, David Megginson wrote:
Jonathan Polley writes:
I have some experience with Tkinter. but my GUIs tend to be a bit
"functional" (OK, ugly), and I will be learning XML at the same
time. Any, and all, help will be greatly appreciated.
If you know LISP (CommonLISP, InterLISP, Scheme, E-LISP, or what-have
you), you're most of the way there.
Now I am going to have nightmares ). LISP and I were not the best of friends in college (things like caadaddaddr gives me chills).
Think of an XML document as a single toplevel LISP list containing any
number of nested sublists. The top-level list and every sublist are
called 'elements' in XML, and each starts with NAME> and ends with
/NAME>, where NAME represents the name of the element. So, what you
might represent in LISP as
('person ('name "David Megginson") ('citizenship "Canadian"))
you can represent in XML as
person>
name>David Megginson/name>
citizenship>Canadian/citizenship>
/person>
I believe that python maps dictionaries to XML. The above would be something like:
Someone = {'person': {'name': 'David Megginson',
'citizenship': 'Canadian'}
}
print Someone['person']['name']would yield
'David Megginson'
Since python has a nice mapping between class membership and dictionaries, it may be cleaner than that.
Jonathan Polley
Re: [Flightgear-devel] Help with XML and preferences.xml
Jonathan Polley [EMAIL PROTECTED] said: The preferences file is not FDM specific at all. The contents of preferences.xml in the base package are for the most part self explanatory, I have to beg to differ on this one. For those few command line arguments that I have used, I can find mappings in the preferences files. Where I do not kow the command line arguments, the preferences file is not very clear. For example: instrument-options nav n=0 has-gs-needle1/has-gs-needle needles-pivot1/needles-pivot /nav nav n=1 has-gs-needle0/has-gs-needle needles-pivot1/needles-pivot /nav hsi n=0 has-gs-needle1/has-gs-needle /hsi dg style0/style /dg /instrument-options Hehe. Yep. Didn't notice that one. Actually I don't know why that would be in the preferences.xml. Anyone know why that isn't in the panel or at least aircraft-set xmls? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Help with XML and preferences.xml
Jim Wilson writes: Hehe. Yep. Didn't notice that one. Actually I don't know why that would be in the preferences.xml. Anyone know why that isn't in the panel or at least aircraft-set xmls? A cleanup and reorg is long overdue; same for keyboard mappings. 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] Help with XML and preferences.xml
If you know LISP (CommonLISP, InterLISP, Scheme, E-LISP, or what-have you), you're most of the way there. Now I am going to have nightmares ). LISP and I were not the best of friends in college (things like caadaddaddr gives me chills). Actually, I think they're referring to nested property lists and not to the exciting tricks that can be played with the CONS operator. Another sneaky bonus of XML over LISP is in the bracketing. Instead of having fifteen close parentheses stacked up at the end of the function, you get to say /a/b/c/d/e/f etc. While this is a pain in the butt to type, at least the compiler has a chance of noticing any mistakes. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] New models
Hi! How do I load the new aircraft models? It's just flightgear --prop:sim/model/path=Aircraft/c172-set.xml? I'm using the currrent CVS. []'s Marcio Shimoda Staridia Softworks ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] UIUC Models -- renaming
Hi Folks, While I thought I had everything set ... I've decided to change my aircraft file naming convention on http://amber.aae.uiuc.edu/~m-selig/apasim/Aircraft-uiuc.html. Instead of the ending date + other stuff serving as a version ID, I am just going to end them w/ v1, v2 and so on. I'll have the changes done sometime tonight. Sorry for the shuffle. Regards, Michael ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Help with XML and preferences.xml
On Sunday, March 10, 2002, at 08:04 PM, Alex Perry wrote: Another sneaky bonus of XML over LISP is in the bracketing. Instead of having fifteen close parentheses stacked up at the end of the function, you get to say /a/b/c/d/e/f etc. While this is a pain in the butt to type, at least the compiler has a chance of noticing any mistakes. Which brings to light the old joke about what LISP stand for: Lots of Idiotic Stupid Parenthesis I also never got far enough to find out how to comment a LISP program. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Help with XML and preferences.xml
Sounds like a worth while (sp?) project! The XML files get IMVHO more and more confusing. Maybe lets do the big reorg that Dave speaks about first, with the hope that things won't change often afterwards. When doing the python scripts to generate the very very rudimentary plane xmls on my website http://wolfram.kuss.bei.t-online.de, I saw that for example the spelling of z-offset changed twice and I was told to use a third spelling. Also, it is not clear to me, what the different xmls are for (what does -dpm, -set etc mean? set as in set options? Don't all xmls set options?) and whether you can use all properties in all XMLs and whether you can use all on the command line. So, a UI that showed you what you can do would be very nice. If you use python, you can include my stuff. I would love someone expand on it and say I download a MSFS 3D model, Python unpacks it, moves all files, generates warnings if applicable telling me what to do (for ex.: !This is an old MSFS 95 model, you need to convert it with the MS converter first, sorry!), lets me create a *.ppeloc file, generates the XML file with the z-offset and the pitch-deg for me, lets me choose a FDM, panel etc, inputs it into the XMLs, generates a small batch file to call everything, etc. Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Help with XML and preferences.xml
On Monday 11 March 2002 02:32 am, you wrote: Sounds like a worth while (sp?) project! The XML files get IMVHO more and more confusing. Maybe lets do the big reorg that Dave speaks about first, with the hope that things won't change often afterwards. When doing the python scripts to generate the very very rudimentary plane xmls on my website http://wolfram.kuss.bei.t-online.de, I saw that for example the spelling of z-offset changed twice and I was told to use a third spelling. Also, it is not clear to me, what the different xmls are for (what does -dpm, -set etc mean? set as in set options? Don't all xmls set options?) and whether you can use all properties in all XMLs and whether you can use all on the command line. dpm == Davids initials set == set of components, as in the set comprised of panel A, model B and FDM C. I wasn't thrilled with it when I thought of it, but I had to do something to avoid confusion because the FDM config files have nothing to identify that they are for the FDM in the filename. So, a UI that showed you what you can do would be very nice. If you use python, you can include my stuff. I would love someone expand on it and say I download a MSFS 3D model, Python unpacks it, moves all files, generates warnings if applicable telling me what to do (for ex.: !This is an old MSFS 95 model, you need to convert it with the MS converter first, sorry!), lets me create a *.ppeloc file, generates the XML file with the z-offset and the pitch-deg for me, lets me choose a FDM, panel etc, inputs it into the XMLs, generates a small batch file to call everything, etc. Bye bye, Wolfram. ___ 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] Help with XML and preferences.xml
On Monday 11 March 2002 02:32 am, you wrote: snip choose a FDM, panel etc, inputs it into the XMLs, generates a small batch file to call everything, etc. The set files do what said batch file would do. They are the top level aircraft config. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
