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,
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 )
>PFNGLPOINTPARAM
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
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.
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 e
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 g
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 19
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
"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 t
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 pan
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
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
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.
"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.
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 ov
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
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
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
> r
"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
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 stabil
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
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
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
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
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
--
Andre
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
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 interfa
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*
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 th
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
accelera
"Curtis L. Olson" 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
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.
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
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
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
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. Ho
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 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
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.
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
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.
exa
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
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.
>
> No
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: FG
"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 ar
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
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
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 fro
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 q
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,
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
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 e
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.
>
> Fli
53 matches
Mail list logo