Jonathan Polley wrote:
> I just updated to the newest uiuc_menu.cpp and am still getting the
> compile problem, but far fewer instances. MSVC error is:
>
> c:\flightgear\src\fdm\uiucmodel\uiuc_menu.cpp() : error C2106: '=' :
> left operand must be l-value
>
>
> on the following lines:
>
Jonathan Polley wrote:
> I just updated to the newest uiuc_menu.cpp and am still getting the
> compile problem, but far fewer instances. MSVC error is:
>
> c:\flightgear\src\fdm\uiucmodel\uiuc_menu.cpp() : error C2106: '=' :
> left operand must be l-value
>
>
> on the following lines:
>
> Ok, people, please have a look at
> rsync scenery.flightgear.org::Base
> and tell me what you think.
Very nice, indeed,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--
I tried this
fgfs --aircraft=c172-3d --fdm=yasim
and had an interesting experience -- I ended up sitting on the runway
a meter or two to the right of the plane, rather than inside it.
Things got even more interesting when I started playing with the view
position offsets, because everything w
Michael,
What you are observing isn't exactly how you describe, although it appears
that way. I was trying to simplify things by just pointing out that the
aircraft stays horizontal (appears to not roll) in the chase view, but that
isn't exactly how it works.
The difference is that the xyz offs
David Megginson <[EMAIL PROTECTED]> said:
> I tried this
>
> fgfs --aircraft=c172-3d --fdm=yasim
>
> and had an interesting experience -- I ended up sitting on the runway
> a meter or two to the right of the plane, rather than inside it.
>
Something is overwriting the xyz offsets in the c172
On Wed, Apr 03, 2002 at 11:15:55AM +0200, Erik Hofman wrote:
> It would be nice to see if the attached test program produces the
> following output on all supported platforms(This would allow us to
> improve the speed of the code dramattically by using memcpy instead of
> for-loops):
>
> 0
Jim Wilson writes:
> That is intentional. Before the pilot and chase were different
> than each other (or seemed that way). Prior to knowing anything
> about using plib or Opengl, I always assumed as a user that x was
> across the screen, y was up and down and z was depth. That is I
> thi
Hi there,
my name is Quint Mouthaan and I'm a student at the Technical University
Delft in the Netherlands. I'm working a project in which we want to use
FlightGear. The first thing we want to do is analyze some flight data. I saw
a thread a little while ago about a tool that would be added to Fl
David Megginson <[EMAIL PROTECTED]> said:
>
> Sorry for the confusion there. I think that it's probably not a good
> idea to do things that way -- we should stick with normal aircraft
> axes for consistency with the rest of FlightGear, at least at the
> property level (a GUI can present things
Quint Mouthaan writes:
> my name is Quint Mouthaan and I'm a student at the Technical University
> Delft in the Netherlands. I'm working a project in which we want to use
> FlightGear. The first thing we want to do is analyze some flight data. I saw
> a thread a little while ago about a tool
Jim Wilson writes:
> It's already inconsistent. The model is one way (as you expected) and the
> panel xml is x across and y up/down.
Yes, I know. One consideration, though, is that each panel is (soon)
going to be projected to any arbirtary location and orientation in the
aircraft, so you c
On Wed, 03 Apr 2002 14:57:01 +0200
Quint Mouthaan <[EMAIL PROTECTED]> wrote:
>Delft in the Netherlands. I'm working a project in which we want to use
Can you tell us about your project? We always like to hear
about how FlightGear is being used. :-)
>FlightGear. The first thing we want to do
Jim Wilson wrote:
> David Megginson wrote:
> > I tried this
> >
> > fgfs --aircraft=c172-3d --fdm=yasim
> >
> > and had an interesting experience -- I ended up sitting on the runway
> > a meter or two to the right of the plane, rather than inside it.
>
> Something is overwriting the xyz o
Jim Wilson wrote:
> It's already inconsistent. The model is one way (as you expected)
> and the panel xml is x across and y up/down.
But this is OK -- these are different coordinate systems with
different usages. You'll never put airframe coordinates into the
panel XML, nor use panel coordina
Andy Ross <[EMAIL PROTECTED]> said:
> Jim Wilson wrote:
> > David Megginson wrote:
> > > I tried this
> > >
> > > fgfs --aircraft=c172-3d --fdm=yasim
> > >
> > > and had an interesting experience -- I ended up sitting on the runway
> > > a meter or two to the right of the plane, rather tha
On Wed, 03 Apr 2002 09:32:12 -0800
>> Something is overwriting the xyz offsets in the c172-3d-set.xml or
>> maybe it isn't reading that file? Those are defaults from
>> somewhere...probably from c172-set.xml.
Andy Ross <[EMAIL PROTECTED]> replied:
>YASim _sets_ those offsets based on its ow
David Megginson <[EMAIL PROTECTED]> said:
> > If I was the only one to have say in this I'd make the xyz in the
> > model files conform to the expected by the user axes (x across, y
> > up/down, z depth). It is also what would be expected by anyone who
> > is unfamiliar with plib but has don
Jon S Berndt <[EMAIL PROTECTED]> said:
> On Wed, 03 Apr 2002 09:32:12 -0800
>
> >> Something is overwriting the xyz offsets in the c172-3d-set.xml or
> >> maybe it isn't reading that file? Those are defaults from
> >> somewhere...probably from c172-set.xml.
>
> Andy Ross <[EMAIL PROTECTED]>
Jim Wilson wrote:
> Andy Ross wrote:
> > David Megginson wrote:
> > > Something is overwriting the xyz offsets in the c172-3d-set.xml or
> > > maybe it isn't reading that file? Those are defaults from
> > > somewhere...probably from c172-set.xml.
> >
> > YASim _sets_ those offsets based on
Andy Ross <[EMAIL PROTECTED]> said:
> Jim Wilson wrote:
>
> Ultimate, the pilot position comes from the tag in the YASim
> .xml file. The rationale here was that this was the best place to put
> the information about the cockpit position was in the aircraft
> definition. But that was before t
Hi all,
I'm a physicist from Bonn/Germany and though I haven't written to the
developer list yet I'm scanning it now for some months. I'm
really impressed by the progress that has been achieved in this short
time and FlighGear has come a long way since I first had a look at it
some years back. I'
Hi again,
a question I forgot in my last mail. Does anybody of you know how to
control the view direction (in the 3D cockpit) with the coolie hat on a
FlighSimYoke? First, I have the problem that the hat direction is coded
with two digital axis and they are not uncorrelated. What I have achieved
- Original Message -
From: "Julian Foad" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, April 03, 2002 1:16 PM
Subject: Re: [Flightgear-devel] UIUC compile problem
> Robert, maybe I'm missing something but it looks to me like you don't need
to do all this copying; you just
Andy Ross <[EMAIL PROTECTED]> said:
> Jim Wilson wrote:
> > That's ok, but as I said earlier, the offsets that the viewer will
> > use will be defined elsewhere because they are not necessarily the
> > true actual pilot's eye point.
>
> We're evidently talking past each other. What you say i
On Wed, 3 Apr 2002 20:47:57 -
"Jim Wilson" <[EMAIL PROTECTED]> wrote:
> If there is something that I need to use that comes
>from the FDM let me know what it is and how to use it.
> But I'm not going to be setting the eyepoint with FDM data (other than
>offseting it from the available ori
Bernie Bright has submitted a simplified boost distribution for
SimGear and I have committed it to CVS. The boost web page is here:
http://www.boost.org/
We will begin depending on this package soon. We are treating it in
the same way we treat the zlib and metakit libraries. It is another
Alexander Kappes writes:
> a question I forgot in my last mail. Does anybody of you know how to
> control the view direction (in the 3D cockpit) with the coolie hat on a
> FlighSimYoke? First, I have the problem that the hat direction is coded
> with two digital axis and they are not uncorrel
Jim Wilson wrote:
> Andy Ross wrote:
> > The FDMs already take the c.g. into consideration. If a stopped
> > aircraft rotates (about the c.g, of couse), you will see the
> > coordinate origin moving.
>
> Well this might be useful to the 3D model. The effect probably isn't
> all that notic
Hello,
What's the best way to go about adding custom
terrain to FlightGear? We're developing a soaring model and would like to
be able to add in hills and slopes of any shape.
Also, what about static ground objects? For
example, (is there) || (will there be) a way to add trees and build
Alexander Kappes writes:
> First, how do I get information like actual heading of the plane,
> its vertical speed etc? How is this fgGetNode stuff working and do
> we have something like an internal time? I would prefer not to use
> the real time as that can be changed by the player while the
Hi Alexander,
See the inline comments for your answers. Good luck!
Alexander Kappes <[EMAIL PROTECTED]> said:
> First, how do I get information like actual heading of the plane, its
> vertical speed etc? How is this fgGetNode stuff working and do we have
> something like an internal time?
Ta
Andy Ross writes:
> We're evidently talking past each other. What you say is true. It is
> *also* true that, under YASim, you have non-zero pilot offset numbers.
> These are (1) defined by the FDM, in conflict with similar definitions
> in the model, and (2) in an apparently different coord
Jon S Berndt writes:
> I'm not sure I understand what you are saying, here. I will say,
> however, that if there is a viewpoint given for pilot eyepoint in a
> JSBSim config file it would be good to reference it somehow (even
> if you copy it into an aircraft 3d model file) because it will be
I mildly disagree.
I think the FGFS should require that the FDMs _and_ the aircraft models
all have the reference point at the original manufacturer's defined
reference point (so they all match nicely) even if this is done by
a parametric offset that the FDM's configuration file has somewhere.
T
On Wed, 3 Apr 2002 16:26:57 -0600 (CST)
"Curtis L. Olson" <[EMAIL PROTECTED]> wrote:
>The FDM defines some aribitrary reference point (i.e. on the firewall)
>and provides the lon/lat/elev of that point.
We provide the lat/lon/elev of the current _CG_.
>The FDM really doesn't care about the a
Hello,
I didn't express myself when changes were made to the interface of property
classes,
resulting in the change of string to const char * but now, I experiment many
segfault
that are a direct result of these changes.
While I totally agree with the fact that input parameters should be const
c
On Wed, 3 Apr 2002 00:41:26 +0200 (CEST),
Martin Spott <[EMAIL PROTECTED]> wrote in message
<[EMAIL PROTECTED]>:
> > From: Alex Perry <[EMAIL PROTECTED]>
>
> > I don't know whether the IIC has the "Pro" feature set (suspect
> > not). If it does, the Mach64 driver of Utah-GLX works fine for me.
Andy Ross <[EMAIL PROTECTED]> said:
> Jim Wilson wrote:
> > Andy Ross wrote:
> > > The FDMs already take the c.g. into consideration. If a stopped
> > > aircraft rotates (about the c.g, of couse), you will see the
> > > coordinate origin moving.
> >
> > Well this might be useful to the 3D
Quint,
There is Atlas (atlas.sourceforge.net), which connects to Glight Gear and plots the
aircraft's track on a nice moving map display. It doesn't record any other data, but
the source code will show you one way of getting data out of FlightGear.
- Julian
Quint Mouthaan wrote:
>
> Flight
After digging through several README's, FAQ's and Robin's manual I decided
to have a rough try with my so much desired airport.
I did some calculation and then I added two lines to the default.apt(.gz)
file for a minimal airport definition - to have a 'proof of concept' before
I start working on
I have no idea. Last time I touched an rpm was about a year ago.
As I remember, I carefully used a long pole that had an "alien"
on the end ... what do those command line switches mean ?
> On Wed, 3 Apr 2002 00:41:26 +0200 (CEST),
> Martin Spott <[EMAIL PROTECTED]> wrote in message
> <[EMAIL P
Jon S Berndt writes:
> Oh, yeah, I meant to mention that. As I was writing that
> statement the realization slowly came upon me that this
> was likely the case. You are right that it won't be
> noticed in most cases. But, when you do something like
> drop a bomb your viewpoint will jump a smal
Curtis L. Olson writes:
>
>Jon S Berndt writes:
>> On Wed, 3 Apr 2002 22:54:01 -
>> "Jim Wilson" <[EMAIL PROTECTED]> wrote:
>>
>> >Ok, so are you saying that the lon/lat/alt values that
>> >the fdm outputs are at the origin already adjusted for cg?
>>
>> JSBSim gives the lat/lon/alt of the C
On Wed, 3 Apr 2002 17:29:42 -0600 (CST)
"Curtis L. Olson" <[EMAIL PROTECTED]> wrote:
>Jon S Berndt writes:
>I think this boils down to let's have the FDM worry about where the
>plane is, and let's have FlightGear worry about where the current view
>point is.
I agree. We don't care about where
On Wed, 3 Apr 2002 18:44:23 -0500
"Norman Vine" <[EMAIL PROTECTED]> wrote:
>My take on this is that all we need is a 'fixed' position ie 'Center of
>Geometry' returned by the FDM. This fixed position can be anywhere
>on the AirFrame and it needs to be described more exactly in the
>individua
Jon S Berndt writes:
> "Norman Vine" <[EMAIL PROTECTED]> wrote:
>
>>My take on this is that all we need is a 'fixed' position ie 'Center of
>>Geometry' returned by the FDM. This fixed position can be anywhere
>>on the AirFrame and it needs to be described more exactly in the
>>individual mode
Jon S Berndt <[EMAIL PROTECTED]> said:
> On Wed, 3 Apr 2002 18:44:23 -0500
> "Norman Vine" <[EMAIL PROTECTED]> wrote:
>
> >My take on this is that all we need is a 'fixed' position ie 'Center of
> >Geometry' returned by the FDM. This fixed position can be anywhere
> >on the AirFrame and it n
On Tue, 02 Apr 2002 15:04:59 -0600, "Jon S Berndt"
<[EMAIL PROTECTED]> wrote:
>On 02 Apr 2002 15:45:18 -0500
> Sam Varner <[EMAIL PROTECTED]> wrote:
>>I'm working on an automotive simulator, http://vamos.sourceforge.net A
>>while ago, Curt suggested that I try to make my car model work with
>>F
I just updated to the latest CVS and tried to build.
ATCmgr.cxx
c:\flightgear\src\atc\atcmgr.cxx(201) : warning C4715: 'FGATCMgr::GetATCPointer' : not all control paths return a value
JSBSim.cxx
c:\flightgear\src\atc\atc.cxx(34) : error C4716: 'FGATC::RemovePlane' : must return a value
Linux comp
Jim Wilson writes:
>
>Jon S Berndt <[EMAIL PROTECTED]> said:
>
>> On Wed, 3 Apr 2002 18:44:23 -0500
>> "Norman Vine" <[EMAIL PROTECTED]> wrote:
>>
>> >My take on this is that all we need is a 'fixed' position ie 'Center of
>> >Geometry' returned by the FDM. This fixed position can be anywhere
>
At 2/13/02, you wrote:
>BERNDT, JON S. (JON) (JSC-EX) (LM) writes:
> > OK. What does Ctrl-U do??
>
>This was a *hack* that incremented altitude by 1000'. It was easy to
>do in LaRCsim. However, it's ugly, not realistic, and I'd rather have
>a more sensible and complete set of repositioning optio
At 4/2/02, you wrote:
>On 02 Apr 2002 15:45:18 -0500
> Sam Varner <[EMAIL PROTECTED]> wrote:
>>I'm working on an automotive simulator, http://vamos.sourceforge.net A
>>while ago, Curt suggested that I try to make my car model work with
>>FlightGear.
>
>!!
>
>>I'd like to start working on that no
>JSBSim can output data to the console or to a file in .csv
>format (comma separated values). JSBSim can also write the
>data out to a socket. See FGOutput.cpp and FGfdmSocket.cpp
>for more information. The socket approach is nice for real
>time stuff. Flightgear may have some or all (and more
How about ctrl-U generates a sudden updraft that increases by 900fpm/sec
for eight seconds, then decreases over the next eight seconds to zero.
All the FDMs are supposed to be able to accept that kind of environment.
> At 2/13/02, you wrote:
> >BERNDT, JON S. (JON) (JSC-EX) (LM) writes:
> > > OK.
> like this feature too. The current deal where the aircraft freezes on
> crashes is not so handy to me. Why not have some sort of realism feature
> that at one extreme does not freeze on crashes and allows for some sort
of
> slew to altitude feature and then on the other extreme you've got to
> >for more information. The socket approach is nice for real
> >time stuff. Flightgear may have some or all (and more)
> >capabilities than this for logging, but perhaps not all of
> >the desired flight dynamics data is available that way.
> >
> Yes, It is.
> I would better if the socket appr
Michael Selig writes:
> I have found the Ctrl-U very useful to jumping up in altitude. Beginners
> like this feature too. The current deal where the aircraft freezes on
> crashes is not so handy to me. Why not have some sort of realism feature
> that at one extreme does not freeze on crashes
On Wed, 3 Apr 2002 15:03:17 -0800 (PST),
Alex Perry <[EMAIL PROTECTED]> wrote in message
<[EMAIL PROTECTED]>:
> > On Wed, 3 Apr 2002 00:41:26 +0200 (CEST),
> > Martin Spott <[EMAIL PROTECTED]> wrote in message
> > <[EMAIL PROTECTED]>:
> >
> > > > From: Alex Perry <[EMAIL PROTECTED]>
> > >
>
On Wed, 3 Apr 2002 17:16:31 -0500,
David Megginson <[EMAIL PROTECTED]> wrote in message
<[EMAIL PROTECTED]>:
> Jon S Berndt writes:
>
> > I'm not sure I understand what you are saying, here. I will say,
> > however, that if there is a viewpoint given for pilot eyepoint in a
> > JSBSim confi
On Thu, 4 Apr 2002 01:13:32 +0200 (CEST),
Martin Spott <[EMAIL PROTECTED]> wrote in message
<[EMAIL PROTECTED]>:
> > On Wed, 3 Apr 2002 00:41:26 +0200 (CEST),
> > Martin Spott <[EMAIL PROTECTED]> wrote in message
> > <[EMAIL PROTECTED]>:
>
> >> You might want to have a look at recent DRI dev
I still like the idea of a crash causing an automatic teleport to
fgfsbase/Scenery/afterlife/
> > like this feature too. The current deal where the aircraft freezes on
> > crashes is not so handy to me. Why not have some sort of realism feature
> > that at one extreme does not freeze on
David Megginson wrote:
> You can control any property with the joystick, but to control the
> view direction, use something like this:
This controls the absolute direction. I find it much more useful to
incrementally adjust the view offsets instead; this matches view
controls in consumer sims
Curtis L. Olson wrote:
> Michael Selig writes:
> > I have found the Ctrl-U very useful to jumping up in altitude. Beginners
> > like this feature too. The current deal where the aircraft freezes on
> > crashes is not so handy to me.
>
> LaRCsim was good at 'bouncing' on impact, but at leas
At 4/3/02, you wrote:
>Michael Selig writes:
> > I have found the Ctrl-U very useful to jumping up in altitude. Beginners
> > like this feature too. The current deal where the aircraft freezes on
> > crashes is not so handy to me. Why not have some sort of realism feature
> > that at one extrem
Andy Ross writes:
> freezing on crashses isn't so handy. What *is* a handy thing to do in
> a crash? I mean, I can't make the plane *not* crash; it already did! :)
>
> There's really nothing "realistic" that can be done in this situation.
> I suppose I could just invert the vertical component o
Jim Wilson wrote:
> Ok, so are you saying that the lon/lat/alt values that the fdm outputs
> are at the origin already adjusted for cg? If so then how would that
> affect the axis of say pitch rotation on the c172 model? It's origin
> is at the firewall and the pitch rotation is always on th
Jon S. Berndt wrote:
> Jim Wilson wrote:
> > Ok, so are you saying that the lon/lat/alt values that the fdm
> > outputs are at the origin already adjusted for cg?
>
> JSBSim gives the lat/lon/alt of the CURRENT CG - NOT the origin of the
> structural frame.
Ack, really? I was honestly unde
Curtis L. Olson wrote:
> Here's what make sense to me.
>
> The FDM defines some aribitrary reference point (i.e. on the firewall)
> and provides the lon/lat/elev of that point.
>
> The FDM really doesn't care about the actual FlightGear view point.
> It won't know if the user is flying from
Andy Ross <[EMAIL PROTECTED]> said:
> Jim Wilson wrote:
> > Ok, so are you saying that the lon/lat/alt values that the fdm outputs
> > are at the origin already adjusted for cg? If so then how would that
> > affect the axis of say pitch rotation on the c172 model? It's origin
> > is at the
At 4/3/02, you wrote:
>Andy Ross writes:
> > freezing on crashses isn't so handy. What *is* a handy thing to do in
> > a crash? I mean, I can't make the plane *not* crash; it already did! :)
> >
> > There's really nothing "realistic" that can be done in this situation.
> > I suppose I could just
> Ack, really? I was honestly under the impression that you were
> handing out the coordinate frame too; I thought I had checked this in
> code when writing YASim.
Perhaps this is related to the misunderstanding of our gear model and how we
determined where we were?
> Why c.g.? Since it moves,
Jim Wilson writes:
>
>As far as the viewer.cxx and model.cxx code are concerned the axes for
>orientation rotations will continue to be at the model origin
>(which is set at
>the lon/lat/alt reported by FDMs) until further notice :-)
Ah... the CG :-)
> Curt hits the nail on the head --- I'd just like to continue on, and I
> ...
> crashes. Yes, I could restart, but it would be easier to plow along with
We'll be glad to honor any sane request ...
Recommendations?
Jon
___
Flightgear-devel mailing
Regarding the thread you are referring to - The code is presently with Alex
Perry and he is in the process of integrating it into SimGear (?) and should
be available soon.
Regards
Ranga
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Quint
Mouthaan
Sent:
Here's a series from the tower (aka RC pilot) view. Note that I really have
trouble flying this way. The last seen is 2.3 seconds before impact :-)
http://www.spiderbark.com/fgfs/towerpreview.png
Best,
Jim
___
Flightgear-devel mailing list
[EMAIL P
How do I see the 3D cockpit?
[]'s
Marcio Shimoda
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Looking good. From an R/C perspective, it would be great to have an
aircraft shadow for judging altitude. Having worked mainly on the UIUC/FDM
side of things, I'm not sure how difficult it would be to add this...
Glen
- Original Message -
From: "Jim Wilson" <[EMAIL PROTECTED]>
To: <[EM
Marcio Shimoda <[EMAIL PROTECTED]> said:
> That's great!
Thanks.
> Is this working on the current CVS?
>
Not yet, I'm working on the view manager's xml config processing right now.
This was just a test of the plan I was working with (seems to work!).
Hopefully it'll be done in the next day or
Glen Dimock <[EMAIL PROTECTED]> said:
> Looking good. From an R/C perspective, it would be great to have an
> aircraft shadow for judging altitude. Having worked mainly on the UIUC/FDM
> side of things, I'm not sure how difficult it would be to add this...
>
> Glen
>
This has been discussed.
On Wed, 3 Apr 2002 21:31:43 -0600,
"Jon Berndt" <[EMAIL PROTECTED]> wrote in message
<[EMAIL PROTECTED]>:
> > Curt hits the nail on the head --- I'd just like to continue on, and
> > I...
> > crashes. Yes, I could restart, but it would be easier to plow along
> > with
>
> We'll be glad to hon
"Curtis L. Olson" <[EMAIL PROTECTED]> said:
> Perhaps Michael likes the ability to 'continue on' after a crash
> without having to start over? Would reseting and ground trimming at
> the crash site be enough? Air start at XXX' AGL @ YYY kts at the
> last good heading at the time of the crash?
> > We'll be glad to honor any sane request ...
> >
> > Recommendations?
>
> ..ignore planet Earth? Spool the movie back?
> Autofire big recoilless tunnel-maker gun?
Someone's been in the cold too long. ;-)
Jon
___
Flightgear-devel mailing list
> Regarding the thread you are referring to - The code is presently with Alex
> Perry and he is in the process of integrating it into SimGear (?) and should
> be available soon.
On a side note ... Curt, did you decide whether you want to have it in
the CVS tree for SimGear ? If you did and you s
Alex Perry writes:
> > Regarding the thread you are referring to - The code is presently with Alex
> > Perry and he is in the process of integrating it into SimGear (?) and should
> > be available soon.
>
> On a side note ... Curt, did you decide whether you want to have it in
> the CVS tree for
> I need to pick a less popular project to be involved in ... maybe a
> python to cobol translator written in prolog.
Which reminds me ... does Mesa have support for AALIB yet ?
Several people have been complaining about having to run FGFS under
X and/or Windows. I know that AALIB supports both
Erik,
Worked like a champ.
Jonathan Polley
On Wednesday, April 3, 2002, at 03:05 AM, Erik Hofman wrote:
> Jonathan Polley wrote:
>> I just updated to the newest uiuc_menu.cpp and am still getting the
>> compile problem, but far fewer instances. MSVC error is:
>> c:\flightgear\src\fdm\uiu
At 4/3/02, you wrote:
> > Curt hits the nail on the head --- I'd just like to continue on, and I
> > ...
> > crashes. Yes, I could restart, but it would be easier to plow along with
>
>We'll be glad to honor any sane request ...
>
>Recommendations?
>
>Jon
>
Asking me?
true or false
Seriously,
Doing some more investigation, I found that there is a runways.cxx in both
FlightGear/src/ATC and FlightGear/src/Airports. Are they the same?
Thanks,
Jonathan Polley
On Wednesday, April 3, 2002, at 07:30 PM, Jonathan Polley wrote:
> I just updated to the latest CVS and tried to build.
>
> AT
David Megginson wrote:
> > The changes also introduced the need for the caller to allocate a
> > string or to call strcmp that I consider ugly (it's a matter of
> > taste) in C++ programs and that obfus cate the code.
>
> That's why I originally used std::string, but then I found the
> string
Hi David,
> You can control any property with the joystick, but to control the
> view direction, use something like this:
>
>
>
>property-scale
>/sim/view/axes/lat
>
>
>
>
>
>property-scale
>/sim/view/axes/long
>
>
>
Thanks, this solves part of my problem. How
Hi Andy,
> The bindings support a "high" and "low" pseudo-property for this.
> There's a FAQ somewhere on the website about it, but the basic idea is
> that you do:
>
>
>
> true
>
> property-adjust
> WHATEVER
> 1.0
>
>
>
> true
>
>
Hi David,
> Just about any information you want is available in the property
> tree. There's an interactive GUI browser built into FlightGear --
> choose "Properties" from the "View" drop-down menu.
How do I have to imagine this property tree, I mean how is it realized in
memory (C++) and what
93 matches
Mail list logo