Re: [Flightgear-devel] Licensing issues
Curtis L. Olson wrote: I know this is probably opening a can of worms, but I just thought I'd throw this out to the list now so people could start thinking about and/or discussing the issues. Currently SimGear is a set of libraries, each of which is licensed under the *L*GPL. FlightGear is also mostly a set of libraries (with some top level wrapper code) that is entirely GPL'd. What I would like to propose for people's consideration, is the idea of taking each of FlightGear's component libraries and converting them to the LGPL license. The top level wrapper code (i.e. whatever is in src/Main) would remain GPL. Well, to be honnest. I've been thinking of restricting some of my contributions even more (configuration files, textures, etc) so it can be used for non commercial purposes only. That said, I'm a big fan of the Free Software Foundation, but some contributions took so much time, that I don't wanted to see them end up in commercial software (e.g. the F-16 config file end up in FLy! ot MSFS ...) For code, I think GPL is good enoug and when looking back at it, changing SimGear to LGPL was done without consulting anyone else also (If I had contributed code for Simgear at that time I probably would have complained). For me it's all an issue of other people running away with (and making mony out of) my contributions to LightGear, while I am jobless for some time now. This doesn't sound appealing to me. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Licensing issues
Curtis L. Olson wrote: James A. Treacy writes: You should get as close to 100% of the contributors to agree as you can get. Flightgear needs to be prepared to remove any code written by someone who disagrees or who couldn't be contacted and appears later on. FWIW, wine did this earlier this year and they got all but a handful of contributors to sign off on the change. The missing had made only small contributions that they could easily recode if the need arose. Question: for a particular source file, if a person contributed a minor patch or tweak to compile on a new platform, does that person now have a full say in the future of that source, or are they giving their changes to the author of that file to be placed under the license terms chosen by the primary author. My sense is that if it is only minor changes that were contributed by others, the primary author should be able to maintain complete ownership over the copyright and license terms of that code. Yep. That's my opinnion also. FWIW, this issue arrises when we consider moving code from FlightGear into SimGear. SimGear code is LGPL'd and FlightGear code is GPL'd so a license change would be required. Hoever, if we attacked this piece by piece, subsystem by subsytem, it would likely be doable. What's your reason for wanting to change the license anyway? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Free At Last
Cameron Moore writes: I figured David would have said something by now, but Blender was open-sourced a couple days ago. This is great news for the open-source community (ie. us). Go check it out: http://www.blender.org/ I downloaded the source code, but I'm not going to try to build it until someone adds autoconf support. Feel free to write some tutorials for us modelling newbies. There are many good Blender tutorials on the net (I started with the castle one, then moved on to the pencil). For FlightGear, you have to stick to meshes (no nurbs) and work hard to keep the poly count low -- no extruded 64-sided mesh circles, for example. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Licensing issues
Alex Perry writes: See the article in Linux Journal recently. You legally cannot place anything into the public domain, you merely get to assert that the licensing you are assigning to your copyrighted work behaves as though it is in the public domain. There is a subtle distinction, which essentially means that, since you do still have the copyright, people who retrieve the code also have the right to sue you. After all, the public domain license does not limit warranties etc. They have the right to sue anyway, no matter how many disclaimers you put in the license. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Licensing issues
David Megginson wrote: Erik Hofman writes: Well, to be honnest. I've been thinking of restricting some of my contributions even more (configuration files, textures, etc) so it can be used for non commercial purposes only. Unfortunately, that would force their removal from FlightGear, which (given the high quality of your textures) would be a shame. I haven't, I still supose the base package falls under the GPL. But I like to keep it GPL and nothing less restrictive. Also not that none of my code contributions have an explicit copyright in the header, which means they fall under the same license terms of FlightGear (GPL now, and maybe LGPL later). Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Licensing issues
I should point out that my earlier message in this thread was to recommend that Curt not pursue the relicensing because the benefits are probably too small to outweigh both the non-trivial effort for the developers and the fairly large risk of causing FGFS to fork. However, that is independent of how I license my contributions. Erik said: Also not that none of my code contributions have an explicit copyright I think I've said this before. If I submit a patch against someone else's file, the patch is intended to inherit the copyright and any current or future licensing of the containing file or code fragment. When I create a file, or submit a large patch to a file without an identified copyright owner, the intent is to retain the copyright in my name and apply _only_ the then-current GPL license version. To save confusion, don't bother asking me to me-copyrighted files under the GPL with any version and automatic upgrade to future versions. There are no restrictions on how the FSF organisation can rewrite the intent and content of future versions of the GPL. Those future versions could, for example, grant a $0.01/sourceline royalty to RMS for any commercial use of GPL'ed software. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] TC ball
On Tue, 2002-10-15 at 20:12, Curtis L. Olson wrote: FWIW, the turn coordinator ball behaves *very* differently between JSBSim and YASim and another FDM I am playing with. All supposedly return accelerations in body axis in ft/sec squared. IMO, what we should all be aiming at providing are accels very similar to what three body-axis aligned acclerometers mounted at the pilot eyepoint would give. The FDMs should provide to the TC only that which an airplane would provide, the raw forces or accels. This means we can't create a single turn coordinator instrument who's ball behaves reasonably well for every FDM. Well, I tried to compare the two, but got this for the yasim c172: YASim solution results: Iterations: 404 Drag Coefficient: 18.9992 Lift Ratio: 87.1639 Cruise AoA: -0.124142 Tail Incidence: 0.440443 Approach Elevator: -1.00013 CG: -2.3, -0.0, 0.2 YASim SOLUTION FAILURE: Insufficient elevator to trim for approach [exit] I just used fgfs --aircraft=c172-yasim, is anything else needed? Would it be better to force the FDM's to calculate a ball deflection in degrees/radians, or do we need to investigate why the body axis accelerations are so radically different for 3 different FDM's (who all are trying to model a C172.) No and yes. If the FDM's do the work, then they all have to do the failure modeling too. It would be nicer to figure out what's going on ... it seems to be more than a simple coordinate system difference, unless JSBSim/YASim swap X/Y axes or something strange like that. Regards, 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 -- 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] Licensing issues
James A. Treacy wrote: On Tue, Oct 15, 2002 at 11:15:08PM -0500, Curtis L. Olson wrote: Question: for a particular source file, if a person contributed a minor patch or tweak to compile on a new platform, does that person now have a full say in the future of that source, or are they giving their changes to the author of that file to be placed under the license terms chosen by the primary author. Exactly the way I want to think of it. The law, though, seems to have its own bizarre sense of logic. I belive that contributions are seen as being individual items(*), like pieces of lego. You only have the copyright on your 'pieces of lego'. Thus, if the primary author of some code wants to release future versions under a different license and a contributor disagrees, then the primary author would need to back out the contributed code. Obviously, as code evolves it becomes less clear who contributed what. That's also my point of view. If you want to change the licence you must ask every contributor. If one doesn't answer or one rejects the change (you'll have to assume the worst) you must roll these commits back before you change the license. There's no other way to do it. Code that has grown over the time is thus quite impossible to convert to a new license with out implementing it in a clean room. As this sounds like *very* much work to me and all of us have no spare time (if they'd had they'd be improoving FGFS...) I can't see the FGFS changing the license in the near future. If a company needs a differnt licence they could do it if they have the resources... (have a look at the Wine project as a reference) To make this kind of stuff easier in the future we could try to ask every contributor to give the copyright to someone. E.g. to Curt or The FlightGear project (whatever that means - probably only legal if there's an official organisation like the KDE league; Mantis does that) Appart from this legal stuff I really dislike 2 different licenses in the FGFS pakage (or SimGear, or ...). All the files should have the same license. That was IIRC one the reasons for seperating SimGear. I also can's see any benefit for changing FGFS itself to LGPL. So I grant permission to move any code that I produced (mostly, but not only, patches and bug fixes) to SimGear and change the License for that purpose only to the LGPL. Code that remains in FGFS itself has to stay under GPL. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] TC ball
I'd tend to pay some attention to McFarland's document, but haven't had a chance to review it with this in mind. Might get to that today. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Tony Peden Sent: Wednesday, October 16, 2002 8:28 AM To: FGFS Devel Subject: Re: [Flightgear-devel] TC ball On Tue, 2002-10-15 at 20:12, Curtis L. Olson wrote: FWIW, the turn coordinator ball behaves *very* differently between JSBSim and YASim and another FDM I am playing with. All supposedly return accelerations in body axis in ft/sec squared. IMO, what we should all be aiming at providing are accels very similar to what three body-axis aligned acclerometers mounted at the pilot eyepoint would give. The FDMs should provide to the TC only that which an airplane would provide, the raw forces or accels. This means we can't create a single turn coordinator instrument who's ball behaves reasonably well for every FDM. Well, I tried to compare the two, but got this for the yasim c172: YASim solution results: Iterations: 404 Drag Coefficient: 18.9992 Lift Ratio: 87.1639 Cruise AoA: -0.124142 Tail Incidence: 0.440443 Approach Elevator: -1.00013 CG: -2.3, -0.0, 0.2 YASim SOLUTION FAILURE: Insufficient elevator to trim for approach [exit] I just used fgfs --aircraft=c172-yasim, is anything else needed? Would it be better to force the FDM's to calculate a ball deflection in degrees/radians, or do we need to investigate why the body axis accelerations are so radically different for 3 different FDM's (who all are trying to model a C172.) No and yes. If the FDM's do the work, then they all have to do the failure modeling too. It would be nicer to figure out what's going on ... it seems to be more than a simple coordinate system difference, unless JSBSim/YASim swap X/Y axes or something strange like that. Regards, 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 -- 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 smime.p7s Description: application/pkcs7-signature
Re: [Flightgear-devel] Licensing issues
David Megginson wrote: My understanding of the *gpl is keep the copyright as a legal instrument to enforce the donation in court against those who try to deny the public its donated good, which _makes_ it legally enforceable. I don't see pd as being enforceable. Not quite -- the GPL is designed to force people to make their modifications or improvements publicly available, something that does not concern me so much. The GPL doesn't force the modifications to be given back to the community. It only forces that the source code for the distribution of the software (modified or unmodified doesn't matter) must be aviable for reasonalbe costs. So if my company gets an GPLed software and modifies it and uses it only internally no code has to come back to the community (although it'd be playing nice). If the company sells (or gives it away for free) this modified software it doesn't need to give the modified source code away with it. BUT: The customer can copy this software for free and give it to everybody else for free (as long as it states that this software is still GPLed). And the customer can ask the company for the source code. The company has to give the source to the customer then... Something that is in the Public Domain remains in the Public Domain; otherwise, publishers would be able to restrict Jane Austen's novels or Shakespeare's plays (rather than just the publisher's editorial contributions). They can - sort of. The layout etc. in their books is copyrighted work. But you are free to type it from the books and give it away for free - as long as you aren't also typing additional stuff like translations from the old english to the new english words. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Initial Airspeed
It seems that the recent changes related to the airspeed instrumentation have affected the --vc option. If I start with --vc=100, JSBSim gets passed 92.885 knots. Including instrumentation error is fine, but I have a hard time believing 7 knots of error (relative to calibrated) at cruise angles of attack and small sideslip angles. I'd also advocate adding a --ias option for this and continue to allow --vc to set calibrated airspeed. It is for that reason that I chose to use --vc instead of --ias when I added that a while back. -- 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] Licensing issues
Alex Perry wrote: I should point out that my earlier message in this thread was to recommend that Curt not pursue the relicensing because the benefits are probably too small to outweigh both the non-trivial effort for the developers and the fairly large risk of causing FGFS to fork. exactly I think I've said this before. If I submit a patch against someone else's file, the patch is intended to inherit the copyright and any current or future licensing of the containing file or code fragment. I disagree partly. If I submit a patch it'll be under the same licence of the file that it had at the creation of the patch (unless otherwise stated). If anyone (including the author who has written everthing exept a few minor patches) wants to change the licence every author of that file (i.e. the original author and any additonal authors, also those that only fixed a speeling mistake in a sting that never gets printed) must agree - or their work has to be redone in a clean room environment. When I create a file, or submit a large patch to a file without an identified copyright owner, the intent is to retain the copyright in my name and apply _only_ the then-current GPL license version. Who decides if my patch is minor or a large rewrite? Also I haven't heard the phrase except minor modifications in the Copyright law... So it's a everybody agrees or no action can be done. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] TC ball
AFAICT, the behavior with JSBSim is reasonable. This is what I see at 93 kias, power for level flight, a left turn makes the ball go left and needs left rudder to recenter. Opposite for right turn. Same behavior (with similar magnitudes) observed at around 70 kias. At both speeds I did observe asymmetrical behavior, the ball tended to the left a small amount (but still within the vertical lines) in constant heading flight and may have been more sensitive to left turns than right. A power off descent at 70 knots tended to make it symmetric, so I suspect that the propwash effects are causing the aircraft trim at a small slip angle. On Wed, 2002-10-16 at 07:00, Jon Berndt wrote: I'd tend to pay some attention to McFarland's document, but haven't had a chance to review it with this in mind. Might get to that today. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Tony Peden Sent: Wednesday, October 16, 2002 8:28 AM To: FGFS Devel Subject: Re: [Flightgear-devel] TC ball On Tue, 2002-10-15 at 20:12, Curtis L. Olson wrote: FWIW, the turn coordinator ball behaves *very* differently between JSBSim and YASim and another FDM I am playing with. All supposedly return accelerations in body axis in ft/sec squared. IMO, what we should all be aiming at providing are accels very similar to what three body-axis aligned acclerometers mounted at the pilot eyepoint would give. The FDMs should provide to the TC only that which an airplane would provide, the raw forces or accels. This means we can't create a single turn coordinator instrument who's ball behaves reasonably well for every FDM. Well, I tried to compare the two, but got this for the yasim c172: YASim solution results: Iterations: 404 Drag Coefficient: 18.9992 Lift Ratio: 87.1639 Cruise AoA: -0.124142 Tail Incidence: 0.440443 Approach Elevator: -1.00013 CG: -2.3, -0.0, 0.2 YASim SOLUTION FAILURE: Insufficient elevator to trim for approach [exit] I just used fgfs --aircraft=c172-yasim, is anything else needed? Would it be better to force the FDM's to calculate a ball deflection in degrees/radians, or do we need to investigate why the body axis accelerations are so radically different for 3 different FDM's (who all are trying to model a C172.) No and yes. If the FDM's do the work, then they all have to do the failure modeling too. It would be nicer to figure out what's going on ... it seems to be more than a simple coordinate system difference, unless JSBSim/YASim swap X/Y axes or something strange like that. Regards, 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 -- 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 -- 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] TC ball
On Wed, 2002-10-16 at 07:27, Curtis L. Olson wrote: Tony Peden writes: AFAICT, the behavior with JSBSim is reasonable. This is what I see at 93 kias, power for level flight, a left turn makes the ball go left and needs left rudder to recenter. Opposite for right turn. Same behavior (with similar magnitudes) observed at around 70 kias. At both speeds I did observe asymmetrical behavior, the ball tended to the left a small amount (but still within the vertical lines) in constant heading flight and may have been more sensitive to left turns than right. A power off descent at 70 knots tended to make it symmetric, so I suspect that the propwash effects are causing the aircraft trim at a small slip angle. Tony, I apologize, I should have been more clear in my original message. The JSBSim drives the ball in a reasonable way, as does this other FDM I'm playing with. However, the scaling is about an order of magnitude different between the two, even though they supposedly report the accels in the same units and are modeling the same aircraft. YASim seems to drive the ball yet another order of magnitude further. It's not so much the behavior, but the range of motion and scaling. I found it strange since supposedly all three are reporting body axis accels in ft/sec^2 and it's the same code used in all three cases to compute ball motion based on these accels. Well, keep in mind that the accels driving the TC are calculated largely from the aero and propulsion models, so differences of degree between different models should not be surprising. Also, the FDM you are using probably has better aero data driving the lateral-directional dynamics (I'd guess it's based on Cessna flight test data). The lateral-directional terms in the JSBSim c172 are based largely on Roskam's estimates and pilot feedback, not actual data, so it doesn't surprise me that they don't agree. Regards, 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 -- 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] Licensing issues
On Wed, Oct 16, 2002 at 03:51:17PM +0200, Christian Mayer wrote: If you want to change the licence you must ask every contributor. If one doesn't answer or one rejects the change (you'll have to assume the worst) you must roll these commits back before you change the license. There's no other way to do it. Code that has grown over the time is thus quite impossible to convert to a new license with out implementing it in a clean room. As this sounds like *very* much work to me and all of us have no spare time (if they'd had they'd be improoving FGFS...) I can't see the FGFS changing the license in the near future. If a company needs a differnt licence they could do it if they have the resources... (have a look at the Wine project as a reference) IMO, changing licenses is one of those areas which end up being easier in practice than expected - if people see a good reason to change the license. If the reasons to change the license aren't strong enough you are much more likely to encounter resistance (and as has been discussed resistance would make changing the license very difficult). To date, I don't believe the reasons to change the license are strong enough to overcome any resistance. -- James (Jay) Treacy [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] TC ball
On 16 Oct 2002 07:58:22 -0700 Tony Peden [EMAIL PROTECTED] wrote: On Wed, 2002-10-16 at 07:27, Curtis L. Olson wrote: Tony, I apologize, I should have been more clear in my original message. The JSBSim drives the ball in a reasonable way, as does this other FDM I'm playing with. However, the scaling is about an order of magnitude different between the two, even though they supposedly report the accels in the same units and are modeling the same aircraft. YASim seems to drive the ball yet another order of magnitude further. It's not so much the behavior, but the range of motion and scaling. Well, keep in mind that the accels driving the TC are calculated largely from the aero and propulsion models, so differences of degree between different models should not be surprising. Also, the FDM you are using probably has better aero data driving the lateral-directional dynamics (I'd guess it's based on Cessna flight test data). The lateral-directional terms in the JSBSim c172 are based largely on Roskam's estimates and pilot feedback, not actual data, so it doesn't surprise me that they don't agree. There is no way there should be an order of magnitude difference because of this. Off the top pf my head I'd suggest we all ought to be within 10% of each other as far as acceleration at the pilot eyepoint is concerned. If Curt's external FDM says there is a 0.2g side accel at the pilot eyepoint, there is no way we should be saying it is 1g or greater. Need to look at McFarland, and see if he has something we can use to get a sanity check on our stuff. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] standardizing on units
Ok, I know this will probably open another can of worms, but I believe we need to standardize some of our units. I'm half way through changing all the FlightGear code to follow the new standard and will try to get my changes committed shortly. For those of you writing new code or contributing to existing code, here is the new standard for FlightGear units to be used throughout our project: 1 millionth of a mouthwash = 1 microscope Time between slipping on a peel and hitting the pavement = 1 bananosecond Weight an evangelist carries with God = 1 Billigram Ratio of an igloo's circumference to its diameter = Eskimo Pi 2000 pounds of Chinese soup = Won ton Time it takes to sail 220 yards at 1 nautical mile per hour = Knot-furlong 365.25 days of drinking low-cal beer because it's less filling = 1 lite year 16.5 feet in the Twilight Zone = 1 Rod Serling Half of a large intestine = 1 semicolon 1000 pains = 1 kiloahurtz Basic unit of laryngitis = 1 hoarsepower Shortest distance between two jokes = A straight line 454 graham crackers = 1 pound cake 1 million microphones = 1 phone [10^6 X 10^ -6 = 1] 1 trillion microphones = 1 megaphone 1 million bicycles = 2 megacycles 2000 mockingbirds = Two kilomockingbirds 10 cards = 1 decacards 1 kilogram of falling figs = 1 Fig Newton 2 kilograms of falling figs = 1 set of Fig Newton twins [for the Hattiesburg crowd] 1000 milliliters of wet socks = 1 literhosen Washed away by the Crimson Tide while generating 1 Joule/second = Tippicanoe and Tyler Watts 10 rations = 1 decoration 100 rations = 1 C-ration 8 nickels = 2 paradigms 2.4 statute miles of intravenous surgical tubing at Yale Hospital = 1 I.V. League I'm sure you will all come to appreciate the long term benefits of our use of standard units as time goes on. Thanks you, 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] standardizing on units
On Wed, 16 Oct 2002 10:09:59 -0500 Curtis L. Olson [EMAIL PROTECTED] wrote: What is the unit that represents the time between when the NFL started and when the Minnesota Vikings will win the Super Bowl? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] standardizing on units
Jon S Berndt writes: On Wed, 16 Oct 2002 10:09:59 -0500 Curtis L. Olson [EMAIL PROTECTED] wrote: What is the unit that represents the time between when the NFL started and when the Minnesota Vikings will win the Super Bowl? I think that would be: time-to-hell-freezing-over^2 chance-of-me-winning-the-lottery 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] standardizing on units
On Wed, Oct 16, 2002 at 10:20:19AM -0500, Jon S Berndt wrote: On Wed, 16 Oct 2002 10:09:59 -0500 Curtis L. Olson [EMAIL PROTECTED] wrote: What is the unit that represents the time between when the NFL started and when the Minnesota Vikings will win the Super Bowl? infinity. ___ 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] TC ball
Curtis L. Olson wrote: it seems to be more than a simple coordinate system difference, unless JSBSim/YASim swap X/Y axes or something strange like that. Could be a bug, too. What exactly is the behavior you're seeing? The way the code in steam works is to look at the Y and Z pilot acceleration vectors and compute a down direction. Is it the direction that's wrong? * Not the same as coordinate acceleration, for the reasons discussed before. And it shouldn't use X, which is the longitudinal axis. The ball is constrained by its housing to the YZ plane. The steam.cxx code is the only place that uses these numbers, so a bug could easily have gone unnoticed. I haven't looked at the ball in a while, honestly, but I don't remember being surprised by anything looking wrong. 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] Licensing issues
Curtis L. Olson wrote: Question: for a particular source file, if a person contributed a minor patch or tweak to compile on a new platform, does that person now have a full say in the future of that source, or are they giving their changes to the author of that file to be placed under the license terms chosen by the primary author. It goes by change, not by file. They contributed a patch under an existing license, not a new one. So you can't legally change their license without removing the patch; nothing gives you the right to their work. In practice, what this means is that you need to get most of the developers on board. If someone doesn't agree, you need to be prepared to remove their code and reimplement it. You don't necessarily need to remove every 2-line patch submitted on the assumption that the author doesn't agree. It's enough to announce the license change in the appropriate forum for FlightGear development (here, of course) and expect that people interested will notice and tell you about problems. IANAL, of course. But this is the way it's worked in other projects (Wine, especially) that have gone through license changes. But under no circumstances can you relicense someone else's code over their objections. If someone makes a stink, you have to snip it out. 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] Licensing issues
Alex Perry wrote: There is a subtle distinction, which essentially means that, since you do still have the copyright, people who retrieve the code also have the right to sue you. It's even more subtle: the right to sue you doesn't go with the copyright. The copyright is a right that *you* have to restrict distribution. The right to sue for damages is someone else's, and is inherent (with lots of legislative exceptions). Basically, regardless of what you do with your copyright: if you wrote the code, it's your fault. This is why the GPL has its warranty clause, and why commercial licenses always have the limitation of liability clause. 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] Free At Last
This is great news, especially in that it could present a model for similar releases in the future. Some great software has been lost over the years to failed companies being bought out and disposed of by competitors for relatively tiny sums of money. I'm not convinced that the blender interface (as it is now) would be helpful to bringing in large numbers of modelers. But it'd be great to have a loader in plib, which I assume could be more easily accomplished now? Or would it make more sense or be possible to add the import/export to blender? This really is exciting, as those who have been doing some modeling know, weakness in the modeling tools is holding us back a bit in the eye candy department. Best, Jim Cameron Moore [EMAIL PROTECTED] said: I figured David would have said something by now, but Blender was open-sourced a couple days ago. This is great news for the open-source community (ie. us). Go check it out: http://www.blender.org/ Feel free to write some tutorials for us modelling newbies. ;-) Thanks -- Cameron Moore [ My grandfather died when he was just an infant. ] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Jim Wilson - IT Manager Kelco Industries PO Box 160 58 Main Street Milbridge, ME 04658 207-546-7989 - FAX 207-546-2791 http://www.kelcomaine.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] TC ball
Andy Ross writes: Curtis L. Olson wrote: it seems to be more than a simple coordinate system difference, unless JSBSim/YASim swap X/Y axes or something strange like that. Could be a bug, too. What exactly is the behavior you're seeing? The way the code in steam works is to look at the Y and Z pilot acceleration vectors and compute a down direction. Is it the direction that's wrong? * Not the same as coordinate acceleration, for the reasons discussed before. And it shouldn't use X, which is the longitudinal axis. The ball is constrained by its housing to the YZ plane. The steam.cxx code is the only place that uses these numbers, so a bug could easily have gone unnoticed. I haven't looked at the ball in a while, honestly, but I don't remember being surprised by anything looking wrong. I haven't looked at YAsim closely, but FlightGear and this other fdm I'm working on both use nearly the same formula to calculate the ball position. The steam code uses A_Y_pilot / -A_Z_pilot to calculate turn coordinator ball position. This other fdm code bases it's calculation on forces, but also in the Y and Z directions. I'm guessing that Ay / Az is roughly proportional to Fy / Fz so these two methods won't be exactly the same, but should be similar enough. However, I'm not using the TC ball output, but instead passing this FDM's Ay and Az to the steam code so it get's processed the same as JSBsim. The results from both are good and apparently correct, but off by an order of magnitude in scaling. I guess I'll have to try to find some time to dump out the values and see if I can figure out what's going on. Perhaps someplace in one of the pipelines, a units conversion was screwed up (maybe meters vs. ft or something?) Regards, 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] TC ball
Tony Peden wrote: Well, I tried to compare the two, but got this for the yasim c172: YASim SOLUTION FAILURE: Are you sure you have current code and base package? I haven't looked at the 172 in a good while, and not much has changed. Do the other YASim aircraft work for you? 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] Some little bugs report from an enthusiast new user...
Andy Ross [EMAIL PROTECTED] said: Jim Wilson wrote: The problem with the 2D panel mapped to the cockpit had been there since Andy added that capability...but now I don't see it anymore. I'm sure it was there fairly recently, within the last month anyway. Are you seeing it with current code David? It's related to depth buffer precision. On my Geforce cards (2MX and 3), it never happens with the 24 bit depth buffer you get by default at 32bpp. At 16bpp, it picks a slimmer depth buffer (probably 16 bit) and the texture layers bleed through. That explains why it went away on my system :-) The code is using a pretty big argument to glPolygonOffset, and I've never investigated how small it can be. If someone has a little time the next time they see this issue, try changing the value of POFF_UNITS at the top of Cockpit/panel.cxx. Decrease it until the textures *just* start to interfere with each other, and post the value that works for you. Will take a look at that when I get a minute. Thanks, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Licensing issues
Erik Hofman writes: I haven't, I still supose the base package falls under the GPL. But I like to keep it GPL and nothing less restrictive. Also not that none of my code contributions have an explicit copyright in the header, which means they fall under the same license terms of FlightGear (GPL now, and maybe LGPL later). Perhaps the licensing status of the base package should be our first concern. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] TC ball
Curtis L. Olson wrote: The JSBSim drives the ball in a reasonable way, as does this other FDM I'm playing with. However, the scaling is about an order of magnitude different between the two, even though they supposedly report the accels in the same units and are modeling the same aircraft. YASim seems to drive the ball yet another order of magnitude further. Hrm... yup, that sounds awfully wrong. Especially since units shouldn't matter. What the steam.cxx code is doing is taking the sideways acceleration and dividing it by the vertical acceleration to get a down direction. The units should drop out. I could be reporting accelerations in mph per year and it should still work. Could you stick some printfs in and get a feel for the numbers that are coming out? I mean, just print Ay and Az for each sim under broadly similar conditions and see if anything is obviously wrong. Unless you're doing aerobatics, Z should be very close to 32 and Y should be near zero. If this is happening in the air, it might not be the acceleration code at all, but the side-force-per-slip-angle behavior that is different. Try testing while doing constant rate turns on the ground to see if they behave the same there. 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] Initial Airspeed
Tony Peden writes:
It seems that the recent changes related to the airspeed instrumentation
have affected the --vc option. If I start with --vc=100, JSBSim gets
passed 92.885 knots. Including instrumentation error is fine, but I
have a hard time believing 7 knots of error (relative to calibrated) at
cruise angles of attack and small sideslip angles.
Here's an excerpt from options.cxx:
} else if ( arg.find( --vc= ) == 0) {
fgSetString(/sim/startup/speed-set, knots);
fgSetDouble(/velocities/airspeed-kt, atof(arg.substr(5)));
And here's one from flight.cxx:
if ( speedset == knots || speedset == KNOTS ) {
set_V_calibrated_kts( fgGetDouble(/velocities/airspeed-kt) );
Nothing should be interfering with this value from point A to point B.
The new instrumentation code puts indicated values under the
/instrumentation/ property subtree and explicitly does not touch
values under /velocities/ etc. Ditto for the older steam support.
All the best,
David
--
David Megginson, [EMAIL PROTECTED], http://www.megginson.com/
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Wright flyer
Jim, Your Wright flyer model is really starting to look sharp! Good work. :-) People need to check this out if they haven't already: fgfs --aircraft=wrightFlyer1903-v1-nl-uiuc You definitely need to stay on your toes (so to speak) to keep this thing in the air. The lack of lateral stability is very apparent. If you get banked a little too much, you'll slide right out of the sky. The UIUC folks did a very good job on the flight dynamics. My gut feeling is that this is probably very close in terms of performance to the original. 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] FSAA frustration continues (Nvidia forum post)
Curtis L. Olson [EMAIL PROTECTED] said: Geoff Reidy writes: The major problem I have with fgfs is that I seem to hit a race condition where all graphics and sound stop for extended periods of time (up to about 30 secs), long enough for autopilot (or me!) to lose control and the plane will always crash. During this time there is no disk access happening or lack of memory, fgfs still uses 99% CPU. Doesn't make any difference whether I use the Mesa files or not. Tried compiling with/without random-objects and threading. Tried running with textures disabled, 16 or 24 bit. It happens after covering a certain amount of terrain. It doesn't matter if I'm flying the A4 or a Cessna I will go down about 1000km north of Sydney, give or take a couple of hundred. Over other parts of the world I usually get further but it always gets me in the end. The program itself never crashes. It's been happening since before version 8.0 came out but noone else seems to have the problem? I had put it down to some gcc3.2 weirdness but others are using it now. I can sometimes precipitate it by switching to tower view, will get a white screen, elevation goes to 4 ft or so, sound stops, oh-oh. This most likely relates to freeing tile memory (i.e. moving old tiles out of the cache and reclaiming their memory.) This was never a fast process and could result in frame rate glitches. When David added random ground cover objects, the problem got *really* bad because the scene graph structure of a tile got a lot larger. David and I worked really hard to optimize that, and I further worked on a partial tile free-er so we could spread the load out over multiple frames. This should have been all fixed by version 0.8.0 so that you should see very little frame rate impact when you cross a tile boundary. What version of flightgear are you running? This discription sounds like a problem that I think I've seen, but haven't tracked down. It seemed as though the tile cache is getting clogged up with unusable entries (this was 2 or 3 months ago btw). IIRC I traced this through to plib to make sure everything was being deleted, but still couldn't verify this was happening. Of course with time, all the tiles for the tower view will be released, and they will require reloading, if tower view is not used. Normally the tiles under the FDM location will be kept current by the code that queries for ground elevation (see end of Main Loop) when the FDM location is not the current view (as in tower view). I don't have time to look right now, but I assume that the code still updates the timestamp for tiles whenever the tilemgr.update() is run as it was a couple months ago. In any case if the capacity of the tile cache is dimminished somehow, maybe with the timestamps getting screwed up, or all the tiles including the one under the FDM location end up with the same timestamp (or the timestamp isn't kept current--so it gets old--by the tilemgr update as mentioned in the previous paragraph), then the tile under the FDM location may get removed when switching to tower view by the reloading that is going on. This would explain the whacky elevation figure. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] TC ball
Andy Ross writes: Hrm... yup, that sounds awfully wrong. Especially since units shouldn't matter. What the steam.cxx code is doing is taking the sideways acceleration and dividing it by the vertical acceleration to get a down direction. The units should drop out. I could be reporting accelerations in mph per year and it should still work. In the past we've had trouble with accelerations because of different references. I have no physics background and a bad memory, so I'll use baby talk: basically, you have to consider whether the accelerations you're reporting include or exclude the earth's rotation (or something similar). Andy, Tony, or Jon can translate that into proper terminology (probably inertial reference frame or something similar) and comment on whether it has anything to do with the problem. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Wright flyer
Curtis L. Olson writes: Your Wright flyer model is really starting to look sharp! Good work. :-) It looks great -- this is the first time I've tried it. With the mouse, at least, it's also quite easy to fly -- I had to work hard to make it overrotate. Jim: you need to make sure that the propellers are drawn last so that they don't obscure the airplane in external view. If you name all of the objects (so that you can tell which is which), you can rearrange them in the *.ac file using an ordinary text editor. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Wright flyer
At 10/16/02, Curtis L. Olson wrote: Jim, Your Wright flyer model is really starting to look sharp! Good work. :-) People need to check this out if they haven't already: fgfs --aircraft=wrightFlyer1903-v1-nl-uiuc The 1903 Wright Flyer has rudder coupled to wing warping. For this to work out right use: fgfs --aircraft=wrightFlyer1903-v1-nl-uiuc --enable-auto-coordination Then be sure to not input any rudder w/ the stick (i.e. don't twist the joystick). With later aircraft, the Wright Brothers de-coupled the wing warping from the rudder ... for good reason as can be deduced from flying the model. My confidence level in terms of the accuracy of the model (sans the engine) is pretty high. It's largely based on NASA Ames data from tests on a replica, which I mention in the readme: ~/fgfsbase/Aircraft/UIUC/wrightFlyer1903-v1-nl/README.wrightFlyer1903.html Sounds like I need to cvs-checkout out the latest stuff! Regards, Michael You definitely need to stay on your toes (so to speak) to keep this thing in the air. The lack of lateral stability is very apparent. If you get banked a little too much, you'll slide right out of the sky. The UIUC folks did a very good job on the flight dynamics. My gut feeling is that this is probably very close in terms of performance to the original. 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 ** Prof. Michael S. Selig Dept. of Aero/Astro Engineering University of Illinois at Urbana-Champaign 306 Talbot Laboratory 104 South Wright Street Urbana, IL 61801-2935 (217) 244-5757 (o), (509) 691-1373 (fax) mailto:[EMAIL PROTECTED] http://www.uiuc.edu/ph/www/m-selig http://www.uiuc.edu/ph/www/m-selig/faq.html (FAQ) ** ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Wright flyer
At 10/16/02, David Megginson wrote: Curtis L. Olson writes: Your Wright flyer model is really starting to look sharp! Good work. :-) It looks great -- this is the first time I've tried it. With the mouse, at least, it's also quite easy to fly -- I had to work hard to make it overrotate. From the wind tunnel test data, up elevator (canard nose up) does not very quickly lead to a big stall. But if you get the nose moving up, the instability will in 1-2 sec lead to canard stall. That the canard power is pretty weak (i.e. not very effective) is consistent w/ the first flight: http://www.libraries.wright.edu/special/ Note the large amount of canard input. Regards, Michael Jim: you need to make sure that the propellers are drawn last so that they don't obscure the airplane in external view. If you name all of the objects (so that you can tell which is which), you can rearrange them in the *.ac file using an ordinary text editor. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ** Prof. Michael S. Selig Dept. of Aero/Astro Engineering University of Illinois at Urbana-Champaign 306 Talbot Laboratory 104 South Wright Street Urbana, IL 61801-2935 (217) 244-5757 (o), (509) 691-1373 (fax) mailto:[EMAIL PROTECTED] http://www.uiuc.edu/ph/www/m-selig http://www.uiuc.edu/ph/www/m-selig/faq.html (FAQ) ** ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Licensing issues
Curtis L. Olson [EMAIL PROTECTED] said: James A. Treacy writes: You should get as close to 100% of the contributors to agree as you can get. Flightgear needs to be prepared to remove any code written by someone who disagrees or who couldn't be contacted and appears later on. FWIW, wine did this earlier this year and they got all but a handful of contributors to sign off on the change. The missing had made only small contributions that they could easily recode if the need arose. Question: for a particular source file, if a person contributed a minor patch or tweak to compile on a new platform, does that person now have a full say in the future of that source, or are they giving their changes to the author of that file to be placed under the license terms chosen by the primary author. My sense is that if it is only minor changes that were contributed by others, the primary author should be able to maintain complete ownership over the copyright and license terms of that code. If someone else (in addition to the main author of a particular chunk of code) contributed new code, or a major rewrite, or something else significant, then we start getting into gray areas. It seems like the primary author of that code probably still could have final say, but basic courtesy might dictate that the major contributors at least be consulted ... (?) This could be a concern for a legal department in a company considering using code down the road. It seems unlikely that anyone with a trivial contribution would sue the project if they were not given full say. Ethically I would say yes, since the conditions under which the contribution took place were clearly stated by GPL. Ethics are extremely important in the open source community, and should I think be considered before legal liability. Whether or not someone could or would take legal action or would spend the money to defend against legal action should not be the primary concern. If that all was the case, then it still might be nearly impossible to relicense the entire project given the total number of contributors, but it might be possible to relicense a smaller sub-section of the code where the number of identifiable contributors is smaller and within reason (as long as the resulting license remained compatible with the rest of the code of course.) At least two or three of the authors of the 3D models that I solicited for the project would not want their work released under LGPL (I understand this isn't necessarily what you had in mind). FWIW, this issue arrises when we consider moving code from FlightGear into SimGear. SimGear code is LGPL'd and FlightGear code is GPL'd so a license change would be required. Hoever, if we attacked this piece by piece, subsystem by subsytem, it would likely be doable. And of course, the FlightSim specific stuff would make the most sense to leave inside FlightGear, but other things like the scenery subsystem, FDM interface (?), sound manager, time tracking, model animation, properties, joystick support, etc. might make sense to migrate over to SimGear as time goes by ... This would be the best approach I think, so long as authors are consulted. Generally I feel the same as David about the code I've created. But, fundamentally I think that David's concern about the pretentiousness in the GPL or LGPL is unwarranted. It isn't about whether or not someone would actually afford to defend their rights faced with abuses by a large company. GPL and LGPL are as much social contracts as they are legal contracts. They have recognizable meaning that could be disrupted, if too many projects sought less restrictive licensing without good reason. That said, the age of this project and the large number of contributors makes it difficult to do this conversion right, except by carefully moving work over to SimGear as Curt suggests, consulting authors along the way. My apologies if this response is out of sync, but i'm only about half way through the thread and need to get back to work work. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] TC ball
On Wed, 2002-10-16 at 10:22, Andy Ross wrote: Tony Peden wrote: Well, I tried to compare the two, but got this for the yasim c172: YASim SOLUTION FAILURE: Are you sure you have current code and base package? I haven't looked at the 172 in a good while, and not much has changed. Do the other YASim aircraft work for you? The a4 seems to work. FG, SG, and base were updated this morning. Possibly interesting (and unrelated) data point: I just ran FG on my box but displayed on my wife's. It has a GeForce 4mx ( a GeForce 2, as I understand it) and was getting ~30 fps. Maybe I just had low expectations, but that seems pretty good to me. 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] TC ball
On Wed, 2002-10-16 at 11:05, David Megginson wrote: Andy Ross writes: Hrm... yup, that sounds awfully wrong. Especially since units shouldn't matter. What the steam.cxx code is doing is taking the sideways acceleration and dividing it by the vertical acceleration to get a down direction. The units should drop out. I could be reporting accelerations in mph per year and it should still work. In the past we've had trouble with accelerations because of different references. I have no physics background and a bad memory, so I'll use baby talk: basically, you have to consider whether the accelerations you're reporting include or exclude the earth's rotation (or something similar). Andy, Tony, or Jon can translate that into proper terminology (probably inertial reference frame or something similar) and comment on whether it has anything to do with the problem. Well, Yasim and JSBSim do the bulk of their work in different sets of reference frames, but by specifying that these accels are in body axes, we are specifying the reference frame and so should end up with the same thing. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- 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
[Flightgear-devel] Elite Simulator
I had my first experience with the Elite simulator today (I missed the version -- sorry) at a Precision Controls station. Here are some observations. To my understanding, Elite is the most commonly-used FTD at flight schools in Canada and the U.S., so I'll post some initial observations, on the understanding that they might not apply to the most recent versions. 1. The physical controls have a nice solid feel, especially the rudder pedals, compared to my flimsy USB controls. It's nice having actual knobs to turn for the radios. Unfortunately, the electronic trim button tended to get stuck, so I had to recover five or six times from runway trim. 2. The graphics are very simplistic, but that's no big deal since it's meant mainly as an IFR simulator. The panel is pretty similar to our 2D panel, though slightly more complete. 3. The C172R flight model left a bit to be desired: in a 20deg turn, the nose dropped about 5-10 degrees and needed a *lot* of elevator to maintain altitude. They should hire Tony to help them improve it. 4. The update rate for the gauges is horrendous -- maybe 2-4Hz at best. It was very hard to fly IFR at first with the jumpy needles, until I learned to anticipate the indications. Similarily, the controls seemed to work in fairly large steps rather than smooth gradiants. 5. The instrument lags and errors are no better than ours. For example, a real VOR needle doesn't center instantly when you spin to a new radial, but Elite's (like FlightGear's) did; the Elite mag compass was not nearly as impressively confusing as Alex's in FlightGear. In summary, then, I don't see much preventing FlightGear from becoming a certified IFR FTD other than the trivial problems of time, money, and political influence, once we finish wiring in the electrical system. We'd need to work a bit on an instructor console, making it easy (for example) to place the plane 5.5 miles out on a specified radial from a navaid, but that's no big deal. By the way, thanks to FlightGear, I didn't go through the usual newbie initiation of spiraling out of control in the first simulated vacuum failure -- my instructor was impressed that I diagnosed every failure relatively quickly. I spent most of the time practicing holding patterns. I'm still trying to decide whether to love or hate them: I'll write a tutorial for sim users some day if anyone is interested. I understand that ATC almost never uses holds any more, but I have been in them twice as an airliner passenger: once over East Anglia inbound to Heathrow from Helsinki (because of congestion), and once over London Ontario inbound to Toronto from Seattle (because of thunderstorms). All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Elite Simulator
Since we are comparing sims, I can relate my own experience. I got to sit down at a C172 sim that was partially complete. Unfortunately the primary funder of this project was killed when his 3/4 scale P-51 crashed. Anyway, they did the bulk of their panel using 2d graphics similar to our 2d panel, but had a separate radio stack (ok, but sort of chinsey, probably similar to PFC equipment.) And they had a *really* slick magnetic compass. The 2d graphics were a lot nicer than ours (as in much more closely and completely matching real C172 instruments) but as you looked real close, they had chunky pixels ... like they did the instruments at too low of a resolution, but weren't using any sort of magnification filtering so the result was blocking/chunky ... like running your new laptop at 640x480 full screen res. Their yoke was functional and felt good, but was really clunky looking and didn't quite look like a C172 setup. Their rudder pedals were great with working toe brakes the drove hydraulic pressure sensors. They had purchased a visual system from someone down in FL that covered the whole state. Compared to FlightGear's visuals we pretty much rock. They had more detail modeled in the airport environment, towers, vors, hangers, etc. but not a lot beyond that. They had full approach lighting, although it was omni-directional. Our ground textures were much nicer, and they had no real ability to do terrain that I could see which is probably why they picked florida as their area to cover. They were running 5 display channels and the update rate was really chunky, slow, and jerky. With a couple exceptions, our open source visuals smoked their commercial visuals (although neither of us are MSFS from what I hear.) One of the guys that put this together does aircraft instrumentation for the purpose of deriving simulator flight dynamics and so their C172 was *really* good. They of course do all the fault modeling, and they have a nifty turbulence/gust model. I believe their turbulence model came out of Stanford, so perhaps with a little googling or research, someone could come up with a paper and perhaps we could get soemthing similar implimented? Overall, I think FlightGear compared very favorably on most fronts to their sim. We still have work todo, but the barriers we have between us and a 'full fledged' sim are rapidly being overcome. Once we get full approach lighting implimented it's going to be hard to find significant reasons not to do a 1.0 release ... Regards, Curt. David Megginson writes: I had my first experience with the Elite simulator today (I missed the version -- sorry) at a Precision Controls station. Here are some observations. To my understanding, Elite is the most commonly-used FTD at flight schools in Canada and the U.S., so I'll post some initial observations, on the understanding that they might not apply to the most recent versions. 1. The physical controls have a nice solid feel, especially the rudder pedals, compared to my flimsy USB controls. It's nice having actual knobs to turn for the radios. Unfortunately, the electronic trim button tended to get stuck, so I had to recover five or six times from runway trim. 2. The graphics are very simplistic, but that's no big deal since it's meant mainly as an IFR simulator. The panel is pretty similar to our 2D panel, though slightly more complete. 3. The C172R flight model left a bit to be desired: in a 20deg turn, the nose dropped about 5-10 degrees and needed a *lot* of elevator to maintain altitude. They should hire Tony to help them improve it. 4. The update rate for the gauges is horrendous -- maybe 2-4Hz at best. It was very hard to fly IFR at first with the jumpy needles, until I learned to anticipate the indications. Similarily, the controls seemed to work in fairly large steps rather than smooth gradiants. 5. The instrument lags and errors are no better than ours. For example, a real VOR needle doesn't center instantly when you spin to a new radial, but Elite's (like FlightGear's) did; the Elite mag compass was not nearly as impressively confusing as Alex's in FlightGear. In summary, then, I don't see much preventing FlightGear from becoming a certified IFR FTD other than the trivial problems of time, money, and political influence, once we finish wiring in the electrical system. We'd need to work a bit on an instructor console, making it easy (for example) to place the plane 5.5 miles out on a specified radial from a navaid, but that's no big deal. By the way, thanks to FlightGear, I didn't go through the usual newbie initiation of spiraling out of control in the first simulated vacuum failure -- my instructor was impressed that I diagnosed every failure relatively quickly. I spent most of the time practicing holding patterns. I'm still trying to decide whether to love or hate them: I'll write a
Re: [Flightgear-devel] Wright flyer
Curtis L. Olson [EMAIL PROTECTED] said: Jim, Your Wright flyer model is really starting to look sharp! Good work. :-) Thanks! I was going to do a few more things before announcing it :-) I'm not sure if anyone has tried the java wright brothers sim that's floating around the internet. It seems to have much more severe lateral instability. Takes some practice to keep it in the air more than a few feet. The uiuc model on the other hand can be flown up to 200' AGL for several miles under windless conditions. Note that the actual first flight was done a fairly nasty day with a 15-20 knot headwind, which explains why the 100ft flight took 12 seconds to complete from lift off to touch down. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Wright flyer
David Megginson [EMAIL PROTECTED] said: Curtis L. Olson writes: Your Wright flyer model is really starting to look sharp! Good work. :-) It looks great -- this is the first time I've tried it. With the mouse, at least, it's also quite easy to fly -- I had to work hard to make it overrotate. Thanks. It's getting there. I'm still trying to figure out from Orville's description how the elevator mecahnism works (for animation). Might need to go down to Owl's head again to take a another look at their replica. Still thinking about wing warping... (hints to the animation code guru :-)) Jim: you need to make sure that the propellers are drawn last so that they don't obscure the airplane in external view. If you name all of the objects (so that you can tell which is which), you can rearrange them in the *.ac file using an ordinary text editor. Yes I know about that. You guys just caught a bad revision. After commiting the addition of the drive chain runners I realized I forgot to do that. Actually in ac3d it's pretty easy. Just grouping and ungrouping the transparent objects puts them down the bottom of the list. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] standardizing on units
On Wed, 16 Oct 2002 10:09:59 -0500, Curtis L. Olson
[EMAIL PROTECTED] wrote:
Ok, I know this will probably open another can of worms, but I believe
we need to standardize some of our units. I'm half way through
changing all the FlightGear code to follow the new standard and will
try to get my changes committed shortly. For those of you writing new
code or contributing to existing code, here is the new standard for
FlightGear units to be used throughout our project:
Hmm...
uk.rec.sheds, one day the failed apprentice will return to
observe the sheddi masters at jbex.
From an old and yellowed copy of the FAQ found down the back of
my pSofa:
Official shed units are undecided - and probably undecidable - but
Niall [EMAIL PROTECTED] suggests:
There is the opened out fag packet representing a thickness of about
0.025 or 4 stroke petrol engine plug gap (CB ignition); fold in two for
2 stroke or CD ignition, and that favorite of TV science programs; the
one bar electric fire or 1kW.
The furlong/firkin/fortnight system isn't bad: it has the microfortnight
(about 1.2sec) and the millifortnight (about 20min). The mass unit is a
firkin of water, which I think works out to 90 lbs. Thanks Chris Hedley
[In this system the speed of light is 1.79*10^12furlongs/fortnight]
{and the national speed limit (A roads) is 161280f/f}
For angles, Mr Passingham Indeed suggests that the shed unit of rotation
should be the ajar, defined as: the angle between a door and its frame
when there's a slight draught coming through: subsequent discussion
indicates that the chord of this angle will be the width of a British
Standard Cat. Atomic physics has a unit called the barn, equal to
10^-28m^2, and a Hubble is 10^9 light years, so a Hubble-barn is about 1
and 2/3 pints,or just less than one of those new-fangled litre thingies,
which means that drinking a couple of brown ales is like emptying a
bottle the length of the universe with the cross-sectional area of a
medium-sized nucleus. And you thought it was a long way to the Gents.
Boonie calculates the Hubble-radius barn is about 13 liters. This is the
volume of a straw that has the cross-sectional area of a barn and a
length equal to the radius of the universe (given by H^{-1}c).
If you use the old value of H, 55 km/s/Mpc, you get 17 liters. The
extreme value of H near 100 reduces this by half. The current value is
40 H 100 so a median value would give about 13 liters.
The fact that a gallon milk jug has the same volume as a straw with the
area of a medium sized nucleus such as Silicon that reaches to the end
of the universe is one way to visualize just how small and how big those
two numbers really are.
Oh, and thanks to Brian Skinner for clearing up the correct values of
those constants: Frank Malcolm must have been testing the BA bit when
they sent in their values.
An appropriate unit of jbex is the barn-yard-atmosphere
(9.3*10^-24Joules)
And lest we forget, which I did, Brian Skinner mentioned and then James
Garry reminded us, a bit smaller than the barn is the shed: 10^-52 m^2.
There's also a furlong/farad,Faraday/fortnight system, but its unit of
mass, the (Faraday^2*fortnight)/(farad*furlong^2) is impracticably small
at about 2.3 atto kg. Thanks to Boonie for finding and posting the file
with these last two paragraphs in it, and for finding:
A microcentury is about 52.5 minutes;
one nanocentury is about pi seconds;
The micro-Fortnight is approximately a second;
The speed of light (c) is 1.80 tera furlongs per fortnight (or 1.80
furlongs per pico-fortnight);
One teaspoon is 1.6 barn mega-parsecs;
I suggest that the furlong/firkin/fortnight system be mandated
when developing FDM for Porkine Aviation. :)
The FAQ goes on to say:
C++ is something of a sheddy language: full of bits you don't really
need but which might come in useful one day, not easy to get into, and
anything you do want will be impossible to find as it will be buried
under several layers of inherited classes in an include file called from
another include file.
Rick (ex The Shed, nearly recovered now, I think...)
--
I think there is a world market for maybe five computers.
-- Thomas Watson, chairman of IBM, 1943
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
Re: [Flightgear-devel] Wright flyer
Jim Wilson writes: David Megginson [EMAIL PROTECTED] said: Curtis L. Olson writes: Your Wright flyer model is really starting to look sharp! Good work. :-) It looks great -- this is the first time I've tried it. With the mouse, at least, it's also quite easy to fly -- I had to work hard to make it overrotate. Thanks. It's getting there. I'm still trying to figure out from Orville's description how the elevator mecahnism works (for animation). Might need to go down to Owl's head again to take a another look at their replica. Still thinking about wing warping... (hints to the animation code guru :-)) look at the PLIB exposer demo for how the bones go together :^) Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Build Error of /src/Main/main.cxx under MSVC 6.0
I had to remove the following block of code from main.cxx in order to get FlightGear to build under MSVC: #if ( WIN32 ) PFNGLPOINTPARAMETERFEXTPROC glPointParameterfEXT = 0; PFNGLPOINTPARAMETERFVEXTPROC glPointParameterfvEXT = 0; #endif I changed the '#if (WIN32)' to be '#if 0' instead. Thanks, Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Runway lights ...
Some progress to show ... http://www.flightgear.org/tmp/rwy_lights1.jpg http://www.flightgear.org/tmp/rwy_lights2.jpg 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] Build Error of /src/Main/main.cxx under MSVC 6.0
Jonathan, I just made one change to CVS that may help (based on docs only, I don't have access to MSVC) Regards, Curt. Jonathan Polley writes: I had to remove the following block of code from main.cxx in order to get FlightGear to build under MSVC: #if ( WIN32 ) PFNGLPOINTPARAMETERFEXTPROC glPointParameterfEXT = 0; PFNGLPOINTPARAMETERFVEXTPROC glPointParameterfvEXT = 0; #endif I changed the '#if (WIN32)' to be '#if 0' instead. Thanks, Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- 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] Build Error of /src/Main/main.cxx under MSVC 6.0
Curt, It compiles, links, and runs. Thanks for the fix. Jonathan Polley On Wednesday, Oct 16, 2002, at 11:37PM, Curtis L. Olson [EMAIL PROTECTED] wrote: Jonathan, I just made one change to CVS that may help (based on docs only, I don't have access to MSVC) Regards, Curt. Jonathan Polley writes: I had to remove the following block of code from main.cxx in order to get FlightGear to build under MSVC: #if ( WIN32 ) PFNGLPOINTPARAMETERFEXTPROC glPointParameterfEXT = 0; PFNGLPOINTPARAMETERFVEXTPROC glPointParameterfvEXT = 0; #endif I changed the '#if (WIN32)' to be '#if 0' instead. Thanks, Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- 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 Of COURSE they can do that. They're engineers! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Wright flyer
Michael Selig [EMAIL PROTECTED] said: At 10/16/02, Curtis L. Olson wrote: Jim, Your Wright flyer model is really starting to look sharp! Good work. :-) People need to check this out if they haven't already: fgfs --aircraft=wrightFlyer1903-v1-nl-uiuc The 1903 Wright Flyer has rudder coupled to wing warping. For this to work out right use: fgfs --aircraft=wrightFlyer1903-v1-nl-uiuc --enable-auto-coordination Then be sure to not input any rudder w/ the stick (i.e. don't twist the joystick). Yes, in fact that should be in the *-set.xml file. It'd probably make sense to disable the rudder control and the throttle as well (there was no throttle on the engine). Another thing that was unique about the warping on the 1903 is the earlier glider twisted the entire wing structure. With the 1903 they trussed it all up so that only the trailing edges warped, making it even more aileron like. My confidence level in terms of the accuracy of the model (sans the engine) is pretty high. It's largely based on NASA Ames data from tests on a replica, which I mention in the readme: ~/fgfsbase/Aircraft/UIUC/wrightFlyer1903-v1-nl/README.wrightFlyer1903.html From what I've read it seems pretty accurate. It's hard to imagine what it must have been like for them to fly that aircraft. Wilbur tried it first, yanking hard back on the elevator to get it to lift off which caused a near stall and broken nose (on the aircraft). Attempting the same thing with this model has the identical result, without the damage of course. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
