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 one would
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 not perfect or even
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 future
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 uses
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]
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
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'm
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 is
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
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 looked,
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.
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 worth
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++
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 not
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 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 that does
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
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. When
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
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. I've been
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 various
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 prefered
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:
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.
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. :)
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]
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. I
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
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
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 startup with
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/radius
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
At
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 mailing
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 we supply the
* [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: *(int*)0=0;
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 (crash
points
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).
So, when querying, would we
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 UNACCEPTABLE in a
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 supply the
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
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,
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]
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
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't as serious).
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 terrain
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, when querying, would we
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) need is a
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
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 get
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
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 of
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
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?
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 significant
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 usually
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
* 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 doesn't
* [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
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 sure I
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
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
will it take to
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
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 Z
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
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 model
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 original position
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 as it
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
model can and
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 you are doing,
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
interface
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 its length.
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 than
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 want
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 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.
+
.\
.
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 scenery code to do the
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
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 the
78 matches
Mail list logo
