Norman Vine wrote:
>
> David Megginson writes:
> >
> >Norman Vine writes:
> >
> > > IMHO the biggest obstacle to reading and developing FGFS code is
> > > the formatting
> > >
> > > We really need a mechanical formating means that is acceptable to
> > > every one as the CVS standard even if it is
David Megginson writes:
>
>Norman Vine writes:
>
> > IMHO the biggest obstacle to reading and developing FGFS code is
> > the formatting
> >
> > We really need a mechanical formating means that is acceptable to
> > every one as the CVS standard even if it is not perfect or even
> > close to what
On Sun, 17 Mar 2002 14:03:31 -0500,
"Norman Vine" <[EMAIL PROTECTED]> wrote in message
<001801c1cde6$6f3e2380$a300a8c0@nhv>:
> hence my suggestion to find a set of settings for one of the
> 'beautifiers' that the code is run through, this way everyone can work
> on the code formatted in their p
"Jon Berndt" <[EMAIL PROTECTED]> writes:
> I ran into this problem when looking through FlightGear code in the past.
> It's hard to keep track of things like:
>
> #ifdef xxx
> 200 lines of code
> #else
> 100 lines of code
> #endif
If you happen to be using Emacs (available on Windows, the vari
On Sun, 17 Mar 2002 07:27:07 -0500,
David Megginson <[EMAIL PROTECTED]> wrote in message
<[EMAIL PROTECTED]>:
> Alex Perry writes:
>
> > > Fair enough. I certainly overengineered props.[ch]xx, in
> > > anticipation of all kinds of sophisticated stuff that people
> > > never bothered doing.
Curtis L. Olson writes:
> If you are willing to setup these files and keep them from getting too
> far out of date, then this sounds like a reasonable proposal to me.
I don't mind setting up the READMEs. The others will be set up as
needed.
All the best,
David
--
David Megginson
[EMAIL
David Megginson writes:
> Perhaps we should stick three
> files in every code directory: a README file, explaining what the code
> in the directory does, a PLANS file, where we can put ideas for future
> interfaces, and an ATTIC file, where we can paste old code we might
> need again some day. Wh
Jim Wilson writes:
> From where I sit, I'd have to agree more with David. There should
> be no cruft left in the code that gets committed. This doesn't
> mean individual developers can't keep it around on there local
> drive, but once something is good enough to commit it should
> contain
Norman Vine writes:
> Curtis L. Olson writes:
> >
> >I'd be happy if somewone could find a decent code [re]formatter that
> >gave us enough flexibility to make our own style choices and didn't
> >have glaring ommission or do really stupid things.
>
> astyle is the only 'free' beautifier I know of
Jim Wilson writes:
> From where I sit, I'd have to agree more with David. There should be no cruft
> left in the code that gets committed. This doesn't mean individual developers
> can't keep it around on there local drive, but once something is good enough
> to commit it should contain working
Norman Vine <[EMAIL PROTECTED]> said:
> I realize that this is a 'religous' issue and a 'tough' problem but IMHO
> it is a major obstacle to FGFS code evolution
>
It is a tough problem to solve, but I haven't found it to be much of a problem
reading fgfs code (have seen much worse). Maybe I'm
Curtis L. Olson writes:
>
>I'd be happy if somewone could find a decent code [re]formatter that
>gave us enough flexibility to make our own style choices and didn't
>have glaring ommission or do really stupid things.
astyle is the only 'free' beautifier I know of that does a reasonable
job on c++
"Curtis L. Olson" <[EMAIL PROTECTED]> said:
> If something doesn't make sense, or seems out of place, there's no
> harm in asking ... perhaps the author will look at the 'cruft' and say
> oh yea, nothing valuable there, we can axe it. But perhaps the code
> is there is for valid reasons and it's
David Megginson writes:
> I disagree that this is the biggest obstacle (or even one of the top
> 10), but then, I use an editor (XEmacs) with syntax highlighting,
> brace matching, language-based navigation (jump forward one function),
> etc., so those features might be hiding the problem from me.
Norman Vine writes:
> IMHO the biggest obstacle to reading and developing FGFS code
> is the formatting
>
> We really need a mechanical formating means that is acceptable to every
> one as the CVS standard even if it is not perfect or even close to what one
> would personally use.
When I've lo
> If the page being shown does not show the #ifdef, it can be really
> confusing. I can't recall any specific examples of this in the code, but I
> remember being bitten by this kind of thing a couple of times when perusing
> some of the base FlightGear code.
Some of it is simply people being po
Norman Vine writes:
> IMHO the biggest obstacle to reading and developing FGFS code is
> the formatting
>
> We really need a mechanical formating means that is acceptable to
> every one as the CVS standard even if it is not perfect or even
> close to what one would personally use.
I disag
Jon Berndt writes:
> Elimination of dead code (as we all know, CVS is really good for
> tracking past changes) and better documentation would be really
> helpful. We'd like to be better in JSBSim too - we all face this.
Absolutely. While I don't tend to keep #ifdef's around, some of my
code
David Megginson writes:
>
>Curtis L. Olson writes:
>
> > I know you are making a point by using extereme wording, but if you
> > are running through the woods, it doesn't hurt to look up once in a
> > while.
> I'm willing to bet that
>FlightGear contributors spend more time trying to understand e
> This is where we disagree -- keeping it in makes the code much harder
> for new (and existing) contributors to read and understand, gives
> false hits when searching for variables and method calls, etc. etc.
> With CVS, it's trivially easy to look at or restore old code later if
> we need to; I'
Curtis L. Olson writes:
> I know you are making a point by using extereme wording, but if you
> are running through the woods, it doesn't hurt to look up once in a
> while.
I preached full interface design in advance through much of the 1990s
-- it seemed like a good idea. I now freely renou
David Megginson writes:
>
>For the record, I don't agree with the XP people on team programming
Hopefully you will eventually come to embrace that concept too. :-)
Cheers
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightge
David Megginson writes:
> One thing that has impressed me about Andy Ross's code over most of
> the rest of FlightGear (including any of my own contributions that I
> haven't looked at for a few months) is that I was able to understand
> most of his code immediately. Part of that is because he us
Alex Perry writes:
> > Fair enough. I certainly overengineered props.[ch]xx, in anticipation
> > of all kinds of sophisticated stuff that people never bothered doing.
> > I've been learning, slowly, from the XP people to build only for today
> > (all my training previously was to anticipate
David Megginson writes:
>>
>Also, if we add the ability to get surface attributes, it will be
>obvious when one wheel slips off the side of the runway onto the
>grass or gravel.
FWIW the Hitlist code has had the capability to return the ssgState
assosciated with the triangle 'hit' < intersected
> Fair enough. I certainly overengineered props.[ch]xx, in anticipation
> of all kinds of sophisticated stuff that people never bothered doing.
> I've been learning, slowly, from the XP people to build only for today
> (all my training previously was to anticipate future needs, and it's
> hard to
Andy Ross writes:
> I really don't subscribe to the "indirection above all" school of
> software engineering, where the slightest hint that change might be
> coming is enough to justify all sorts of contortions in the code.
> Sometimes, simple things really should be left simple.
Fair enough
> And to pick on a silly point: it would never be called "YAexit".
I thought it was quite appropriate ... "Yet Another Exit Function" YAexit().
8-)
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightg
> And you really don't get much for your effort. The data that you get
> with the exception is only what the thrower thought to include. And
> the (IMHO) most important part, the stack trace, isn't available at
> all! This is why I prefer the crashing idiom -- a crash gives you a
> stack trace.
C. Hotchkiss wrote:
> The fact that the program exits gracefully as opposed to crashing with
> a null de-reference helps considerably. The former says something
> unacceptable or unhandled occurred. In this case, if we could turn on
> a parser log it could do a lot in pinpointing XML problems.
C. Hotchkiss writes:
> Should we add good exception handling in the future, then throwing and
> catching exceptions would make for a more robust way of dealing with a lot
> of problems. And, it would probably be more informative.
We have exception support and we use it, but there's a gotcha:
Andy Ross wrote:
> I wrote:
> > This is the YASim XML parser. You hit this line when an
> > unrecognized tag is found in the XML file.
>
> In an attempt to keep blood pressures in a healthy range ...
Good. Hate to loose a contributor to cerebral hemorrhage. Very messy. Not
fun. ;-)
>
> It's
> You have a chicken-and-egg bug here: The tire contact point is
> *defined* as the intersection of the gear compression vector with the
> ground. You can't possibly ask for the elevation beneath it until you
> know it. Going back to the same diagram, the point of the wheel is
> the "result" of
On Fri, 15 Mar 2002 10:02:38 -0800,
Andy Ross <[EMAIL PROTECTED]> wrote in message
<[EMAIL PROTECTED]>:
> I wrote:
> > This is the YASim XML parser. You hit this line when an
> > unrecognized tag is found in the XML file.
>
> In an attempt to keep blood pressures in a healthy range this mor
Jon S. Berndt wrote:
> We, of course, track the local frame position of the contact point of
> the tire. We are not measuring elevation using the CG, nor the attach
> point of the strut to the body. I keep repeating myself here, but when
> I ask for elevation, I am asking for it at the point D
On Fri, 2002-03-15 at 15:29, Andy Ross wrote:
> Tony Peden wrote:
> > Andy Ross wrote:
> > > Tony Peden wrote:
> > > > Only the gear model can and should "know" the path that the wheel
> > > > follows as it compresses.
> > >
> > > I don't necessarily disagree,
> >
> > But by asking the sce
On Fri, 15 Mar 2002 16:40:38 -0800
Andy Ross <[EMAIL PROTECTED]> wrote:
>Here's another ASCII diagram (please don't mock this one)
>to try to explain:
This is actually pretty good for an ascii diagram and it
shows where the misunderstanding is coming onto play.
>
>+
>.\
>
Jon S. Berndt wrote:
> Given a *NON-FLAT* polygon, how do we place the aircraft on it
> properly so the gear doesn't sink in on one side and sit above it on
> the other? The answer is that you give each gear the blasted elevation
> at that gear. How can I make it any plainer?
Jon, I'm running
On Fri, 15 Mar 2002 15:29:05 -0800
Andy Ross <[EMAIL PROTECTED]> wrote:
>We either have to have scenery code that understands funny gear
>trajectories or gear code that understands 3D collision
>detection.
We can be fairly simple. If you want to do articulated
F-18 gear, be my guest. All I wa
On Fri, 15 Mar 2002 14:51:33 -0800
Andy Ross <[EMAIL PROTECTED]> wrote:
>I'm not quite sure what you mean by the 3D model. Assuming vertical
>gear compression is no closer to rendered reality than what we are
>doing now. You'll get a tilt, but not a physically correct one.
It will be better
On Fri, 15 Mar 2002 14:42:27 -0800
Andy Ross <[EMAIL PROTECTED]> wrote:
>Sigh... grab a calculator. Type "2", then "0", then "sin". :)
>The answer to this question:
>
> How far from the original position is the tip of a gear strut at 20
> degrees of AoA (or bank, or whatever)?
>...is "34% of
Andy Ross writes:
>
>I guess I'm just a little flummoxed at the resistance to doing things
>"right" here. I mean, it doesn't take any more CPU time; it doesn't
>make the FDM's job any more complicated, and it's reasonably
>well-supported by the scenery code as-is. All that's needed is an
>interf
Tony Peden wrote:
> Andy Ross wrote:
> > Tony Peden wrote:
> > > Only the gear model can and should "know" the path that the wheel
> > > follows as it compresses.
> >
> > I don't necessarily disagree,
>
> But by asking the scenery code to do the intersection for you, that's
> exaclty what
On Fri, 2002-03-15 at 14:51, Andy Ross wrote:
> Tony Peden wrote:
> > Andy Ross wrote:
> > > You give the scenery the position of the gear min/max comprssion
> > > points, and it tells you where the tip really is.
> >
> > That is, IMO, precisely the job of the gear model. Only the gear
> >
Tony Peden wrote:
> Andy Ross wrote:
> > You give the scenery the position of the gear min/max comprssion
> > points, and it tells you where the tip really is.
>
> That is, IMO, precisely the job of the gear model. Only the gear
> model can and should "know" the path that the wheel follows
Jon S. Berndt wrote:
> Andy Ross wrote:
> > What part of "assuming a flat ground" is not getting across? :)
>
> I was trying to figure out where you got that 34% error from.
Sigh... grab a calculator. Type "2", then "0", then "sin". :)
The answer to this question:
How far from the origin
On Fri, 15 Mar 2002 13:55:49 -0800
Andy Ross <[EMAIL PROTECTED]> wrote:
>What part of "assuming a flat ground" is not getting across? :)
I was trying to figure out where you got that 34% error
from.
>If you are willing to assume a flat ground, then you already *have* a
>valid and workable mo
Jon S. Berndt wrote (or, strictly, didn't write):
> Andy Ross writes:
> // If the line segment intersects
> // the scenery more than once,
>
> !?!?
/\
p1--+--+---p2
/\
/ground\
--
Andrew J. RossNextBus Information Systems
Senior Software Engineer Eme
Jon S. Berndt wrote:
> Try using a cosine if you are talking about spring compression. An
> aircraft with a straight strut extending straight down from the wing,
> with the aircraft at twenty degrees alpha would compress the strut
> about 4.25 inches instead of 4 inches
>
> (when using pure
Tony Peden writes:
> > And think carefully about the simplification you propose. Yes, it
> > works in most case. But the existing code already works in most cases
> > -- all of the situations where we can get away with a simplified
> > per-gear model are *also* fine with the existing code.
Jon S Berndt writes:
> I wonder if modeling this as a pure aural cue would be
> enough?
Until Linux and PLIB support force-feedback controllers, it might be.
For many surfaces, though, we will want the plane to bounce around
visibly.
All the best,
David
--
David Megginson
[EMAIL PROTECT
On Fri, 2002-03-15 at 13:03, Andy Ross wrote:
> Jon S. Berndt wrote:
> > Andy Ross wrote:
> > > Ski jumps are an immediate counter example.
> >
> > Modeling ski jumps are the one example I can think of - the single
> > special case - where this is important. [How many terrain polygons
> > wi
On Fri, 15 Mar 2002 14:45:35 -0800 (PST)
Gene Buckle <[EMAIL PROTECTED]> wrote:
>Well from a strict user standpoint, this would be neat to have, especially
>the "thump" you get when crossing expansion joints on concrete runways. :)
I wonder if modeling this as a pure aural cue would be
enough
On Fri, 15 Mar 2002 12:50:08 -0800
Andy Ross <[EMAIL PROTECTED]> wrote:
>And even so, it's not the *position* of the gear tip that is the
>problem, it is the *direction* of the compression vector. An 20
>degree difference from vertical (not a terribly uncommon AoA for a jet
>touchdown, or bank
Jon S. Berndt wrote:
> Andy Ross wrote:
> > Ski jumps are an immediate counter example.
>
> Modeling ski jumps are the one example I can think of - the single
> special case - where this is important. [How many terrain polygons
> will it take to accurately model a ski jump, anyhow?] I'm not
* [EMAIL PROTECTED] (Norman Vine) [2002.03.16 14:42]:
> Curtis L. Olson writes:
> >This is true in extreme cases, but even at angles where the gear would
> >hit first (maybe more so for certain aircraft configurations), the
> >gear extension angle and extension amount will move the lon/lat of the
> * YASim can use the flat earth to compute a consistently flat runway
>for the gear to press against, for example. With a per-gear
>elevation like this, there would be no way to prevent the airplane
>from seeing a "stair-step" (really, escalator) configuration
>instead, which doe
> I guess we could try to model running over 'curbs and 'potholes' ' but
>
Would it be that difficult to do? It certainly would add some fidelity to
the ground-handling. Is this the kind of thing that's required handling
in the Level D sims?
g.
--
"I'm not crazy, I'm plausibly off-nomi
Andy Ross writes:
>
>Norman Vine wrote:
> > Who better then the FDM to know the offsets of the points to test
> > for contact. It certainly shouldn't be anything in the Scenery
> > Module !!
>
>Of course not. You would be told the points to test by the FDM.
>
>The problem is that the gear aren'
Norman Vine wrote:
> Unless runways aren't anywhere near as flat in reality as I was
> trained to build them when I was in the Corp of Engineers I wouldn't
> expect a difference of 1-2 meters in a horizontal direction to be more
> then a couple of centimeters in the vertical. < ie dy/dx usual
On Fri, 15 Mar 2002 12:11:59 -0800
Andy Ross <[EMAIL PROTECTED]> wrote:
>Ski jumps are an immediate counter example.
Modeling ski jumps are the one example I can think of -
the single special case - where this is important. [How
many terrain polygons will it take to accurately model a
ski j
Curtis L. Olson wrote:
> Andy Ross wrote:
> > Actually, there needs to be a way to disambiguate the case where p1
> > is actually below ground, too.
>
> It shouldn't be too hard to test that the resulting contact point is
> between p1 and p2 ...
Yeah, that's one way to do it. But, as I spe
Curtis L. Olson writes:
>>
>This is true in extreme cases, but even at angles where the gear would
>hit first (maybe more so for certain aircraft configurations), the
>gear extension angle and extension amount will move the lon/lat of the
>contact point. Perhaps the differences won't be significa
On Fri, 15 Mar 2002 13:55:10 -0600 (CST)
"Curtis L. Olson" <[EMAIL PROTECTED]> wrote:
> ... the gear extension angle and extension amount will move the
>lon/lat of the contact point. Perhaps the differences won't be
>significant enough to significantly change the resulting ground
> elevation?
Jon S. Berndt wrote:
> If the aircraft is not aligned vertically (or nearly so), the wingtips
> (or other contact points) will scrape and gear location will be
> irrelevant. Indeed, at extreme angles the gear will either be
> inaccessible or will be treated as a hard contact point. We can get
Andy Ross writes:
> Of course not. You would be told the points to test by the FDM.
>
> The problem is that the gear aren't simple points; they can compress,
> and thus are geometrically line segments.
And occasionally they are a more complex linkage and can follow funky
curves (or in the case
Norman Vine wrote:
> Who better then the FDM to know the offsets of the points to test
> for contact. It certainly shouldn't be anything in the Scenery
> Module !!
Of course not. You would be told the points to test by the FDM.
The problem is that the gear aren't simple points; they can com
Jon S Berndt writes:
> If the aircraft is not aligned vertically (or nearly so),
> the wingtips (or other contact points) will scrape and
> gear location will be irrelevant. Indeed, at extreme
> angles the gear will either be inaccessible or will be
> treated as a hard contact point. We can ge
Jon S Berndt writes:
>. We can get complicated at
>some point in the future. Right now all we want is to be
>able to determine the elevation at a given lat/lon.
Jon
I URGE you and everyone else to think in terms of 'direction cosine'
XYZ's instead of lat/lons and where possible to use the pre
Jon S Berndt writes:
> On Fri, 15 Mar 2002 13:15:04 -0500
> "Norman Vine" <[EMAIL PROTECTED]> wrote:
>
> >Who better then the FDM to know the offsets of the points to test for
> >contact. It certainly shouldn't be anything in the Scenery Module !!
> >
> >Norman
>
>
> Yep. I think all we (FDM
Andy Ross writes:
>
>Norman Vine wrote:
> > Jon S Berndt wrote:
> > > David Megginson wrote:
> > > > That's good news -- I'd like to encourge the FDM writers to query
> > > > separately for each gear now, at least for the wheels and skids
(crash
> > > > points aren't as serious).
> > >
> > > So, w
On Fri, 15 Mar 2002 13:15:04 -0500
"Norman Vine" <[EMAIL PROTECTED]> wrote:
>Who better then the FDM to know the offsets of the points to test for
>contact. It certainly shouldn't be anything in the Scenery Module !!
>
>Norman
Yep. I think all we (FDM) need is a function that returns
the te
On Fri, 2002-03-15 at 09:47, Andy Ross wrote:
> Norman Vine wrote:
> > Jon S Berndt wrote:
> > > David Megginson wrote:
> > > > That's good news -- I'd like to encourge the FDM writers to query
> > > > separately for each gear now, at least for the wheels and skids (crash
> > > > points aren'
I wrote:
> This is the YASim XML parser. You hit this line when an
> unrecognized tag is found in the XML file.
In an attempt to keep blood pressures in a healthy range this morning,
I've modified the YASim parser to print messages and exit on parse
errors, rather than crash.
It's still no mo
Tony Peden writes:
> So then, we'd need to convert from our body coordinates to FG's global
> cartesian?
You already have the absolute position, so you need only to add in the
body coordinates rotated to the body axes, I think.
All the best,
David
--
David Megginson
[EMAIL PROTECTED]
_
Jon S Berndt writes:
> So, when querying, would we supply the lat/lon/radius of
> each bogey of interest, then get the height above ground?
I think so. We might want to rewrite the interface so that you can
supply offsets in meters, but that would require a bit of thought.
All the best,
Andy Ross writes:
> This is correct only so long as the gear struts are pointing straight
> down, with many aircraft (even at their touchdown attitude) this isn't
> the case. How much harder would it be to give you a gear location and
> an extension vector, and get the intersection of that vector
Norman Vine wrote:
> Jon S Berndt wrote:
> > David Megginson wrote:
> > > That's good news -- I'd like to encourge the FDM writers to query
> > > separately for each gear now, at least for the wheels and skids (crash
> > > points aren't as serious).
> >
> > So, when querying, would we suppl
Norman Vine wrote:
> ARRRG
>
> I just discovered this piece of code in the CVS
>
> } else {
> *(int*)0=0; // unexpected tag, boom
> }
>
> I will leave the name calling and expletives out but
>
> THIS IS RUDE ARROGANT AMATURISH PROGRAMMING
> TO THE MAX and completely UNACCEPTABL
Tony Peden writes:
> Norman Vine wrote:
>> Jon S Berndt
>> > David Megginson <[EMAIL PROTECTED]> wrote:
>> >
>> >>That's good news -- I'd like to encourge the FDM writers to query
>> >>separately for each gear now, at least for the wheels and skids (crash
>> >>points aren't as serious).
>> >
>>
On Fri, 2002-03-15 at 08:47, Norman Vine wrote:
> Jon S Berndt
>
> >On Fri, 15 Mar 2002 10:00:28 -0500
> > David Megginson <[EMAIL PROTECTED]> wrote:
> >
> >>That's good news -- I'd like to encourge the FDM writers to query
> >>separately for each gear now, at least for the wheels and skids (cr
* [EMAIL PROTECTED] (Jon S Berndt) [2002.03.16 09:40]:
> On Fri, 15 Mar 2002 09:44:07 -0500
> >1) CHANGE THIS ASAP to at least print an error message
> > or
> >2) defend this hack publicly
>
> Where is the code located?
$ find . -type f | xargs grep "(int\*)0=0"
./src/FDM/YASim/FGFDM.cpp: *(
Jon S Berndt
>On Fri, 15 Mar 2002 10:00:28 -0500
> David Megginson <[EMAIL PROTECTED]> wrote:
>
>>That's good news -- I'd like to encourge the FDM writers to query
>>separately for each gear now, at least for the wheels and skids (crash
>>points aren't as serious).
>
>So, when querying, would w
Jon S Berndt wrote:
> On Fri, 15 Mar 2002 09:44:07 -0500
>
>> 1) CHANGE THIS ASAP to at least print an error message
>> or 2) defend this hack publicly
>
>
> Where is the code located?
Hehe, relax it's not JSBSim ...
Erik
___
Flightgear-devel m
Norman Vine wrote:
> ARRRG
> There is some good news however
>
> After discovering that the above was responsible for
> unexplained crashing at startup with some configurations
> I can announce that I have a new Height above Ground algorithm
> that is MUCH faster < read order of magnitude
On Fri, 15 Mar 2002 10:00:28 -0500
David Megginson <[EMAIL PROTECTED]> wrote:
>That's good news -- I'd like to encourge the FDM writers to query
>separately for each gear now, at least for the wheels and skids (crash
>points aren't as serious).
So, when querying, would we supply the lat/lon/ra
On Fri, 15 Mar 2002 09:44:07 -0500
>1) CHANGE THIS ASAP to at least print an error message
> or
>2) defend this hack publicly
Where is the code located?
>=
>
>There is some good news however
>
>After discovering that the above was responsible for
>unexplained crashing at star
Norman Vine writes:
> Note for the FDM writers This means that queries for multiple < 3
> or 4 > gear locations should be quicker then just the single query
> was before
That's good news -- I'd like to encourge the FDM writers to query
separately for each gear now, at least for the wheels and
ARRRG
I just discovered this piece of code in the CVS
} else {
*(int*)0=0; // unexpected tag, boom
}
}
I will leave the name calling and expletives out but
THIS IS RUDE ARROGANT AMATURISH PROGRAMMING
TO THE MAX and completely UNACCEPTABLE in a complex
project like FlightGear where
89 matches
Mail list logo
