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:
1454,
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:
1454,
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
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
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
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 1
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
think
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
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
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
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 is
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 offsets in the
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
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 than inside it.
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 own
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 done other
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] replied:
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 its own
Andy Ross [EMAIL PROTECTED] said:
Jim Wilson wrote:
Ultimate, the pilot position comes from the cockpit 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
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.
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 need
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 is true.
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 origin
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
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
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 noticable
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
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?
Take a
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.
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 actual
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
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.
You might
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 model. The
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:
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
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 CURRENT CG - NOT the
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 the
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
individual
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 needs to be
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
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
on the AirFrame and
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 options
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 now, but I don't
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)
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
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]
I don't know whether
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 config file it
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 extreme does
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 of
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 the
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 under the
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 firewall
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 invert the
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, it
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
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: [EMAIL
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...check
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 honor any sane
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?
Fly!
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
[EMAIL
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
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 SimGear
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:
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?
plowtrue or false/plow
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.
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 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:
axis n=...
low
repeatabletrue/repeatable
binding
commandproperty-adjust/command
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 kind
75 matches
Mail list logo
