RE: [Flightgear-devel] ARGGHHH !
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 personally use. 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. The problem, which I am guessing you don't see, is I believe due to much of the source having a mix of tabs and spaces in the formatting. FWIW try setting your tab-size to 4 spaces I think the cure for this is to have everyone detab their source before submission or if people insist on using the emacs feature of automagically converting whitespace to tabs to add a hints line in a comment saying what the 'reccomended' tab size settings are for the file, I believe EMACS variants can automate this and even automagically adjust themselves to use the 'per file setting' Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ARGGHHH !
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 close to what one would personally use. 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. The problem, which I am guessing you don't see, is I believe due to much of the source having a mix of tabs and spaces in the formatting. FWIW try setting your tab-size to 4 spaces No, please! Tab is 8 spaces. Or Tab is as well 4 spaces as it is 2 spaces or 8 spaces. I think the cure for this is to have everyone detab their source before submission or if people insist on using the emacs feature of automagically converting whitespace to tabs to add a hints line in a comment saying what the 'reccomended' tab size settings are for the file, I believe EMACS variants can automate this and even automagically adjust themselves to use the 'per file setting' Yes, the code would already benefit heaps when all tabs would be replaces with spaces. Who cares about the wasted space when we have modern harddisks. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ARGGHHH !
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 needs, and it's hard to let that go). It's nice to have a concept that can support all that stuff if/when we have an excuse to make use of it. Put the methods and stuff into the header file, with a comment that they are not implemented yet, and have the implementations break if used. That makes it easier to have backward compatible code when the snazzy features get added. Yes, except that I think we're paying a price with a couple of levels of unnecessary indirection and with code that no one but me can understand. I'd like to keep most of the user-level stuff intact, but to remove the developer-level stuff we're not actually using and reduce the number of layers. 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 good, clear design patterns, but a lot of it is because he is a good practitioner of worse-is-better: when in doubt seems to err on the side of leaving stuff out rather than putting it in. From my experience both on open source and on large commercial projects, I've come to agree entirely with the XP people on certain points: 1. Never write code that you don't need right now, and never make a design more complicated than it needs to be for today. On average, it's cheaper to add one new feature later, when it's needed, than to waste time and obfuscate code by adding twenty new features now purely on spec. 2. Deleting code is as important as writing code. Never leave old code lying around. Instead of commenting or #ifdef'ing stuff out, delete it. If no one's using a particular class or method any more, delete it. If only a class or method is used in only a couple of places, try refactoring the code to use a different approach then delete the class or method. Curt and I disagree on the second point but try (most of the time) to respect each-other's opinions. Personally, I believe that (especially with CVS and ediff-revision in XEmacs for restoring old stuff) the cost of leaving in a lot of commented-out old code is painfully high -- it makes the code hard to understand and maintain, so people tend not to touch it until either something breaks or the whole development stalls. We have to try to write code that a new developer can understand the first time through, and that means keeping it short and simple and avoiding indirection and subclassing wherever possible (the last point shouldn't be controversial, since modern OO design frowns on excessive subclassing anyway). For the record, I don't agree with the XP people on team programming or the unimportance of documentation. 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] ARGGHHH !
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 good, clear design patterns, but a lot of it is because he is a good practitioner of worse-is-better: when in doubt seems to err on the side of leaving stuff out rather than putting it in. From my experience both on open source and on large commercial projects, I've come to agree entirely with the XP people on certain points: 1. Never write code that you don't need right now, and never make a design more complicated than it needs to be for today. On average, it's cheaper to add one new feature later, when it's needed, than to waste time and obfuscate code by adding twenty new features now purely on spec. 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. 2. Deleting code is as important as writing code. Never leave old code lying around. Instead of commenting or #ifdef'ing stuff out, delete it. If no one's using a particular class or method any more, delete it. If only a class or method is used in only a couple of places, try refactoring the code to use a different approach then delete the class or method. Curt and I disagree on the second point but try (most of the time) to respect each-other's opinions. Perhaps you misunderstand my position. It's one thing to delete crufty old useless code. However, there may be reasons to keep old code #ifdef'd in. And it certainly doesn't hurt to ask before you delete someone else's old code. Personally, I believe that (especially with CVS and ediff-revision in XEmacs for restoring old stuff) the cost of leaving in a lot of commented-out old code is painfully high -- it makes the code hard to understand and maintain, so people tend not to touch it until either something breaks or the whole development stalls. I think there needs to be a balance here. Yes, cruft can get in the way, but code represents knowledge. Code represents experience. Code is the solution to a problem. For myself personally, if I am the author of a section of code, and if I am the one who has to maintain it and answer questions, I *certainly* should have the right to leave comments and hints and 'knowledge' and 'experience' included in that body of code. There may be very good reasons why the author includes it that aren't immediately obvious. 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 keeping. We have to try to write code that a new developer can understand the first time through, and that means keeping it short and simple and avoiding indirection and subclassing wherever possible (the last point shouldn't be controversial, since modern OO design frowns on excessive subclassing anyway). Yup, on this point I agree with you completely. 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] ARGGHHH !
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.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ARGGHHH !
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 renounce that view. Dead code is just too expensive to keep around; I'm willing to bet that FlightGear contributors spend more time trying to understand existing code (including mine) than writing new code. Perhaps you misunderstand my position. It's one thing to delete crufty old useless code. However, there may be reasons to keep old code #ifdef'd in. 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 strongly in favour of keeping the onscreen code short, clean, and uncluttered. Unlike the XP people, however, I am a big supporter of explanatory comments. There are parts of FlightGear that have a single, well-known maintainer (such as YASim or WeatherCM), but a lot of the dead code is in the well-trodden public corridors of FlightGear, like fg_init.cxx, main.cxx, etc. 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] ARGGHHH !
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 strongly in favour of keeping the onscreen code short, clean, and uncluttered. Unlike the XP people, however, I am a big supporter of explanatory comments. There are parts of FlightGear that have a single, well-known maintainer (such as YASim or WeatherCM), but a lot of the dead code is in the well-trodden public corridors of FlightGear, like fg_init.cxx, main.cxx, etc. 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 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. 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. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] ARGGHHH !
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 pretty badly obfuscated right now, so I need to take care of the beam in my own eye before I do too much more preaching about everyone else's slivers. 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] ARGGHHH !
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 polite and leaving another developer's code in the file rather than deleting it for them. However, unless the person who #ifdef'ed the code tells the other developer to look at it, this is unlikely to be noticed and thereafter deleted. 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. How about doing this kind of diff ? /* The clever function was removed from the CVS after rev 2.13.4 */ int clever() [] Anybody who is interested can cvs update back to that version and read it through ... without cluttering things up. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] ARGGHHH !
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, I've not found any acceptably tools to do automatic formatting of C++ code. The *very* few tools that did exist either were far too simplistic and weren't to the point of actually being useful or made horrible awful choices without providing a way to override those choices. The closest thing I've found to a usable tool is emacs, but that is interactive and not something you can batch, and it is very limitted in what it does and occasionally does some ugly stuff too. FWIW, I try to fix really poorly / inconsistantly formated code as it's submitted, but I'm not perfect either. This way everyone could format the code in a way that helped them understand it and the CVS maintainers could easily compare submissions against existing code FWIW I find a large percentage of the code very difficult to read because of indentation does not match structure and lack of whitespace I know that Curt often has had a difficult time with my submissioons because of massive whitespace change but in all due respect the majority of these changes were necessary inorder fo me to understand the code. With all corresponding due respect, these white space changes may help you understand the code, but they are anything but consistant, and they rarely follow the conventions of the code you are tweaking. That IMHO just makes things a lot messier and harder for anyone else to read. I realize that this is a 'religous' issue and a 'tough' problem but IMHO it is a major obstacle to FGFS code evolution 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. BTW, Norman, are you having fun hitting all the religeous hot buttons here since your return? :-) 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] ARGGHHH !
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. That said, I do agree that this is a problem. We probably need a standard coding style for FlightGear code, preferably one that is preinstalled in most programmers' editors. The question is whether we have anyone with cycles available to lead discussion on this and clean up the existing code base. Personally, I've looked, and I've not found any tools that actually do a reasonable job. If we do come up with a style guide it will probably piss off 100% of us. If this is a problem in the top 10, it's definitely not in the top 5. 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] ARGGHHH !
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 keeping. 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 code and nothing else. Critical information can always be kept in comments, but ifdef'ed or commented out code is very distracting. For here on out I hereby give anyone permission to hack out any dead, commented out, or useless code that I submit to the project. You don't need to ask. :-) On planning ahead: Back when I studied systems analysis 20 years ago, planning ahead was everything. Hardware price/performance, OO design, and networks have changed all that. These things are what make requirements so unpredictable these days (and systems so flexible). How many distribution software designs of the early nineties anticipated web based e-commerce? But now as the business world becomes increasing internetworked, requirement cycles measure in weeks and months, not years and decades. It is hard to break old habits though. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] ARGGHHH !
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++templates exceptions try blocks ect It only has a limited set of styles available though so you have to accept one of the more standard ones unless you want to write some code My self I find the default settings 'just work' for me BTW, Norman, are you having fun hitting all the religeous hot buttons here since your return? :-) In all honesty I hadn't thought of it that way but if these are truely 'religeous' hot buttons then they probably need to be brought up once in a while :-) Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] ARGGHHH !
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 looking at the right code :-) It would be nice if people making patches to a module adhered as best as possible to the style of the original author, so that the module as a unit remains readible. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ARGGHHH !
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 code and nothing else. Critical information can always be kept in comments, but ifdef'ed or commented out code is very distracting. For here on out I hereby give anyone permission to hack out any dead, commented out, or useless code that I submit to the project. You don't need to ask. :-) That works fine as long as the other person doesn't misidentify undead, unuseless code as being dead and useless. Not asking first can lead to hard feelings, and there's been too much of that going on around here lately. Where we can find ways to be nicer to each other, that is good. :-) On planning ahead: Back when I studied systems analysis 20 years ago, planning ahead was everything. Hardware price/performance, OO design, and networks have changed all that. These things are what make requirements so unpredictable these days (and systems so flexible). How many distribution software designs of the early nineties anticipated web based e-commerce? But now as the business world becomes increasing internetworked, requirement cycles measure in weeks and months, not years and decades. It is hard to break old habits though. This can be viewed at different levels. No we can't predict the future, and yes we need to be nimble and flexible and quick to adjust to the world changing around us, but some planning, some vision, some anticipation of the future is necessary to be succesful. Anyone who writes successful code is doing this at some level even if they say they aren't. :-) 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] ARGGHHH !
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 a reasonable job on c++templates exceptions try blocks ect It only has a limited set of styles available though so you have to accept one of the more standard ones unless you want to write some code My self I find the default settings 'just work' for me I admit I haven't tried this tool in a year or so, but when I did try it, they seemed much more focused on java formatting. And I wasn't even close to happy with it's treatment of C++. I'd love to see something with the flexibility of 'indent' available for C++, but that doesn't seem to be happening. BTW, Norman, are you having fun hitting all the religeous hot buttons here since your return? :-) In all honesty I hadn't thought of it that way but if these are truely 'religeous' hot buttons then they probably need to be brought up once in a while :-) Well, as long as it's done 'respectfully' and 'considerately' that's fine. But there's been way to much disrespect, snipping, and ill will going around this list lately. I know nothing is ever perfect. least of all human beings, but I think we could all make a concious effort to be nicer to each other and keep the tone of our messages positive... we really go no where when we are busy flaming each other and there has been really too much of that going on lately. 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] ARGGHHH !
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 code and nothing else. Critical information can always be kept in comments, but ifdef'ed or commented out code is very distracting. For here on out I hereby give anyone permission to hack out any dead, commented out, or useless code that I submit to the project. You don't need to ask. :-) We'll keep this on file. Same goes for me, by the way. Here's something that might help -- perhaps coders who want to keep old code around and visible could paste it into a separate file, like foobar.attic for foobar.cxx. That way, it would still be visible and easy to find. Personally, I think that's overkill, but it's an alternative for people who don't quite trust CVS to preserve their thoughts for posterity. On planning ahead: Back when I studied systems analysis 20 years ago, planning ahead was everything. Hardware price/performance, OO design, and networks have changed all that. These things are what make requirements so unpredictable these days (and systems so flexible). How many distribution software designs of the early nineties anticipated web based e-commerce? But now as the business world becomes increasing internetworked, requirement cycles measure in weeks and months, not years and decades. It is hard to break old habits though. On tech projects where I've been involved (ranging from $25K to over $50M), I figure we lost $10-$100 for every $1 we saved anticipating future needs. Jim's right -- people are just too stupid to guess the future (if you want a laugh, read the analysts' predictions on Yahoo! finance every morning before the markets open, and compare them with the market close after 4:15 EST -- it boggles my mind that they analysts be wrong *more* than 50% of the time). Planning ahead is OK, but C++ code and interfaces are not the place to do it. What you want is a short, 1-3 page roadmap document saying here's what we might do in the future and here's how we might do it. There's no point writing more than a few pages unless you want to give up any pretence of writing non-fiction. 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 people send patches, they can send updates to these files as well. I'll volunteer to start the README files myself, if no one objects. Don't expect more than ten words each. 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] ARGGHHH !
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 people send patches, they can send updates to these files as well. I'll volunteer to start the README files myself, if no one objects. Don't expect more than ten words each. 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. 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] ARGGHHH !
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 PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ARGGHHH !
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 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 let that go). It's nice to have a concept that can support all that stuff if/when we have an excuse to make use of it. Put the methods and stuff into the header file, with a comment that they are not implemented yet, and have the implementations break if used. That makes it easier to have backward compatible code when the snazzy features get added. Yes, except that I think we're paying a price with a couple of levels of unnecessary indirection and with code that no one but me can understand. I'd like to keep most of the user-level stuff intact, but ..educate us! Comments, and pointers where to learn more. This is also an educational project. ..and eventually, I will want to explain my changes to this-and-that code to airworthiness inspectors from FAA. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ARGGHHH !
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 derivatives
of Unix/Linux, and for other environments as well), you can eliminate the
viewing of the not-in-use code by typing M-x hide-ifdef-mode followed (if
necessary, depending on your configuration) by M-x hide-ifdefs. To show the
whole thing again, you can do M-x show-ifdefs
This will change code with ifdefs like this:
#include stdio.h
int main(int argc, char * argv[])
{
#ifdef xxx
/*
* Lots of code here
* which is only used
* in the rare case
* that 'xxx' is actually
* defined.
*/
#else
/*
* The real code is here
* and this is all we
* normally really want
* to see.
*/
#endif
}
into this:
#include stdio.h
int main(int argc, char * argv[])
{
#ifdef xxx ...
#else
/*
* The real code is here
* and this is all we
* normally really want
* to see.
*/
#endif
}
Yup, it actually runs a C preprocessor to determine what should be displayed,
so you get the proper stuff displayed. There are options available for
setting C preprocessor defines that would be specified at compile time, in
case not all of the defines are in header files.
Enjoy.
Derrell
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ARGGHHH !
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 style. The question is whether we have anyone with cycles available to lead discussion on this and clean up the existing code base. FWIW astyle does the entire src tree in less then a minute on my 'slow' machine so this should not be an issue http://astyle.sourceforge.net ..could everyone document their preferred code style, in a coding style sheet of some sort? ..if astyle can _safely_ and _reliably_ restyle code back and forth between an accepted standard and everyones weird tastes, we only need a standard conversion tool, and a coding style standard. ..my own preference is using the Linux kernel coding style, simply for future airworthiness certification etc purposes. This should allow easier inspection etc of code flying in in aircraft EAA*-style.(EAA* www.eaa.org) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ARGGHHH !
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: exceptions don't survive passage through a C function, and we use C-based callbacks both through GLUT and through Expat. We'll have to make sure that we catch exceptions in every callback function and do something with them, so that they don't just crash the program. 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] ARGGHHH !
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. Crashing, especially from de-referencing null pointers is usually associated with bad code. I'm aware of that. What folks don't seem to grok is that YASim is still very new. Of all the problems I've had inside the parser, only a minority of them have been due to syntax errors in the XML. The majority have been due to parser bugs, and the crash is *helpful* in these situations. Think of the *(int*)0=0 statement as a quirky form of an assertion. It works everywhere, on all platforms, and does the right thing. Much better and more portable than assert.h, frankly. The assert macro doesn't always halt the debugger or give you a core file. :) 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. I certainly wouldn't argue. Although I'm really no great fan of C++ exceptions. In Java, which does them right, you can be guaranteed that your exception will be caught -- exceptions are part of the type signature of a method. In C++, making exceptions work requires a *lot* of coordination between the catcher and all the possible throwers. If you want a piece of information in a programmatic way, you need to make sure that all the throwers throw the right type. In practice, it seems that all anyone ever throws are strings, which aren't very useful except as debug messages on the screen. 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. :) 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] ARGGHHH !
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. :) How about if (vfork()) [crash]; throw exception; ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ARGGHHH !
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/flightgear-devel
Re: [Flightgear-devel] ARGGHHH !
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 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 let that go). To rewind a bit, Andy rightly pointed out some of the problems with C++ exceptions, including the fact that they don't include stack traces and that people usually throw only strings. Granted, on both points, but exceptions still have the advantage that they can be caught at any arbitrary point up the stack and handled. For example, let's say that YASim fails to parse its XML config file. If it throws an exception, perhaps fg_init can catch that, display a warning dialog, and default to magic carpet mode. 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] ARGGHHH !
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 since it's inception See the commented code in fgCurrentElev() /* ssgState *IntersectedLeafState = ((ssgLeaf*)hit_list-get_entity(this_hit))-getState(); */ Note ssgState allows for arbritrary user data Have Fun :-) Norman _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] ARGGHHH !
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 skids (crash points aren't as serious). 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] ARGGHHH !
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 some configurations I can announce that I have a new Height above Ground algorithm that is MUCH faster read order of magnitude Note for the FDM writersThis means that queries for multiple 3 or 4 gear locations should be quicker then just the single query was before Excellent. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ARGGHHH !
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 of each bogey of interest, then get the height above ground? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ARGGHHH !
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 7 ~ 15 frames per second every frame extra is welcome :-) Good work Norman! Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ARGGHHH !
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 list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] ARGGHHH !
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 lat/lon/radius of each bogey of interest, then get the height above ground? Easier, well at least faster, then that The fgCurrentElev() routine takes sgdVec3 abs_view_pos as its first argument which normally is globals-get_current_view()-get_abs_view_pos() which I believe is still the AP CG so I believe that you could just add the offset for each query point to the abs_view_pos vector see tilemgr::update() for whee this is called currently HTH Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ARGGHHH !
* [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; // unexpected tag, boom ./src/FDM/YASim/FGFDM.cpp:*(int*)0=0; ./src/FDM/YASim/FGFDM.cpp:if(!atts-hasAttribute(attr)) *(int*)0=0; // boom ./src/FDM/YASim/FGFDM.cpp:if(!atts-hasAttribute(attr)) *(int*)0=0; // boom Hmm...I wonder who it could be. ;-) -- Cameron Moore / Do not meddle in the affairs of sysadmins, \ \ for they are subtle and quick to anger. / ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] ARGGHHH !
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 aren't as serious). So, when querying, would we supply the lat/lon/radius of each bogey of interest, then get the height above ground? Easier, well at least faster, then that The fgCurrentElev() routine takes sgdVec3 abs_view_pos as its first argument which normally is globals-get_current_view()-get_abs_view_pos() which I believe is still the AP CG so I believe that you could just add the offset for each query point to the abs_view_pos vector So then, we'd need to convert from our body coordinates to FG's global cartesian? see tilemgr::update() for whee this is called currently HTH Norman ___ 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] ARGGHHH !
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 supply the lat/lon/radius of each bogey of interest, then get the height above ground? Easier, well at least faster, then that The fgCurrentElev() routine takes sgdVec3 abs_view_pos as its first argument which normally is globals-get_current_view()-get_abs_view_pos() which I believe is still the AP CG so I believe that you could just add the offset for each query point to the abs_view_pos vector So then, we'd need to convert from our body coordinates to FG's global cartesian? I believe that the view-UP matrix will come in handy here Norman Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ARGGHHH !
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 complex
project like FlightGear where not everyone is familiar with
every line of code
This is the YASim XML parser. You hit this line when an unrecognized
tag is found in the XML file. Certainly, printing a nice error
message and exiting cleanly would be better, but you seem to
misunderstand the point. There is nothing useful the code can do at
this point; I actually like the fact that it crashes. If you feed
line noise to other parts of the code, you can get them to crash too.
This just does it in a more debuggable way.
If folks want to see a nice error message, then I'm happy to accept
patches. I'm less happy to be screamed at in public, of course.
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] ARGGHHH !
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 lat/lon/radius of each bogey of interest, then get the height above ground? Easier, well at least faster, then that The fgCurrentElev() routine takes sgdVec3 abs_view_pos as its first argument 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 and the normal at that location? This would better simulate things like crosswing landings and ski jumps. 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] ARGGHHH !
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 and the normal at that location? This would better simulate things like crosswing landings and ski jumps. I haven't looked closely, but I believe the code (at least at some level) is able to handle intersecting any arbitrary vector. Does that give you what you need? 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] ARGGHHH !
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, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] ARGGHHH !
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] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ARGGHHH !
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 more useful, IMHO. A truly robust error message implementation would do things like tell you where it was in the parsing (a missing control attribute? where?!) and what it was expecting to find. That requires more work, more state, and more code, and hasn't been done. This just fatally terminates in a prettier way. Maybe folks will believe me that this is why I haven't bothered to do any robust error detection yet; or maybe it's just because I'm arrogant and amateurish. :) It's difficult to test this at work (I can run the parser, but not fly the aircraft), so let me know if I broke something. 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] ARGGHHH !
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). So, when querying, would we supply the lat/lon/radius of each bogey of interest, then get the height above ground? Easier, well at least faster, then that The fgCurrentElev() routine takes sgdVec3 abs_view_pos as its first argument 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 and the normal at that location? This would better simulate things like crosswing landings and ski jumps. I'm not seeing what you're saying Andy. Why wouldn't a vector describing the location of the tire contact point be sufficient? 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 -- 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] ARGGHHH !
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 radius (or elevation ASL?) at a given lat/lon. We *do* know where our gear is! Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] ARGGHHH !
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 supply the lat/lon/radius of each bogey of interest, then get the height above ground? Easier, well at least faster, then that The fgCurrentElev() routine takes sgdVec3 abs_view_pos as its first argument 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 and the normal at that location? This would better simulate things like crosswing landings and ski jumps. 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 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ARGGHHH !
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 function that returns the terrain radius (or elevation ASL?) at a given lat/lon. We *do* know where our gear is! You know where the gear is, but you don't know how much it should be compressed until you know something about the ground elevation, but the amount of compression might change the lat/lon if the gear isn't aligned vertically at the moment. 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] ARGGHHH !
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 preexisting matrices to convert between your local xyz space and the global FGFS xyz space. Usually this will consist of nothing more then a translation and a rotation. Otherwise you end up taking the sin/cos atan etc of the same angles repetitively on both sides of the 'Module divide'. I believe the necessary Matrices are all exposed by the global-view pointer so your Interface routine can grab whatever it needs Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ARGGHHH !
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 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. 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 enough to significnatly change the resulting ground elevation? If we run the gear code fast enough this will approach reality anyway ... as in the gear extension amount from the last frame allows us to calculate the accurate lat/lon of the contact point for the next frame. And the ground elevation then feeds back into the gear extension amount which can be fed forward to the next frame. Assuming the changes are small from one frame to the next this should work ok ... and as you increase the rate of your gear integration, this will become increasingly valid. 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] ARGGHHH !
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 compress, and thus are geometrically line segments. The FDM knows that the gear tip can be anywhere between one point (full extension) and another (full compression), but needs to know where so it can calculate the spring force along the strut. The scenery manager is the only code that knows what the ground looks like, so it has to figure this out. So, what I'd like to see is an interface that looks like: // Calculates and returns a point of scenery intersection that lies on // the line segment between p1 and p2. If the line segment intersects // the scenery more than once, then the point closest to p1 is chosen. // All coordinates are in global cartesian. sgdVec3 fgGetSceneryIntersection(sgdVec3 p1, sgdVec3 p2, sgdVec3* normalOut); ... or something equivalent. Actually, there needs to be a way to disambiguate the case where p1 is actually below ground, too. 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] ARGGHHH !
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 spring gear also follow a less than straight path.) The FDM knows that the gear tip can be anywhere between one point (full extension) and another (full compression), but needs to know where so it can calculate the spring force along the strut. The scenery manager is the only code that knows what the ground looks like, so it has to figure this out. So, what I'd like to see is an interface that looks like: // Calculates and returns a point of scenery intersection that lies on // the line segment between p1 and p2. If the line segment intersects // the scenery more than once, then the point closest to p1 is chosen. // All coordinates are in global cartesian. sgdVec3 fgGetSceneryIntersection(sgdVec3 p1, sgdVec3 p2, sgdVec3* normalOut); ... or something equivalent. 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 ... 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] ARGGHHH !
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 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. Ski jumps are an immediate counter example. But again, it's not that the compression vector is significantly non-vertical, it's that the amount of compression is very sensitive to the direction of this vector. The point to doing per-gear collision detection is to account for non-flatness of the ground plane. That gets defeated if you treat the gear compression configuration as a flat space normal to the earth. :) Really, we have a perfectly acceptable gear model for many situations right now. We're already getting complicated by considering per-gear collisionn. If we're going to do it, I'd rather we do it right. 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] ARGGHHH !
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? Exactly. The gear will hit where we expect it to, but due to any non-level orientation, the compression and rate of compression will be different. We might be able to trigonometrically modify the forces applied at the contact point based on the orientation at touchdown, but the location that the force is applied won't really be affected much. And the landing gear max stroke is not terribly large in relative terms. There are probably other inaccuracies that are much more important to deal with. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] ARGGHHH !
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 enough to significnatly change the resulting ground elevation? 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 1/100 and yes I do know about Catalina and I guess we could try to model running over 'curbs and 'potholes' ' but FWIW the hitlist maintains a pointer to the triangle that is hit for those who really want to get into micro modelling this kind of thing Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ARGGHHH !
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 1/100 Once more: ski jumps. I can assure you, without a shadow of doubt, that the deck of the Illustrious is nowhere near as flat as the runways you built in the army. :) 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 angle for a stiff crosswind landing) can results in a translation of sin(20) (about 34%) of the gear length. The difference in spring force between a gear compressed by 34% and one that isn't compressed is very large. And again, it is true that under almost all circumstances we could just assume that gear compressed down regardless of aircraft orientation and get away with it. But we already make an even better assumption -- that the ground will be a flat plane. If you think about it, the assumptions are basically the same. All the circumstances where we'd get away with down-only gear compression are already handled just as well (or better*) by our existing flat runway assumption. Like I said, if we're going to do it, we should do it right. Andy * 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 make any physical sense. -- 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] ARGGHHH !
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-nominal! http://www.f15sim.com - The only one of its kind. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ARGGHHH !
* 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 make any physical sense. No, but it certainly would be amusing to watch. :) g. -- I'm not crazy, I'm plausibly off-nominal! http://www.f15sim.com - The only one of its kind. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ARGGHHH !
* [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 contact point. Perhaps the differences won't be significant enough to significnatly change the resulting ground elevation? 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 1/100 and yes I do know about Catalina and I guess we could try to model running over 'curbs and 'potholes' ' but I've been lurking and half-way following this conversation, but one thing to keep in mind is that we are not just dealing with tires and runways. Bush pilots routinely land in fields that are sometimes no more than a bumpy, dirt path, and float-plane pilots don't always have a smooth runway. Floats and skis will also penetrate the scenery upon touchdown. Okay...back to lurking... Sort of OT: What was the name of that supersonic navy sea jet developed back in the 50's/60's? I hear it was a rough ride. :-) -- Cameron Moore / Why is it, A penny for your thoughts, but, you have \ \ to put your two cents in? Somebody's making a penny. / ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ARGGHHH !
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 want to do a complicated gear model with fidelity solely for this case. I think you misunderstand. The FDM's gear model is simpler in this case. You give the scenery the position of the gear min/max comprssion points, and it tells you where the tip really is. There's less work to do in the gear model, not more. 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. There's no point to doing the per-gear stuff if we're not going to see any benefit. Among the problems we run into with any proposed right approach, is that the aircraft may straddle polygons and the movement from one polygon to the next may result in discontinuous jumps with the surface normal. I think there needs to be some smoothing there. No need; that's what the integration algorithm is for. Even if the underlying implementation was smooth (a spline, say), you're only sampling it at discreet points anyway. You couldn't tell the difference, so long as the difference across two samples was small. For the specific case of a ski jump: the speed of an aircraft when it hits the jump is about 30 m/s. At a 120 Hz integration rate, that's a per-sample change of 25cm, so our geometry needs to be 25cm long. A ski jump is about 10m long, and is axially symmetric, so that comes out by my reconning to 40 quads (or 80 triangles) for the deck. Not bad at all; and the non-deck parts can of course be done at much lower resolution. 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] ARGGHHH !
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 angle for a stiff crosswind landing) can results in a translation of sin(20) (about 34%) of the gear length. The difference in spring force between a gear compressed by 34% and one that isn't compressed is very large. 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 compression). We're talking about just a few percent even at twenty degrees. The backward _movement_ of the contact point for a gear that compresses 3 and the aircraft at a twenty degree pitch would be one inch - a small inaccuracy. Where are you getting your figures? Jon Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ARGGHHH !
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 accurately model a ski jump, anyhow?] I'm not sure I want to do a complicated gear model with fidelity solely for this case. I think you misunderstand. The FDM's gear model is simpler in this case. You give the scenery the position of the gear min/max comprssion points, and it tells you where the tip really is. There's less work to do in the gear model, not more. 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 compresses. I'll certainly agree that right now it's not necessary to model anything more than compression along a straight line, but we know that's not real in alot of cases and should allow for it in the design of the FG-FDM interface. 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. There's no point to doing the per-gear stuff if we're not going to see any benefit. A significant benefit will be had immediately -- the aircraft will follow the terrain while taxiing and the 3D model will look better. Among the problems we run into with any proposed right approach, is that the aircraft may straddle polygons and the movement from one polygon to the next may result in discontinuous jumps with the surface normal. I think there needs to be some smoothing there. No need; that's what the integration algorithm is for. Even if the underlying implementation was smooth (a spline, say), you're only sampling it at discreet points anyway. You couldn't tell the difference, so long as the difference across two samples was small. For the specific case of a ski jump: the speed of an aircraft when it hits the jump is about 30 m/s. At a 120 Hz integration rate, that's a per-sample change of 25cm, so our geometry needs to be 25cm long. A ski jump is about 10m long, and is axially symmetric, so that comes out by my reconning to 40 quads (or 80 triangles) for the deck. Not bad at all; and the non-deck parts can of course be done at much lower resolution. 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 -- 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] ARGGHHH !
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 PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ARGGHHH !
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 compression). ^ What part of assuming a flat ground is not getting across? :) If you are willing to assume a flat ground, then you already *have* a valid and workable model that requires no modifications whatsoever. Don't bother with the per-gear stuff, you neither need it nor want it. If, like me with my ski jump fancy, you want to be able to deal with ground that isn't flat, then that assumption goes out the window and you can *not* assume pure Z compression. If you don't, don't. But don't do it half way, it won't do anyone any good. If you don't believe me, try this: what specific circumstance would be helped by your hybrid per-gear force computation, and what would the quantitative difference be? 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] ARGGHHH !
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 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] ARGGHHH !
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 that requires no modifications whatsoever. Don't bother with the per-gear stuff, you neither need it nor want it. It's been mentioned here several times in this thread already. If the runway is not perfectly level, the aircraft will be tilted (in real life). 1) If we model the gear given a per-gear elevation, we get a lot of effects for free - including slanted runways. The 3D model with then rest on it correctly. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ARGGHHH !
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 is the tip of a gear strut at 20 degrees of AoA (or bank, or whatever)? ...is 34% of its length. Draw it out, if it is not clear. For small angles, that distance goes as the sine of the angle. The sine of 20 degrees is 0.34. QED. You answered that this didn't matter, since only the Z component was important. I immediately plonked you for assuming that the ground was flat (or, strictly, that the ground and aircraft's wing/body planes were parallel). The point of doing separate gear intersection testing is to get proper results when the ground is *not* flat. We *already* get proper results with flat ground. You can't fix the flat ground assumption by making the flat ground assumption. Again: if we're going to do it, we should do it right and not wrong. We already have good enough. If we need better, we can only go to perfect. It's been mentioned here several times in this thread already. If the runway is not perfectly level, the aircraft will be tilted (in real life). 1) If we model the gear given a per-gear elevation, we get a lot of effects for free - including slanted runways. The 3D model with then rest on it correctly. Ah, here's an actual feature. But the solution is wrong. If you want a tilted aircraft, then use the normal vector for the ground plane (take a look at the YASim code for this if you want). You don't need to do per-gear stuff for this. And in fact you don't want to, because of the stair-stepping effect I mentioned earlier. You can do better with a single plane. 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] ARGGHHH !
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 compresses. I'll certainly agree that right now it's not necessary to model anything more than compression along a straight line, but we know that's not real in alot of cases and should allow for it in the design of the FG-FDM interface. I don't necessarily disagree, but I'm at a loss for how you get this effect by assuming that gear compression is always along a line normal to the ground plane? If anything, this would argue for an interface more like mine, where the FDM can probe the scenery for intersection points rather than blindly trust an elevation number for each gear and assume a flat ground plane under the gear. A significant benefit will be had immediately -- the aircraft will follow the terrain while taxiing and the 3D model will look better. If you mean the aircraft will be tilted on non-level ground, then you can get that effect already by inspecting the normal vector. When I say flat, I don't mean level. Take a look at the YASim code (which supports, but does not use, a terrain normal vector) for an example. 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. 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] ARGGHHH !
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 should know the path that the wheel follows as it compresses. I'll certainly agree that right now it's not necessary to model anything more than compression along a straight line, but we know that's not real in alot of cases and should allow for it in the design of the FG-FDM interface. I don't necessarily disagree, But by asking the scenery code to do the intersection for you, that's exaclty what you are doing, AFAICT. but I'm at a loss for how you get this effect by assuming that gear compression is always along a line normal to the ground plane? I wouldn't make this argument, I'd say it's reasonable to assume *body* axis z compression only (though you shouldn't lock yourself into that, there are many examples where that's not the case, the F-18 and Cessna 172 being two), a very different thing. If anything, this would argue for an interface more like mine, where the FDM can probe the scenery for intersection points rather than blindly trust an elevation number for each gear and assume a flat ground plane under the gear. Why would this entail the assumption of a flat plane? We ask for the compression under (or, conversely, the agl altitude) of each contact point and whatever it is, it is. Whether the ground has a simple slope or undulates within the area formed by the gear contact points, it doesn't matter. Even a nicely non-linear curve like a ski-jump is not a problem. All we care about is the agl height of each wheel (and in particular whether its negative or not), not what may be happening in between. A significant benefit will be had immediately -- the aircraft will follow the terrain while taxiing and the 3D model will look better. If you mean the aircraft will be tilted on non-level ground, then you can get that effect already by inspecting the normal vector. When I say flat, I don't mean level. Take a look at the YASim code (which supports, but does not use, a terrain normal vector) for an example. Sure, but we can get that and a ski-jump capability knowing the agl altitude of each wheel. 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. 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 -- 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] ARGGHHH !
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, AFAICT. Well, to be fair, this is a hard problem. If we allow for the scenery to be an arbitrary 3D mesh, *and* allow the gear to compress along funny non-linear trajectories, we have a lot of complexity to deal with. We either have to have scenery code that understands funny gear trajectories or gear code that understands 3D collision detection. My suggestion works fine for the simple linear-compression situation that works for most aircraft, and allows for an iterative, probing metaphor in situations where it doesn't. That is, break the compression trajectory into small pieces and test each one of those for intersections. Note that the pieces don't have to be any smaller than the integration sampling wavelength, or about 0.1m or so, so this is actually quite feasible. This gets you a perfect gear simulation down to the level of integration granulatity, which is good for all purposes. but I'm at a loss for how you get this effect by assuming that gear compression is always along a line normal to the ground plane? I wouldn't make this argument, I'd say it's reasonable to assume *body* axis z compression only (though you shouldn't lock yourself into that, there are many examples where that's not the case, the F-18 and Cessna 172 being two), a very different thing. Bingo, here is the disconnect. The current terrain intersection code gives you an altitude above the ground plane for each gear. That allows only for compression along the ground's up axis, not the body's. You could hack in a hybrid, but only by assuming flat ground in the area under the gear. This assumption breaks under the same circumstances that the flat ground assumption does, and thus doing things this way just doesn't buy you much. I completely agree, by the way, that assuming the body frame compression is always along the Z axis makes sense. In fact, while YASim in principle supports any gear compression axis, I only bothered supporting Z axis compression in the parser. 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 change and we're done. 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] ARGGHHH !
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 change and we're done. The way I see it the Hitlist Interface is Public and the current elevation code makes a good example of how to use it albeit in a fairly simple manner If another module wants to use the hitlist mechanism todo different things then just declare your own hitlist object and have at it. I believe all the hooks are there to do anything anyone might reasonably expect to be able to do with a line surface intersector FWIW I'll gladly help people who actually try it on there own and need help but for my purposes the scenery elevation is all I need so I don't have the itch todo anything fancier especially since all of this functionality has been in place for well over a year now and as yet is unused. regards Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ARGGHHH !
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. Draw it out, if it is not clear. For small angles, that distance goes as the sine of the angle. The sine of 20 degrees is 0.34. QED. Andy can draw. Andy can do trig. Andy can write QED. Either you are missing my point, or I am missing yours. This 34% has no bearing on anything - at least given the way JSBSim models gear/ground interactions. I am absolutely clueless on what you are trying to get across. It appears to be totally irrelevant. The point of doing separate gear intersection testing is to get proper results when the ground is *not* flat. We *already* get proper results with flat ground. For Pete's sake, I *know* this, and I am *not* assuming the ground is flat. I've been trying to get across to you that we *can* assume that: 1) *FOR THE PURPOSES OF CALCULATING FORCES* and MOMENTS given our simulated world that the strut *compresses* along a vertical axis only. 2) For the purposes of calculating correct aircraft *orientation* (repeat O R I E N T A T I O N ... look it up at m-w.com) we can assume that the strut compresses vertically. 3) If we have the ground elevation (E L E V A T I O N) at each gear point, then we can correctly orient (O R I E N T) the aircraft on the ground on NON-FLAT runways - EVEN if we span polygons. We've discussed this and investigated it ad nauseum long before you even became involved in this project. You can't fix the flat ground assumption by making the flat ground assumption. Again: if we're going to do it, we should do it right and not wrong. We already have good enough. If we need better, we can only go to perfect. You're not making any sense. You're completely missing the point. 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? Ah, here's an actual feature. But the solution is wrong. If you want a tilted aircraft, then use the normal vector for the ground plane (take a look at the YASim code for this if you want). You don't need to do per-gear stuff for this. And in fact you don't want to, because of the stair-stepping effect I mentioned earlier. You can do better with a single plane. Andy, this doesn't work. You cannot simply have a single surface normal and calculate the delta height and angle at any point because the aircraft may span more than one polygon. We went over this long, long ago. At that time we wanted to do a per-gear elevation, but we decided it was too computationally expensive (IIRC). If we can do this now, as Norman mentioned, it's an attractive way to go. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ARGGHHH !
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 what is done, currently, which is nothing. And at reasonable runway slopes and tilts, it will be just fine. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ARGGHHH !
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 to know is what is the darned elevation at a given lat/lon, and eventually perhaps the roughness, the bouyancy, and the surface normal. I wouldn't make this argument, I'd say it's reasonable to assume *body* axis z compression only (though you shouldn't lock yourself into that, there are many examples where that's not the case, the F-18 and Cessna 172 being two), a very different thing. Bingo, here is the disconnect. The current terrain intersection code gives you an altitude above the ground plane for each gear. That allows only for compression along the ground's up axis, not the body's. This is, in fact, what the JSBSim gear code uses. We do compression only along the vertical axis (the ground Z axis). As I keep repeating to you - even at an angle of up to 20 degrees, the *compression* error maxes out at several percent (less than 7). The runway exerts a force on the aircraft in the RUNWAY vertical direction (in real life, of course, this would be more accurately a runway _normal_ direction). It would be no big deal to compress the gear along its own body axis (for a non-articulated single strut), but we have more pressing things we are working on than doing ski jumps with airplanes at present. Providing the elevation at a single lat/lon gives _us_ a nice feature. If you don't want to use it, you don't have to. I completely agree, by the way, that assuming the body frame compression is always along the Z axis makes sense. In fact, while YASim in principle supports any gear compression axis, I only bothered supporting Z axis compression in the parser. 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 change and we're done. Maybe you need to re-state what you are thinking is right. Something's not getting communicated. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ARGGHHH !
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 out of ways to explain this; and in all seriousness, I mean no disrespect here. But that statement is simply false. The elevation at the gear does not unambiguously define a contact point for the gear. It just doesn't. It works only if you make one of two assumptions: (1) the gear compression vector is along the ground's up vector, or (2) the ground is locally flat. Here's another ASCII diagram (please don't mock this one) to try to explain: + .\ . \ --gear strut . \ elev . (0) ation-. + . / . / ground ./ / Here, the elevation says that the gear is clear of the ground. But that is wrong! The gear strut points forward, and the gear should, in fact, be sitting nicely on the edge as shown. Note that you can come up with an equivalent diagram if you find the elevation of the point of maximum compression, or the midpont, or any point. If the gear doesn't compress vertically, then *no* use of elevation (other than an infinite number of them to probe all possibilities) is going to get you what you want. My way, which computes an intersection between the gear base and the maximum extension point below the ground, works fine here. It is the correct algorithm for this problem. And it's no more difficult. I'm having a very hard time understanding the resistance here. Either you are missing my point, or I am missing yours. Both, it seems. Let's try this: You want to handle (1) aircraft on non-level-but-flat ground so that they tilt and (2) non-flat areas where two polygons with different normals meet. [You agree with me this far, right? Have I misrepresented?] OK, now my point: In order to handle case #2, you are willing to make the assumption that gear compression is always along the up vector from the ground and simply use the elevation at that point. [Are we still on the same page? Do you not see why this must be?] So, your proposed solution can handle the case where the ground is non-level, but flat, or the case where the ground is non-flat, but level, but it fails in the case where the ground is both non-flat and non-level. I argue that the only interesting non-flat or non-level cases happen together. This is true for ski jumps. It is true at catalina. It is true at the edge of a cliff. I further argue that it requires no more work on the part of the FDM or the scenery code to do this the Right Way: by computing an intersection point along the gear's axis of compression. I even posted a putative interface for such code, which you and Tony, for no reason that I can for the life of me figure out, hate with a passion. :) Try turning it around. Rather than justify why your way is Good Enough, tell me why my way (which, I think we all agree, is technically more correct) is harder? Or more expensive? Or uglier? Or... what? Stated as simply as I can possibly say it: The simplifications that you want to make are (1) unnecessary and (2) incorrect. There are better ways of doing ground intersection code. 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] ARGGHHH !
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. + .\ . \ --gear strut . \ elev . (0) ation-. + . / . / ground ./ / Here, the elevation says that the gear is clear of the ground. 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 DIRECTLY BELOW THE TIRE CONTACT POINT. JSBSim can provide a lat/lon for that point. But that is wrong! The gear strut points forward, and the gear should, in fact, be sitting nicely on the edge as shown. Which we would track properly, given that the elevation below the *tire* is reported. My way, which computes an intersection between the gear base and the maximum extension point below the ground, works fine here. It is the correct algorithm for this problem. How typically arrogant. It's not your approach, it's your attitude. You are perfectly welcome and free to do things in whatever way you desire - I'm not stopping you at all. I am just considering taking Norman up on his suggestion that a per-wheel elevation can be given. Your algorithm is correct for what you want to do. There are tradeoffs and approximations that can be made anywhere in the sim. You may pay more attention to areas here and there than we do, or do things different here and there than we do. That makes your approach different, or more precise, or more approximated, or whatever. Given all the factors to consider in simulation, it doesn't make it uniquely and alone _the_ correct solution. It's called simulation after all. Either you are missing my point, or I am missing yours. Both, it seems. Let's try this: You want to handle (1) aircraft on non-level-but-flat ground so that they tilt and (2) non-flat areas where two polygons with different normals meet. [You agree with me this far, right? Have I misrepresented?] OK, now my point: In order to handle case #2, you are willing to make the assumption that gear compression is always along the up vector from the ground and simply use the elevation at that point. [Are we still on the same page? Do you not see why this must be?] So, your proposed solution can handle the case where the ground is non-level, but flat, or the case where the ground is non-flat, but level, but it fails in the case where the ground is both non-flat and non-level. Disagree. I am assuming by flat you mean that the polygon and any adjacent polygons have parallel normals and that level means a vertical normal. ? As long as any polygon that the tire sits on has a reasonable surface normal (i.e. say within ten degrees of vertical) then we'll do fine. Anything else is likely a crash, anyhow. I argue that the only interesting non-flat or non-level cases happen together. This is true for ski jumps. It is true at catalina. It is true at the edge of a cliff. We could handle either. I further argue that it requires no more work on the part of the FDM or the scenery code to do this the Right Way: by computing an intersection point along the gear's axis of compression. I even posted a putative interface for such code, which you and Tony, for no reason that I can for the life of me figure out, hate with a passion. :) I can't remember rejecting your interface. But go ahead and do things your own way - like I said I have no objection to you doing whatever you want to do. That's not my place. Try turning it around. Rather than justify why your way is Good Enough, tell me why my way (which, I think we all agree, is technically more correct) is harder? Or more expensive? Or uglier? Or... what? I still haven't seen a good overall description of exactly what it is that you are proposing. Can you give me a reference to the message? Stated as simply as I can possibly say it: The simplifications that you want to make are (1) unnecessary and (2) incorrect. There are better ways of doing ground intersection code. Again, how arrogant. It's been done like this for a long time. That doesn't make it correct. But it works. It's not incorrect. Your way may be more precise, and handle various odd special cases that at the moment we don't really care about, and that's fine. I'll hand you that. But, you've got to get over this attitude and learn to make a distinction between precision, approximation, and correctness. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ARGGHHH !
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 intersection for you, that's exaclty what you are doing, AFAICT. Well, to be fair, this is a hard problem. If we allow for the scenery to be an arbitrary 3D mesh, *and* allow the gear to compress along funny non-linear trajectories, we have a lot of complexity to deal with. We either have to have scenery code that understands funny gear trajectories or gear code that understands 3D collision detection. Either there's something I'm really missing or you're making the problem way harder than it is. My suggestion works fine for the simple linear-compression situation that works for most aircraft, and allows for an iterative, probing metaphor in situations where it doesn't. That is, break the compression trajectory into small pieces and test each one of those for intersections. Note that the pieces don't have to be any smaller than the integration sampling wavelength, or about 0.1m or so, so this is actually quite feasible. This gets you a perfect gear simulation down to the level of integration granulatity, which is good for all purposes. but I'm at a loss for how you get this effect by assuming that gear compression is always along a line normal to the ground plane? I wouldn't make this argument, I'd say it's reasonable to assume *body* axis z compression only (though you shouldn't lock yourself into that, there are many examples where that's not the case, the F-18 and Cessna 172 being two), a very different thing. Bingo, here is the disconnect. The current terrain intersection code gives you an altitude above the ground plane for each gear. That allows only for compression along the ground's up axis, not the body's. You could hack in a hybrid, but only by assuming flat ground in the area under the gear. Why? Why does the area matter? We're talking points here. If we know the distance below ground of the contact point then we can call that the runway normal, transform it to body coords, and call the z component of that the oleo compression. This assumption breaks under the same circumstances that the flat ground assumption does, and thus doing things this way just doesn't buy you much. I completely agree, by the way, that assuming the body frame compression is always along the Z axis makes sense. In fact, while YASim in principle supports any gear compression axis, I only bothered supporting Z axis compression in the parser. I guess I'm just a little flummoxed at the resistance to doing things right here. I don't see that that's the right way, and what you're proposing would require us to expose information that I think we shouldn't. 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 change and we're done. 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 -- 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] ARGGHHH !
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 DIRECTLY BELOW THE TIRE CONTACT POINT. JSBSim can provide a lat/lon for that 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 collision detection algorithm. All the input knows is the base point and the point beneath the ground: + -- gear min extension point .\ . \ . \ elev . (\) -- computed contact point ation-. ++--- . / \ . /+ -- gear max extension point ./ / Really, I'm sorry if this seems arrogant. I'm trying to be nice. But, well, despite how much you think you're right here, ... you're not. This algorithm you propose is incorrect. It's not terribly incorrect, since it works great for lots of situations. But the discussion at hand was how to improve the gear handling. If we're going to improve it, isn't it worth considering all the available solutions and picking the best one? I still haven't seen a good overall description of exactly what it is that you are proposing. Can you give me a reference to the message? OK, it's my turn to make a (mild) snipe. You've been arguing with me on this point all day, through many message, and have finally ended up calling me arrogant. But you haven't read through the original suggestion that started it all??? Jeez, Jon, if you had questions, why didn't you ask them BEFORE dropping your bombs? OK, having blown off that steam, the suggestion was simply this: // Calculates and returns a point of scenery intersection that lies on // the line segment between p1 and p2. If the line segment intersects // the scenery more than once, then the point closest to p1 is chosen. // All coordinates are in global cartesian. sgdVec3 fgGetSceneryIntersection(sgdVec3 p1, sgdVec3 p2, sgdVec3* normalOut); If you want to use this interface to do vertical-only compression, then there is nothing stopping you. But an interface that does *only* vertical-only compression does not work right for the intersection calculations I want to do for things like ski jumps, etc... My way, which computes an intersection between the gear base and the maximum extension point below the ground, works fine here. It is the correct algorithm for this problem. How typically arrogant. It's not your approach, it's your attitude Jon, cut me some slack here. How else would I have written that paragraph? I mean, I stand by the statement: it is the correct algorithm for this problem. Am I arrogant just because I think you are wrong? Can I call you pig-headed because you don't think I'm right? (If it's not obvious, please insert LOADS of smileys in the above sentence). Look at it from my side: there is a cool new feature that *almost* does what I want it to do. But it can't do what I want unless I get an interface change. But I can't get that interface change unless the other FDM authors agree to use it too. So I advocated my solution. Part and parcel of advocating one solution over another is (1) explaining why my way is good and (2) explaining why the alternative is bad. So I called your mechanism bad. Is that an attitude problem or a debate? Where is the line? How might I have made the same technical points in a way that doesn't seem so arrogant? 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] ARGGHHH !
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 collision detection algorithm. All the input knows is the base point and the point beneath the ground: Your analysis is correct. This is a limitation of our model, because our approach uses an approximation that the contact point is near enough vertical that we can just use that. This approximation may not be good enough for your desires, however, and that's fine. Really, I'm sorry if this seems arrogant. I'm trying to be nice. But, well, despite how much you think you're right here, ... you're not. This algorithm you propose is incorrect. It's not terribly incorrect, since it works great for lots of situations. You're stuck in the terminology dept., still? :-) Look in the mirror and say approximation. Go ahead, you can do it. You physicists ... always splitting hairs - er, I mean atoms. I didn't say we were right. We have an approximation, it works for what we want it to do. We are simulating. There are other aspects of flight simulation that we can spend our time on that will render much more capability, and I'd venture a guess that the same is true for YASim. It's a matter of priorities - particularly given our schedules. ANd if we can add the ability to rest on a tilted runway with little effort, so be it. We'll do that when we get a chance and that filters down the queue. Someday, perhaps we'll refine it even more. I am concerned about the shouts of disgruntled users, however - don't get me wrong. I know we have some work to do. If you want to use this interface to do vertical-only compression, then there is nothing stopping you. But an interface that does *only* vertical-only compression does not work right for the intersection calculations I want to do for things like ski jumps, etc... If one does not care about ski jumps, then will it really be noticable the difference between our current approaches? Will the overall experience be such that someone will exclaim how realistic the approach is given 99% of the runways that exist? LIke I said, it's a matter of priorities. Our current approximation is pretty good for what almost everyone will see. Look at it from my side: there is a cool new feature that *almost* does what I want it to do. But it can't do what I want unless I get an interface change. But I can't get that interface change unless the other FDM authors agree to use it too. I don't think this is true. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
