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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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.
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
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
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*
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
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
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
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
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
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.
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
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
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
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
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
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
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.
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,
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
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
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
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
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
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
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
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
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.
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
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 )
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
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
50 matches
Mail list logo
