Frederic Bouvier wrote:
Hi,
I have problems compiling today's JSBsim with MSVC. I had
to patch the sources like this :
;
- SG_USING_STD(sqrt);
+// SG_USING_STD(sqrt);
because sqrt is not a member of std::
Is this declaration really necessary ? I see that math.h is included
11 lines before
David Megginson wrote:
Fuel costs don't help, obviously, but they're a relatively small percentage
of the cost of operating a plane (i.e. doubling the fuel cost might increase
the cost of flying by 25%). Is maintenance more expensive? Is it taxation
and government fees? Obviously, the
The radio dialog seems to have some precision issues. Using the internal
property browser, it can be seen that com2 (comm[1] in the internal tree)
is set to 118.3 before using the radio dialog. Using the dialog to set
com1 to 118.1, it can be seen from the properties that com1 and com2 are
now
I'm getting alot of this: Alert: catching up on tile delete queue
on the console, in quiet mode, while flying the T-38. There doesn't seem to
be any effect on the sim, though. Is there a way to make this go away?
Dave
--
David Culp
davidculp2[at]comcast.net
On 15 Mar 2004 at 7:14, David Culp wrote:
I'm getting alot of this: Alert: catching up on tile delete queue
on the console, in quiet mode, while flying the T-38. There doesn't seem to
be any effect on the sim, though. Is there a way to make this go away?
see
Martin Spott wrote:
Maintenance _is_ expensive, because aircraft used for commercial
training (not in a flight club) need to have commercial maintenance.
Another part is fuel cost, because we're supposed to pay twice as much
in Europe compared to North America.
And - last but not least - the
David Luff wrote:
The radio dialog seems to have some precision issues. Using the internal
property browser, it can be seen that com2 (comm[1] in the internal tree)
is set to 118.3 before using the radio dialog. Using the dialog to set
com1 to 118.1, it can be seen from the properties that com1
I'm currently using the pa28-161 and the c172-dpm models for the AI traffic, both of
which I
believe are David M's models. These are great models, but there can be quite a few
flying
around in the field of view within a few miles, and this can have quite an impact on
frame rates.
And
D Luff wrote:
c172, and possibly more involved, is there any chance of putting a range LOD on the whole
model that swaps it out for a very low poly version from a certain distance away? I have no
idea of the work involved to create a low poly version from an existing model, so please forgive
Curts,
I am trying to undestand the aircraft development.
I started reading the UFO design, I read ufo.cxx and I would like to know if
there is a tool to change the UFO model.
Regards,
Carlos Renato
___
Flightgear-devel mailing list
[EMAIL
D Luff wrote:
Couple of requests - could the pa28 instruments get a range lod in the same manner as the
c172, and possibly more involved, is there any chance of putting a range LOD on the whole
model that swaps it out for a very low poly version from a certain distance away? I have no
idea of
* [EMAIL PROTECTED] -- Monday 15 March 2004 15:37:
Curts,
Sorry, I'm no Curt (yet) ...
I started reading the UFO design, I read ufo.cxx and I would like to know if
there is a tool to change the UFO model.
Yes. vi(m)
m. ;-)
___
[EMAIL PROTECTED] wrote:
Curts,
I am trying to undestand the aircraft development.
I started reading the UFO design, I read ufo.cxx and I would like to know if
there is a tool to change the UFO model.
To be honest, the UFO is the worst model to look at when you want to add
an aircraft because
Now more serious ...
* [EMAIL PROTECTED] -- Monday 15 March 2004 15:37:
I started reading the UFO design, I read ufo.cxx and I would like to know if
there is a tool to change the UFO model.
What do you mean? Change the 3D model? Any 3D modeler that can generate
plib supported file formats
I'm trying to reduce the 737 xmlauto config to a manageable size by splitting
it up into three parts, one each for autothrottle, pitch modes, and roll
modes. This won't parse:
PropertyList include=737-autothrottle.xml
include=737-autopilot-pitch-modes.xml
On 15 Mar 2004 at 9:41, David Megginson wrote:
D Luff wrote:
Couple of requests - could the pa28 instruments get a range lod in the same manner
as the
c172, and possibly more involved, is there any chance of putting a range LOD on
the whole
model that swaps it out for a very low
On 15 Mar 2004 at 15:11, Erik Hofman wrote:
D Luff wrote:
c172, and possibly more involved, is there any chance of putting a range LOD on
the whole
model that swaps it out for a very low poly version from a certain distance away?
I have no
idea of the work involved to create a
* David Culp -- Monday 15 March 2004 16:04:
I'm trying to reduce the 737 xmlauto config to a manageable size by splitting
it up into three parts, one each for autothrottle, pitch modes, and roll
modes. This won't parse:
PropertyList include=737-autothrottle.xml
[EMAIL PROTECTED] wrote:
Curts,
I am trying to undestand the aircraft development.
I started reading the UFO design, I read ufo.cxx and I would like to know if
there is a tool to change the UFO model.
Hi Carlos,
If you are you trying to create a new aircraft, then for most normal cases
you
From: Martin Spott [EMAIL PROTECTED]
David Megginson wrote:
Fuel costs don't help, obviously, but they're a relatively small percentage
of the cost of operating a plane (i.e. doubling the fuel cost might increase the
cost of flying by 25%). Is maintenance more expensive? Is it taxation
David Culp wrote:
I'm trying to reduce the 737 xmlauto config to a manageable size by splitting
it up into three parts, one each for autothrottle, pitch modes, and roll
modes. This won't parse:
PropertyList include=737-autothrottle.xml
include=737-autopilot-pitch-modes.xml
[EMAIL PROTECTED] wrote:
Curts,
I am trying to undestand the aircraft development.
I started reading the UFO design, I read ufo.cxx and I would like to know if
there is a tool to change the UFO model.
Regards,
Carlos Renato
I always wondered why LOD is generally calculated based on distance
The problem there is that whitespace is allowed in filenames on some OS's,
so we'd have to escape it, and things would get fairly messy.
Thanks Dave, I'll just keep the autothrottle stuff separate and leave the
rest where it is. That'll do.
Dave
--
David Culp
Josh Babcock wrote:
I always wondered why LOD is generally calculated based on distance in
sims, and not on the number of polys rendered. Distance is pretty
meaningless when you have a a variable FOV, which lots of 3d sims and
games do. Is there some reason I don't know about other than
How about shifting the pilot-viewpoint-posistion proportional to the
forces that act on the pilot in order to visualise them. A high g force
would push the pilot down in his seat, shifting the viewpoint down etc.
This is used in IL-2 Sturmovik and I think it does a good job of showing
the
I'm trying to add import/export of IGC file formats capability (within the
Network folder, as nmea, garmin, atlas, etc.)
This is a great idea !
Thank you.
Therefore we have simulators :-)
you're completely right
For real life IGC files you might want to ask the people at KFlog,
Roy Vegard Ovesen said:
How about shifting the pilot-viewpoint-posistion proportional to the
forces that act on the pilot in order to visualise them. A high g force
would push the pilot down in his seat, shifting the viewpoint down etc.
This is used in IL-2 Sturmovik and I think it does a
Jim Wilson wrote:
Currently I think we're interested in making the viewer and FDM totally
independent of each other, so something else that manipulates the property
tree values would be the best way to go. My thought is the viewer is on its
way to SimGear soon. Anyway, just wanted to mention
Not to mention blackout/redout from extreme G's.
-Ethan
From: David Megginson <[EMAIL PROTECTED]>
Reply-To: FlightGear developers discussions <[EMAIL PROTECTED]>
To: FlightGear developers discussions <[EMAIL PROTECTED]>
Subject: Re: [Flightgear-devel] Visualising forces
Date: Mon, 15 Mar 2004
David Megginson said:
Jim Wilson wrote:
Currently I think we're interested in making the viewer and FDM totally
independent of each other, so something else that manipulates the property
tree values would be the best way to go. My thought is the viewer is on its
way to SimGear soon.
Currently I think we're interested in making the viewer and FDM totally
independent of each other, so something else that manipulates the property
tree values would be the best way to go.
Extreme G's, obviously, should slam the head around a bit.
Maybe the nasal script could do this:
I just tried to build FlightGear under Cygwin. When I build, I get the following:
In file included from glut_shapes.c:59:
/usr/include/w32api/GL/glu.h:230: error: syntax error before '*' token
In file included from glut_shapes.c:61:
glut_shapes.h:12:1: warning: APIENTRY redefined
In file
Hopefully someone who knows the answer will jump in and correct me if I'm
wrong, but this sounds like the errors people were getting when they
installed the cygwin X11 packages. These provide conflicting versions of
the opengl headers which cause the build to fail. I think the current
i'm using msvstudio .NET .
i've installed cygwin and run
autogen.sh.
but when i run configure i get the following
output:
which says configure is finding the wrong version
of plib. it want 1.6.0 but i've tried both 1.6.0 AND 1.7.0.
has anyone seen this before?
$ ./configurechecking for
i assume
fgfs.cxxfgfs.hxx
get created by the configure script as i don't see
them in the Main directory.
since i can't get configure to work, is there
anyway someone who is using .NET/Vc7 can send me these files?
thanks,
john
___
Jim Wilson writes:
Currently it is
possible to control all aspects of the camera position and angle through the
property tree (in the /sim/current-view path),
I see 'heading' and 'pitch' but not 'roll'.
I guess I must be missing something ?
Best
Norman
Hopefully someone who knows the answer will jump in and correct me if I'm
wrong, but this sounds like the errors people were getting when they
installed the cygwin X11 packages. These provide conflicting versions of
the opengl headers which cause the build to fail. I think the current
Norman Vine said:
Jim Wilson writes:
Currently it is
possible to control all aspects of the camera position and angle through the
property tree (in the /sim/current-view path),
I see 'heading' and 'pitch' but not 'roll'.
I guess I must be missing something ?
Best
Norman
Jim Wilson writes:
Norman Vine said:
Jim Wilson writes:
Currently it is
possible to control all aspects of the camera position and angle through the
property tree (in the /sim/current-view path),
I see 'heading' and 'pitch' but not 'roll'.
I guess I must be missing
does anyone know why i can't compile the following
program?
for some reason gcc doesn't like
plib/ul.h.
$ cat test.c
#include plib/ul.h
int main(){return 1;
}
$ gcc -I/cygdrive/c/cygwin/usr/include test.cIn
file included from test.c:2:/usr/include/plib/ul.h:135: error: syntax error
Orthonormalize writes:
does anyone know why i can't compile the following program?
for some reason gcc doesn't like plib/ul.h.
$ cat test.c
#include plib/ul.h
int main()
{
return 1;
}
$ gcc -I/cygdrive/c/cygwin/usr/include test.c
PLib is a c++ library and gcc doesn't know that,
I deleted my cygwin installation and started from scratch (somehow, I
had X installed previously). Unfortunately, even though I made sure
that X11 was not installed, the problem didn't go away. plib builds
just fine, it is just SimGear that is having a problem. I will try to
fiddle around a
Yes, I ran into this problem as well. I work around it by temporarily renaming
the /usr/X11R6 directory, i.e.,
cd /usr
mv X11R6/ X11R6.tmp
cd
cd src/SimGear
[build commands]
cd ../FlightGear/source
[build commands]
cd /usr
mv X11R6.tmp X11R6
I realize that this is a bit of kludge, but I works,
Jonathan Polley wrote:
I just tried to build FlightGear under Cygwin. When I build, I get the
following:
In file included from glut_shapes.c:59:
/usr/include/w32api/GL/glu.h:230: error: syntax error before '*' token
In file included from glut_shapes.c:61:
glut_shapes.h:12:1: warning:
44 matches
Mail list logo
