Re: [Flightgear-devel] Some little bugs report from an enthusiast new user...
Jim Wilson writes: > 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 shows up when you zoom in a bit. 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] Bugzilla
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Has anyone thought of using bugzilla to keep track of bugs and suggestions for FlightGear? If no one else wants to, I could administer it, since I seem to have no time to code these days. Thanks, David - -- If you give someone a program, you will frustrate them for a day. If you teach them how to program, you will frustrate them for a lifetime. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9rBHTZOfFgbBAbXARAr9MAKCFZ8brp0P5pEcoqhg8zpC/SkUBLwCfc/Xl z8MSRYSqBrDgu9KX2vDwnNY= =Xq4J -END PGP SIGNATURE- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FSAA frustration continues (Nvidia forum post)
Dave, On a Geforce3 and a GeForce4 Ti4200 I have observed that FSAA works fine, except when I try to exit FlightGear, my entire machine locks up. On GeForce2, you can't FSAA at resolutions over 800x600 I believe ... and I'll take 1600x1200 over 800x600 FSAA any day ... The Geforce3/4 behavior certainly seems like a driver bug ... Regards, Curt. Dave Perry writes: > I posted the following note to the Nvidia linux forum. The issue seems > to be an interaction between fgfs and the Nvidia driver. > > > NVIDIA linux foum post: > > I am a FlightGear enthusiast. Over the past year I have run various > kernels with all the released nvidia linux drivers and various versions > of FlightGear. My experience separates into two categories: > 1. No FSAA affect no matter what value for __GL_FSAA_MODE is exported. > In this case, Flight Gear runs with no system lock ups. > 2. FSAA affect follows the value of __GL_FSAA_MODE while running > FlightGear for some versions but not others. But the system ocasionally > locks up when changing active windows or active resolutions. > > On page 52 of the Nvida Release 25 Notes, the second note indicates that > "When FSAA is enabled ... the rendering may be corrupted when resizing > the window." This is not a minor inconvenience, for it appears to be the > cause of complete system lock ups that force hard resets. > > I can run FlightGear from my Windows XP partition (compiled under > Cygwin) at all resolutions and all FSAA settings. So why can't Nvidia > get this stability in their Linux drivers. > > My system is an Athlon XP 1800+ with an Asus A7M266 mother board, 512MB > of PC2100 memory and 3 Seagate Baracuda IV (80GB each). My GF3 is an > Asus V8200 Deluxe. My Linux is a RH7.3 with recent up2date, but I am > running a 2.4.19 kernel compiled from tarball. This kernel has the patch > for the speculative cache conflict also mentioned in the Nvidia docs. > The behavior described is similar for either the 1.0-3123 or the > 1.0-2960 drivers. I always install Nvidia drivers from the source RPMS > using the --rebuild switch so that they for sure match the current > kernel headers, etc. > > What is wierd is that FlightGear 8.0 (recent stable release) runs with > no FSAA no matter what value I export for __GL_FSAA_MODE and therfore > runs w/o crash. However, the CVS version 0.9.0 runs with FSAA ok with > depth 16 and 1600x1200 or 1280x1024. With depth 24, there is no FSAA at > 1600x1200 (thus stable runs), but there is FSAA at 1280x1024 resolution. > In order to switch from the default 800x600 startup window to a > 1600x1200 window, I first must cycle the resolutions (ctrl-alt-"+") and > then resize the window. When I use the normal exit option from fgfs, > occaionally the system hard locks when i click on the "yes" box. > > With depth 16, and any resolution, (1600x1200, or 1280x1024), I must > disable the splash screen, or the system locks up 100% of the time when > running FlightGear with FSAA enabled. > > This is clearly an Nvidia driver bug! Are others having similar issues > with complex applications? > - Frustrated Dave > > > > ___ > 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] FSAA frustration continues (Nvidia forum post)
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? 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] FSAA frustration continues (Nvidia forum post)
Curtis L. Olson > 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),> > 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? The same thing happens for me with both Cygwin gcc 2.95.2 and MingW gcc 3.2 both using Doug Lea's malloc routines which I believe is what most Linux distributions use CVS version of Cygwin Implemeting the thread support seems to make this even worse but this is a totally unscientific observation FWIW This is bad enough so that any flight covering more then 1000km or so is futile for me as once the condition starts it reoccurs quite frequently Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FSAA frustration continues (Nvidia forum post)
Norman Vine writes: > The same thing happens for me with both Cygwin gcc 2.95.2 > and MingW gcc 3.2 both using Doug Lea's malloc routines which > I believe is what most Linux distributions use > > CVS version of Cygwin > > Implemeting the thread support seems to make this even worse > but this is a totally unscientific observation > > FWIW > This is bad enough so that any flight covering more then 1000km or > so is futile for me as once the condition starts it reoccurs quite > frequently Norman, It might be worth verifying that my partial tile free-er routine is actually running. If it's not running or is being bypassed some how, then the condition you are reporting is very understandable. If it is being run, then it's not doing it's job correctly and should be looked into. You can also tune how much of the tile is deleted per frame. 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] FSAA frustration continues (Nvidia forum post)
Norman Vine > > CVS version of Cygwin AACK CVS version of FGFS Norman ___ 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 writes: > Norman Vine writes: > > The same thing happens for me with both Cygwin gcc 2.95.2 > > and MingW gcc 3.2 both using Doug Lea's malloc routines which > > I believe is what most Linux distributions use > > It might be worth verifying that my partial tile free-er routine is > actually running. If it's not running or is being bypassed some how, > then the condition you are reporting is very understandable. If it is > being run, then it's not doing it's job correctly and should be looked > into. You can also tune how much of the tile is deleted per frame. I have twiddled the amount freed each time before but I see the code has changed a little since the last time I tried this. FWIW - I ended up assuming that my poor little 256 meg machine just wasn't big enough to run FGFS anymore under Windows as it appears to be memory related disk thrashing that is killing me. Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some little bugs report from an enthusiastnew user...
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. 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. 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] FSAA frustration continues (Nvidia forum post)
Norman Vine writes: > Curtis L. Olson writes: > > > Norman Vine writes: > > > The same thing happens for me with both Cygwin gcc 2.95.2 > > > and MingW gcc 3.2 both using Doug Lea's malloc routines which > > > I believe is what most Linux distributions use > > > > It might be worth verifying that my partial tile free-er routine is > > actually running. If it's not running or is being bypassed some how, > > then the condition you are reporting is very understandable. If it is > > being run, then it's not doing it's job correctly and should be looked > > into. You can also tune how much of the tile is deleted per frame. > > I have twiddled the amount freed each time before but I see the code > has changed a little since the last time I tried this. > > FWIW - I ended up assuming that my poor little 256 meg machine > just wasn't big enough to run FGFS anymore under Windows as it > appears to be memory related disk thrashing that is killing me. Another test would be to disable the random ground cover objects. How does this impact tile paging performance? FWIW, I've been running on a 256Mb Linux machine with a GeForce2 MX (32Mb) just fine for a year or two. My system is scsi based though so with threaded tile paging, that will definitely make a performance difference. However, it seems that the biggest hit when paging tiles is in freeing memory for tiles that are purged from the cache. 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 > Norman Vine writes: > > > > FWIW - I ended up assuming that my poor little 256 meg machine > > just wasn't big enough to run FGFS anymore under Windows as it > > appears to be memory related disk thrashing that is killing me. > > Another test would be to disable the random ground cover objects. How > does this impact tile paging performance? That just seems to delay the issue a little bit :-( I'll take another wack at debugging this some more but it won't be today Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Licensing issues
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. For those that aren't as familiar with the differences between GPL and LGPL, I will summarize based on my understanding: - They are essentially the same except that the GPL applies to an entire application, where as the LGPL applies only to a specific library. I.e. in a GPL'd application, the entire source code that forms that application must also be GPL'd (or at least have a compatible license.) If someone makes a source code change (i.e. adds value) and distributes that change, they must distribute the new/different source code so everyone else can also benefit. All the rights and benifits which you received, you need to afford them to everyone else. - The LGPL is very similar except it works on the granularity of a library. If I add code or make a change to the a particular LGPL'd library and distribute it, I need to make the source for those changes available. However, unlike the GPL, an LGPL'd library can be linked into a commercial application. The host application can remain commercial. Plib (which flightgear makes heavy use of is LGPL'd.) This means we (an open source project) can use it, and also a commercial application can use it. For plib, this is a big benefit because it means more people can use their code, more people contribute to the code, etc. etc. In the long term the code is probably better than it would have otherwise been. It might be true that some company is able to sell a better product because of the efforts of the plib team, but the hope is that the commercial company will be able to contribute back to plib, just like any other contributor, and in fact the company would have paid developers that may be able to contribute larger chunks of time to plib than a home hobbyist could. SimGear is also completely LGPL'd. I'm not aware of any commercial applications that are currently using it, however at the moment it's pretty specific to the needs of FlightGear/TerraGear. 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. I'm sure there are some people out there that aren't thrilled with the GPL and would be happy to see the licensing relaxed a bit more (and might feel that this is not going far enough.) There may be other's who think the GPL is just fine and would rather not make the licensing more flexible. - I'd be interested in perspectives and discussion, although I highly doubt this would lead to any sort of consensus. :-) - If we wanted to tweak the licensing terms for the FlightGear project, could we? Who has authority to do this. If we can get most authors/contributors to agree, is that good enough? Do we need approval from 100% of the authors/contributors? What if someone doesn't respond negatively now (i.e. they are on vacation, or just don't have time to think about it) and we change the licensing terms, but then they come back in a year and make a big issue of it? What do we do then? Would that be a potential problem? - Personally I'm inclined towards LGPL'ing the FlightGear components at some point in the nearer future. Is there any major opposition to doing this? - The LGPL license means that the code could show up as part of a commercial application and benefit them. However, if they need to make any changes or improvements to the library to meet their needs, those changes would propogate back into our LGPL code. It's conceivable/likely that if a commercial entity used portions of FlightGear's LGPL code, they would be able to contribute back to our project. - Worst case scenario ... someone out there is a jerk and tries to take advantage of us and our efforts. My view is that we out compete them. We continue to develop our open-source version so it kicks their sorry butts. If they have customers that are stupid enough to buy their old, outdated crap, then what are you going to do? A couple rounds of thorough butt kicking and most people will get the idea. It's not unlike commercial competition where a company see's another company's features and hires someone to replicate them. The first company just impliments new and better features. We are open-source so we are all volunteers, but just like the commercial world, we still win by being better. We don't need to make a decision right now, but it would be interesting to hear people's perspective on whether or not this LGPL'ing the library portions of FlightGear would be
Re: [Flightgear-devel] Licensing issues
I don't see a real benefit of changing FGFS from GPL to LGPL ... * The people who don't like GPL probably aren't much happier about LGPL * They (or we) can add a shared-memory tunnel in SimGear for properties * Most proprietary extensions can simply coexist as separate programs Anything that makes sufficiently fundamental changes to FGFS that the property tree isn't enough, while also staying proprietary, is probably going to be a strong source of project forking and should be discouraged. My $0.02 > 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. > > For those that aren't as familiar with the differences between GPL and > LGPL, I will summarize based on my understanding: > > - They are essentially the same except that the GPL applies to an > entire application, where as the LGPL applies only to a specific > library. I.e. in a GPL'd application, the entire source code that > forms that application must also be GPL'd (or at least have a > compatible license.) If someone makes a source code change > (i.e. adds value) and distributes that change, they must distribute > the new/different source code so everyone else can also benefit. > All the rights and benifits which you received, you need to afford > them to everyone else. > > - The LGPL is very similar except it works on the granularity of a > library. If I add code or make a change to the a particular LGPL'd > library and distribute it, I need to make the source for those > changes available. However, unlike the GPL, an LGPL'd library can > be linked into a commercial application. The host application can > remain commercial. > > Plib (which flightgear makes heavy use of is LGPL'd.) This means we > (an open source project) can use it, and also a commercial application > can use it. For plib, this is a big benefit because it means more > people can use their code, more people contribute to the code, > etc. etc. In the long term the code is probably better than it would > have otherwise been. It might be true that some company is able to > sell a better product because of the efforts of the plib team, but the > hope is that the commercial company will be able to contribute back to > plib, just like any other contributor, and in fact the company would > have paid developers that may be able to contribute larger chunks of > time to plib than a home hobbyist could. > > SimGear is also completely LGPL'd. I'm not aware of any commercial > applications that are currently using it, however at the moment it's > pretty specific to the needs of FlightGear/TerraGear. > > 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. > > I'm sure there are some people out there that aren't thrilled with the > GPL and would be happy to see the licensing relaxed a bit more (and > might feel that this is not going far enough.) There may be other's > who think the GPL is just fine and would rather not make the licensing > more flexible. > > - I'd be interested in perspectives and discussion, although I highly > doubt this would lead to any sort of consensus. :-) > > - If we wanted to tweak the licensing terms for the FlightGear > project, could we? Who has authority to do this. If we can get > most authors/contributors to agree, is that good enough? Do we need > approval from 100% of the authors/contributors? What if someone > doesn't respond negatively now (i.e. they are on vacation, or just > don't have time to think about it) and we change the licensing > terms, but then they come back in a year and make a big issue of it? > What do we do then? Would that be a potential problem? > > - Personally I'm inclined towards LGPL'ing the FlightGear components > at some point in the nearer future. Is there any major opposition > to doing this? > > - The LGPL license means that the code could show up as part of a > commercial application and benefit them. However, if they need to > make any changes or improvements to the library to meet their needs, > those changes would propogate back into our LGPL code. It's > conceivable/likely that if a commercial entity used portions of > FlightGear's LGPL code, they would be able to contribute back to our > project. > > - Worst case scenario ... someone out there is a jerk and tries to > take advantage of us and our efforts. My view is that we out > compete them. We continue to develop our open-source version so it > kicks their sorry butts.
Re: [Flightgear-devel] Licensing issues
I thought about LGPL for JSBSim, and IIRC Tony and others were agreeable to that and also had been thinking of that - Tony, correct me if I am wrong. I think it makes a lot of sense. If we are still agreeable to that, I think we can go that route at any time. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Licensing issues
* [EMAIL PROTECTED] (Curtis L. Olson) [2002.10.15 15:24]: > 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. Oh, great. This could turn into the flamewar of the year... :-) > 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. I would not be opposed to this move. I think many pieces of FlightGear could be LGPL'd while leaving the frontend components GPL'd. I am not in favor of making everything LGPL'd. The only problem we run into is having multiple licenses inside of the FG source tree. It's confusing to me when I look at a project that does this. I always have to make sure I double-check the LICENSE file when I enter a directory (BTW, I would suggest having a LICENSE file in every first-level directory in the source tree). I'll through out another idea while we're discussing it: Why don't we move all of the LGPL-wannabe components into SimGear? Or spawn some other sister project for "plugins" (can we call them FlyIns? ;-)? > - If we wanted to tweak the licensing terms for the FlightGear > project, could we? Who has authority to do this. If we can get > most authors/contributors to agree, is that good enough? Do we need > approval from 100% of the authors/contributors? What if someone > doesn't respond negatively now (i.e. they are on vacation, or just > don't have time to think about it) and we change the licensing > terms, but then they come back in a year and make a big issue of it? > What do we do then? Would that be a potential problem? I would think you would have to have all contributors sign off. I don't now if that's even possible since so many people have contributed over the years, but I still think it is the only fair way to go it. I think we should try to diligently contact everyone who has contributed to FG and have them approve the change. If there are some people we can't get ahold of, assume there is a small risk of them coming out of the woodwork but proceed anyway. > - Personally I'm inclined towards LGPL'ing the FlightGear components > at some point in the nearer future. Is there any major opposition > to doing this? Not from me. I'm a fringe player, so I would be fine with going LGPL. I don't know that I would support a more liberal license though. -- Cameron Moore [ Shouldn't we refer to Bigfoot as "Bigfeet"? ] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Licensing issues
Alex Perry wrote: > I don't see a real benefit of changing FGFS from GPL to LGPL ... > * The people who don't like GPL probably aren't much happier about LGPL > * They (or we) can add a shared-memory tunnel in SimGear for properties > * Most proprietary extensions can simply coexist as separate programs I'm inclined to agree. The only real purpose behind the LGPL is to special case the situation of GNU versions of "system" libraries. Applying the GPL strictly to libraries like libc or libstdc++ means that proprietary software can't be run on free operating systems, since the act of linkage makes them a "derived work" according to the license. That's silly, so there's a special-purpose variant of the license that allows linkage (but *only* linkage) of proprietary code. The LGPL has since become popular for library projects that are designed to become standards, or at least widely shared. Projects like plib and SDL use it for that reason -- to keep development open while encouraging use of the library by anyone. FlightGear doesn't really fall into either category, since it's a one-of-a-kind codebase that is used only by other GPLed software. It strikes me that putting, say, the scenery engine under the LGPL isn't likely to encourage anyone to use it as the "standard" scenery engine for anything. Users who want the code are likely going to want to hack at it for their own purposes, which the LGPL forbids. Is there a use case here, or a particular proprietary application you have in mind? It might be simpler to do a custom release to that vendor under a separate license, rather than play with the license for the whole project. The LGPL is a little problematic for most proprietary users. They aren't, contrary to common belief, allowed to use the library any way they want. They have to link expressly against the library as shipped (no cutting and pasting of code), and have to ensure that future users can relink against newer versions of the library if they want (no static linkage, essentially). 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
[Flightgear-devel] KSTL bug
For what it's worth, I did a high speed taxi down the same runway in the JSBSim C172. At the same point on the runway, the C172 takes a hard bounce, goes almost completely nose down vertical, but recovers without "crashing". I don't see any visual discontinuity, so I assume this must be a problem with the code that reports ground elevation. It appears to be happening as we cross tile boundaries, so mostly likely that first elevation change as we cross is bad. We had a potentially similar problem visually when crossing tile boundaries where the visuals would jump way out of position for just one frame. I dumped out the ground elevation as I went over the anomoly and here's what I get: elev = 164.043 elev = 164.041 elev = 164.037 elev = 164.032 elev = 166.037
Re: [Flightgear-devel] Licensing issues
On Tue, Oct 15, 2002 at 03:22:02PM -0500, Curtis L. Olson wrote: > > - If we wanted to tweak the licensing terms for the FlightGear > project, could we? Who has authority to do this. If we can get > most authors/contributors to agree, is that good enough? Do we need > approval from 100% of the authors/contributors? What if someone > doesn't respond negatively now (i.e. they are on vacation, or just > don't have time to think about it) and we change the licensing > terms, but then they come back in a year and make a big issue of it? > What do we do then? Would that be a potential problem? 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. -- James (Jay) Treacy [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] KSTL bug
Curtis L. Olson writes: > I dumped out the ground elevation as I went over the anomoly and > here's what I get: > elev = 164.032 > elev = 166.037
re: [Flightgear-devel] Licensing issues
Curtis L. Olson writes: > 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. Well, GPL or freer. Some of the code that I've written that doesn't incorporate anyone else's is explicitly PD, though that leaves you free to make it GPL if you want. My opinion is already on the record, so I'll just restate it quickly: I prefer Public Domain to LGPL (and LGPL to GPL), both because it makes it easier for companies to use the code without waiting for approval from the legal department, and because I don't believe in making threats I'm not willing to keep (I'm not going to bankrupt myself suing Microsoft if they steal my code, so why pretend that I would)? If people cannot stomach Public Domain, then something freer than LGPL, such as BSD or Perl artistic, would be preferable. The issue in any case is getting permission from original authors who contributed under the GPL; here's a start: I hereby grant permission for any code or other digital objects I've contributed to FlightGear, SimGear, TerraGear, or the FlightGear base package to be relicensed under the LGPL or a less restrictive license, up to and including Public Domain. 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] KSTL bug
Norman Vine wrote: > Curtis L. Olson writes: > > > Could the hitlist code be overly aggressive on what it's caching > > internally? > > Maybe - should be easy enough to back out almost all of the > modifications as I do not believe that the Interface ever changed > much Oh yea - there is an indexing bug in the FAST TRISTRIP logic that somehow never got changed even though the fix was in several of my submissions maybe this has finally reared it's head if the scenery has hit a tristrip but I didn't think we were actualy using any yet easiest to check by just falling back to the 'slightly' slower version by changing the lines in void FGHitList::IntersectBranch( ssgBranch *branch, sgdMat4 m, sgdVec3 orig, sgdVec3 dir ) - GLenum primType = ((ssgLeaf *)kid)->getPrimitiveType(); - IntersectLeaf( (ssgLeaf *)kid, m, orig_leaf, dir_leaf, primType ); to + IntersectLeaf( (ssgLeaf *)kid, m, orig_leaf, dir_leaf ); ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] fgfs crashing at CYYZ
i get a crash trying to fly the a4-yasim out of toronto's pearson international airport (CYYZ). this is the backtrace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 23176)] SGPropertyNode::getDoubleValue (this=0x0) at props.cxx:1117 1117 if (_attr == (READ|WRITE) && _type == DOUBLE) (gdb) where #0 SGPropertyNode::getDoubleValue (this=0x0) at props.cxx:1117 #1 0x080eb3e6 in FGNavCom::update (this=0x9a90440, dt=0) at navcom.cxx:293 #2 0x080e884a in FGNavCom::init (this=0x9a90440) at navcom.cxx:95 #3 0x080fe98b in FGRadioStack::init (this=0x9a83708) at radiostack.cxx:68 #4 0x08078ac1 in fgInitSubsystems () at fg_init.cxx:1169 #5 0x08058d3e in fgIdleFunction () at main.cxx:1311 #6 0x4024bf5e in idleWait () at glut_event.c:962 #7 0x0805cb26 in main (argc=3, argv=0xb584) at main.cxx:1805 --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Bugzilla
On Tue, 15 Oct 2002 23:02:09 +1000 David Findlay <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Has anyone thought of using bugzilla to keep track of bugs and suggestions > for FlightGear? If no one else wants to, I could administer it, since I seem > to have no time to code these days. Thanks, > > David > We already have that facility on sourceforge but its hardly ever used. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] fgfs crashing at CYYZ
Alex Romosan writes: > i get a crash trying to fly the a4-yasim out of toronto's pearson > international airport (CYYZ). this is the backtrace: Which runway? What altitude at the time of the crash? Which scenery distro? I'll see if I can reproduce. 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] Bugzilla
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 16 Oct 2002 08:19 am, Bernie Bright wrote this piece of wisdom: > We already have that facility on sourceforge but its hardly ever used. Well maybe it needs to be setup, and linked on the press releases and front page of the website, so people know about it. At the moment there doesn't seem to be any categories or groups. For a start I think we need at least these categories: Wishlist Crash OpenGL problem FDM Aircraft models Scenery Clouds 3D models GUI Thanks, David - -- If you give someone a program, you will frustrate them for a day. If you teach them how to program, you will frustrate them for a lifetime. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9rJYoZOfFgbBAbXARAqwiAJ9W79m/RBIAl0IYen7OOhrtGr1hOwCeMrfY S2FE308ka3z+0L2CqzJvkJY= =k2qD -END PGP SIGNATURE- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Bugzilla
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 16 Oct 2002 08:19 am, Bernie Bright wrote this piece of wisdom: > We already have that facility on sourceforge but its hardly ever used. BTW I think Bugzilla, with a KDE style bug reporting wizard would be more powerful for tracking these things. Thanks, David - -- If you give someone a program, you will frustrate them for a day. If you teach them how to program, you will frustrate them for a lifetime. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9rJicZOfFgbBAbXARAukgAJ9/YG3jTBB7kWhDS5vUNRcF0ORayQCbBHYZ 8ei0xs/Gk71w7MKbOL2saYU= =CSzm -END PGP SIGNATURE- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: fgfs crashing at CYYZ
David Megginson <[EMAIL PROTECTED]> writes: > Alex Romosan writes: > > > i get a crash trying to fly the a4-yasim out of toronto's pearson > > international airport (CYYZ). this is the backtrace: > > Which runway? What altitude at the time of the crash? Which scenery > distro? I'll see if I can reproduce. the default runway i guess. fgfs doesn't even run (it crashes during initialization). i suspect some problem with the radio frequencies for CYYZ. the scenery is the standard one downloaded from flightgear.org and everything else is the latest from CVS. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: fgfs crashing at CYYZ
Alex Romosan <[EMAIL PROTECTED]> writes: > the default runway i guess. fgfs doesn't even run (it crashes during > initialization). i suspect some problem with the radio frequencies for > CYYZ. the scenery is the standard one downloaded from flightgear.org > and everything else is the latest from CVS. one more thing. last messages i see before fgfs crashes are: Adding subsystem instrumentation Adding subsystem systems Initializing Interpolator for /usr/local/lib/FlightGear/Navaids/range.term Initializing Interpolator for /usr/local/lib/FlightGear/Navaids/range.low Initializing Interpolator for /usr/local/lib/FlightGear/Navaids/range.high Initializing Interpolator for /usr/local/lib/FlightGear/Navaids/range.term Initializing Interpolator for /usr/local/lib/FlightGear/Navaids/range.low Initializing Interpolator for /usr/local/lib/FlightGear/Navaids/range.high Initializing Interpolator for /usr/local/lib/FlightGear/Navaids/range.term Initializing Interpolator for /usr/local/lib/FlightGear/Navaids/range.low Initializing Interpolator for /usr/local/lib/FlightGear/Navaids/range.high Segmentation fault --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Re: fgfs crashing at CYYZ
Alex Romosan writes: > the default runway i guess. fgfs doesn't even run (it crashes during > initialization). i suspect some problem with the radio frequencies for > CYYZ. the scenery is the standard one downloaded from flightgear.org > and everything else is the latest from CVS. Yes, I'm getting a crash with the default C172 as well. It ends with the following: Initializing Interpolator for /usr/local/FlightGear/Navaids/range.term Initializing Interpolator for /usr/local/FlightGear/Navaids/range.low Initializing Interpolator for /usr/local/FlightGear/Navaids/range.high Initializing Interpolator for /usr/local/FlightGear/Navaids/range.term Initializing Interpolator for /usr/local/FlightGear/Navaids/range.low Initializing Interpolator for /usr/local/FlightGear/Navaids/range.high Initializing Interpolator for /usr/local/FlightGear/Navaids/range.term Initializing Interpolator for /usr/local/FlightGear/Navaids/range.low Initializing Interpolator for /usr/local/FlightGear/Navaids/range.high Segmentation fault gdb gives this backtrace: #0 SGPropertyNode::getDoubleValue() const (this=0x0) at props.cxx:1117 #1 0x080a2bbb in FGNavCom::update(double) () #2 0x080a2454 in FGNavCom::init() () #3 0x080b05f5 in FGRadioStack::init() () #4 0x080604cd in fgInitSubsystems () at fg_init.cxx:1169 #5 0x0805635e in fgIdleFunction () at main.cxx:1311 #6 0x40078e8e in __glutRegisterEventParser () from /usr/lib/libglut.so.3 #7 0x4007953b in glutMainLoop () from /usr/lib/libglut.so.3 #8 0x080545db in mainLoop (argc=2, argv=0x986fba8) at main.cxx:1713 #9 0x080546d6 in main (argc=2, argv=0xb954) at main.cxx:1805 In other words, FGNavCom is running getDoubleValue() on a null object. 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] Re: fgfs crashing at CYYZ
At first glance it appears that the radio stack is being created, init'd and bound before the electrical subsystem. This means that properties in the electrical system that the radio stack expects, are not there yet. It seems like an initialization order problem although I don't understand why it doesn't kill us other places. Curt. David Megginson writes: > Alex Romosan writes: > > > the default runway i guess. fgfs doesn't even run (it crashes during > > initialization). i suspect some problem with the radio frequencies for > > CYYZ. the scenery is the standard one downloaded from flightgear.org > > and everything else is the latest from CVS. > > Yes, I'm getting a crash with the default C172 as well. It ends with > the following: > > Initializing Interpolator for /usr/local/FlightGear/Navaids/range.term > Initializing Interpolator for /usr/local/FlightGear/Navaids/range.low > Initializing Interpolator for /usr/local/FlightGear/Navaids/range.high > Initializing Interpolator for /usr/local/FlightGear/Navaids/range.term > Initializing Interpolator for /usr/local/FlightGear/Navaids/range.low > Initializing Interpolator for /usr/local/FlightGear/Navaids/range.high > Initializing Interpolator for /usr/local/FlightGear/Navaids/range.term > Initializing Interpolator for /usr/local/FlightGear/Navaids/range.low > Initializing Interpolator for /usr/local/FlightGear/Navaids/range.high > Segmentation fault > > gdb gives this backtrace: > > #0 SGPropertyNode::getDoubleValue() const (this=0x0) at props.cxx:1117 > #1 0x080a2bbb in FGNavCom::update(double) () > #2 0x080a2454 in FGNavCom::init() () > #3 0x080b05f5 in FGRadioStack::init() () > #4 0x080604cd in fgInitSubsystems () at fg_init.cxx:1169 > #5 0x0805635e in fgIdleFunction () at main.cxx:1311 > #6 0x40078e8e in __glutRegisterEventParser () from /usr/lib/libglut.so.3 > #7 0x4007953b in glutMainLoop () from /usr/lib/libglut.so.3 > #8 0x080545db in mainLoop (argc=2, argv=0x986fba8) at main.cxx:1713 > #9 0x080546d6 in main (argc=2, argv=0xb954) at main.cxx:1805 > > In other words, FGNavCom is running getDoubleValue() on a null > object. > > > 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 -- 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] Re: fgfs crashing at CYYZ
Curtis L. Olson writes: > At first glance it appears that the radio stack is being created, > init'd and bound before the electrical subsystem. This means that > properties in the electrical system that the radio stack expects, are > not there yet. That shouldn't matter, though, as long as the radio stack is using fgGetNode(..., true); That seems to be the case throughout navcom.cxx. 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] Re: fgfs crashing at CYYZ
Errr, not exactly, but my fault. Should be fixed now in cvs. Regards, Curt. David Megginson writes: > Curtis L. Olson writes: > > > At first glance it appears that the radio stack is being created, > > init'd and bound before the electrical subsystem. This means that > > properties in the electrical system that the radio stack expects, are > > not there yet. > > That shouldn't matter, though, as long as the radio stack is using > > fgGetNode(..., true); > > That seems to be the case throughout navcom.cxx. > > > 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 -- 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] Licensing issues
On Tue, 15 Oct 2002 17:37:32 -0400, David Megginson <[EMAIL PROTECTED]> wrote in message <[EMAIL PROTECTED]>: > > My opinion is already on the record, so I'll just restate it quickly: > I prefer Public Domain to LGPL (and LGPL to GPL), both because it > makes it easier for companies to use the code without waiting for > approval from the legal department, and because I don't believe in > making threats I'm not willing to keep (I'm not going to bankrupt > myself suing Microsoft if they steal my code, so why pretend that I > would)? .."pretending", you allow, say, the FSF, to "act on our behalf", or to fund that furball. With PD, AFAIK, you have given up all rights, and your (or the public domains) case never makes it into the court. ..there _are_ many good reasons not to give up copyright for free stuff too, the best ones is to protect that very freedom and price. > If people cannot stomach Public Domain, then something freer than .."public domain" equals "the author drops or donates his copyright to the public domain"? 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. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... 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] KSTL bug
Norman Vine writes: > Oh yea - there is an indexing bug in the FAST TRISTRIP logic that > somehow never got changed even though the fix was in several of > my submissions For what it's worth, separating out individual concepts into separate patch submissions makes things a lot easier and simpler for the patch applier. Mixing a bunch of stuff into a single submission can make it really difficult to sort out what's going on, and without blindly applying everything (which I don't like to do) it's really easy to miss something. Sometimes it's impossible to just blindly apply a whole patch when the submission isn't against the latest cvs. If you take the view that the project coordinator is a complete dummy and make things as simple as possible for him, that can be very helpful. :-) > maybe this has finally reared it's head if the scenery has hit a > tristrip but I didn't think we were actualy using any yet > > easiest to check by just falling back to the 'slightly' slower version > by changing the lines in > > void FGHitList::IntersectBranch( ssgBranch *branch, sgdMat4 m, > sgdVec3 orig, sgdVec3 dir ) > > > - GLenum primType = ((ssgLeaf *)kid)->getPrimitiveType(); > - IntersectLeaf( (ssgLeaf *)kid, m, orig_leaf, dir_leaf, primType ); > > to > > + IntersectLeaf( (ssgLeaf *)kid, m, orig_leaf, dir_leaf ); I tried this change and it didn't seem to have any affect on the problem. :-( 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] Licensing issues
Arnt Karlsen writes: > .."public domain" equals "the author drops or donates his copyright > to the public domain"? It means that the work is released into the public domain. There is no donation, because no one owns (or can own) copyright on their original work, though people can copyright derivatives. > 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. 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). 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] Free At Last
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
Re: [Flightgear-devel] Help
Yes, you can use plugins and scripts to load obj, 3ds,... Marcio Shimoda - Original Message - From: dominic stadden To: [EMAIL PROTECTED] Sent: Sunday, October 13, 2002 7:07 AM Subject: [Flightgear-devel] Help Hi, is it possible to load non gmax .mdl files into gmax. Sorry this message is so brief, but net -time is limited. [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] TC ball
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. This means we can't create a single turn coordinator instrument who's ball behaves reasonably well for every FDM. 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.) 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
Re: [Flightgear-devel] Licensing issues
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 ... (?) 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.) 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 ... 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] Licensing issues
> Arnt Karlsen writes: > > .."public domain" equals "the author drops or donates his copyright > > to the public domain"? 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. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] TC ball
> 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. This means we > can't create a single turn coordinator instrument who's ball behaves > reasonably well for every FDM. Body axes must be the coordinate frame used here, IMHO: +X forward, +Y out the right side, +Z down. The issue of whether to include the local acceleration due to gravity I'll leave for Tony to address - this is probably an issue, if my hunch is correct. > Would it be better to force the FDM's to calculate a ball deflection > in degrees/radians, No. That's not the job of the FDM, IMHO. > or do we need to investigate why the body axis > accelerations are so radically different for 3 different FDM's Yes. > (who > all are trying to model a C172.) If the FDM's do the work, then they > all have to do the failure modeling too. No! > It would be nicer to figure out what's going on ... Yes. > it seems to be more than a simple coordinate > system difference, unless JSBSim/YASim swap X/Y axes or something > strange like that. I believe we do. JSBSim uses the industry standard body axis system as described above. Jon smime.p7s Description: application/pkcs7-signature
Re: [Flightgear-devel] Licensing issues
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. (*)This is what I have surmised from previous discussions on copyright. I have never seen this explicitly stated. I don't like this way of looking at things but we have to deal with the legal system we have been given. > 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. It is precisely because this is false that the FSF will not accept code for software they own the copyright unless you sign a document stating you own the copyright on code that you submit and assign the copyright to the FSF. > 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 ... (?) I wish common courtesy played a part in such matters. When it comes to the law you can't trust people to be polite. Unfortunately, the legal system is inherently combatative(**). SUMMARY If the developers decide to change the license it should be doable. Some person or group will need to track down as many contributors as possible and try to get them to agree to the switch. That is where the real work is. My opinion is that the change won't bring enough benefits to warrant the expenditure of energy. (**) Off topic: the family of a co-worker of my wife completely devastated a few million dollar estate (on lawyers) because one group didn't agree with the terms of the will and contested it. This is not a rare occurence. -- James (Jay) Treacy [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
