Martin Dressler wrote:
And what about this: remove description tag from alias set files which
shouldn't be displayed in --show-aircrafts and show only those with non empty
description. Fill description only in c172-set.xml,j3cub-set.xml etc.
It is simplistic solution and all syntax can stay
Orthonormalize wrote:
i assume
fgfs.cxx
fgfs.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?
These files where moved to SimGear a while ago and
Curtis L. Olson wrote:
Update of /var/cvs/FlightGear-0.9/source/src/FDM/UIUCModel
In directory baron:/tmp/cvs-serv19850/UIUCModel
Hehe, just when you thought it was a while back you heard from the UIUC
developers someone comes running out of their shelter just to throw a
bunch of new code at you
David Luff wrote:
On 3/15/04 at 8:41 PM 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:
Frederic BOUVIER wrote:
Erik Hofman wrote:
Modified Files:
glut_shapes.c glut_shapes.h
Log Message:
Further refinement of the Cygwin problem as suggested by Frederic.
Well, I had the impression that the code was originally good but the
configure step was failing to detect and set
Norman Vine wrote:
This is still wrong windows.h needs to be included *before* gl.h
inorder for the the WINDOWS GL extensions and not the GLX extensions
to be recognized
How do you explain that the extensions code does work this way.
Did you read the code or just the CVS log message?
Erik
Orthonormalize wrote:
i still see:
#include Main/fgfs.hxx
in the file FGLocalWeatherDatabase.h . however i don't see the file fgfs.hxx
anywhere in SimGear.
The WeatherCM module isn't actively maintained anymore. Try building
with --without-weathercm
Erik
Norman Vine wrote:
If it works then it is getting WIN32 predefined from someplace other
then the compiler itself which will break a Cygwin compilation for
GLX X windows OpenGL which is a separate issue
AFAIK the *only* Windows compiler that does not #define WIN32 is Cygwin.
This is in order
David Megginson wrote:
Erik Hofman wrote:
The WeatherCM module isn't actively maintained anymore. Try building
with --without-weathercm
I talked with Curt about removing WeatherCM over a year ago, but I
didn't want to go through with it in case the module sprang back to
life. In the event
Norman Vine wrote:
I still submit that what I proposed is a 'proper' solution and don't
understand what you have against it as it only affects MingW and
Cygwin users.
I'm not against it. I just want to know why this was needed because
obviously the extensions code needs the same update then.
Orthonormalize wrote:
here are my observations:
1) the autoconf/configure process is extremely fickle. in my opinion there
are way too many configurations for flightgear. the problem seems in
trying to support every platform out of the box, fightgear supports no
platform. i know that sounds
Innis Cunningham wrote:
Hi Guys
I don't know if this helps in any way but I did
a complete rebuild(plib,simgear,flightgear) about
7 days ago under Cygwin on windows 98 and did
not have any problem so unless the above area
has been changed in the last 7 days it is not
simgear or cygwin that is to
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
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
[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
Lee Elliott wrote:
Are specular reflections/high-lights only applied to the aircraft models?
No, there is no distinction between objects. Everything can use specular
highlights.
I was wondering how well it might work if it could also be applied to water
covered scenery.
It won't, the surface is
Anil K. Narayanan wrote:
I am extremely sorry, everybody. That empty mail was an
accident.
It's not like my life stopped after that message :-)
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
Erik Hofman wrote:
http://home.clara.net/wolverine/BOB/misc/Spit_Hurri_Manuals.zip
To get back to the original subject, this site has an aweful lot of
information on WWII warbirds, including performance charts:
http://www.rdrop.com/users/hoofj/
Erik
David Megginson wrote:
Frederic Bouvier wrote:
Was this in PLIB 1.6, again? The alpha transparency is fine using
the CVS
I am using the CVS plib and I am seeing this bug.
That's interesting -- is anyone else seeing this problem?
No, not for IRIX, not for Linux.
Erik
David Megginson wrote:
Roy Vegard Ovesen wrote:
Am I being ignored? I don't hope so because I think that the changes
I've made makes the GPS module quite usefull for navigation.
No -- apologies. I typically juggle 30-100 active items in my INBOX,
aside from the 500-1000 spams I receive every
Melchior FRANZ wrote:
* Melchior FRANZ -- Friday 12 March 2004 15:59:
All needles are OK. The only bug that I see is the non-transparent
attitude 'needle': http://members.aon.at/mfranz/pa28.jpg
The SGI image seems to be OK, though (and I'm an SGI image expert :-).
I'll look into plib ...
Yep,
[EMAIL PROTECTED] wrote:
Could someone with cvs access fix this and change in file
../src/FDM/JSBSim/FGEngine.cpp
in line 71 this:
Name.clear();
into this:
Name = ;
So that the compilation works.
Done.
Erik
___
Flightgear-devel mailing list
Martin Spott wrote:
Erik Hofman wrote:
Here are two files for the sgs126. The sgs126-jsbsim-set.xml file now starts
the glider in the air by default. I think some people didn't know it is a
glider, [...]
I assume we already have two of them: The ASW-20 and the SGS 126 -
don't we ?
Yes
Jon Berndt wrote:
Are there any reasons to choose one method over the other in the declaration
of local variables that are used each frame?
Here are some examples. Note that this hypothetical routine would be called
each pass through the EOM (for example):
= Method 2)
Jim Wilson wrote:
For the time being though, I propose that we try to get this default angle to
a higher value. From my testing 61 degrees seems to be a good number. 61
degrees means that a 6 sided cylinder will be smoothed. Anything less (e.g. 4
or 5 sides) will be sharp sided. Many of the
Jonathan Polley wrote:
The fix for the MacOS isnan problem didn't compile. I changed it to be
inline int (isinf)(double r) { return isinf(r); }
inline int (isnan)(double r) { return isnan(r); }
and it worked just fine (it was Real r instead of double). Real wasn't
defined.
I already wondered
David Megginson wrote:
Erik Hofman wrote:
Silently ignore texture files that are not present.
How about putting out a warning at a very low priority level, so that
people can debug problems if they need to?
That would be an option ...
The thing is, we now can have more than one texture
Jonathan Polley wrote:
Plasma TVs tend to be 1280x1024 at a 16:9 aspect ratio, rather than the
4:3 (or 1:1) that it would normally expect. I am assuming that I can
just adjust the field of view, but will that only adjust the horizontal
field or will it adjust the vertical as well?
Use
Martin Spott wrote:
Erik Hofman wrote:
Use --geometry=1280x720 to set it to 16:9.
I've used this on an of on my O2 and it works as expected.
Are you sure you have a _plasma_ display with 1280 columns ?
I'm sure it's not plasma. But I'm not sure if that even matters.
He wanted to be sure
Jonathan Polley wrote:
For some reason, when iostream is included, it messes with the
#include of math.h by undefining isnan(0, no matter the order of the
include.
In order for me to get cloud.cxx to build, I had to add the following
lines after the #include of math.h
#if defined (__APPLE__)
Jon Berndt wrote:
Great news!
Usenix have accepted my abstract so I'm going to write the talk
and the paper over the next few weeks.
Title: The FlightGear Flight Simulator
Author(s): Alexander R Perry, PAMurray
Very cool. The exposure grows ...
Great news indeed!
Erik
http://home.clara.net/wolverine/BOB/misc/Spit_Hurri_Manuals.zip
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Vivian Meazza wrote:
Erik Hofman wrote
http://home.clara.net/wolverine/BOB/misc/Spit_Hurri_Manuals.zip
Is this a hint ;-)?
Yes.
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Vivian Meazza wrote:
Oddly enough, last weekend I found a book in my local bookstore on the
Spitfire MkIIb, containing line drawings. I'll see if it's still there. If
it is, I could do a model especially with the info in the pilot's notes. Is
there a demand for a Spitfire IIB?
There was a
Mathias Fröhlich wrote:
Hi all,
I have done a new joystick definition for my hardware. This is the
thrustmaster top gun afterburner USB (what a name!) throttle/stick
combination.
It's committed. Thanks!
Erik
___
Flightgear-devel mailing list
[EMAIL
William Earnest wrote:
Original Message
Subject: Joystick XML for Logitech Extreme 3D Pro
Date: Sun, 29 Feb 2004 00:53:32 +0100
From: Johan Walles [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Hi!
Here's a joystick configuration file for a Logitech Extreme 3D Pro.
It's based on
Mathias Fröhlich wrote:
On Donnerstag, 4. März 2004 11:37, Erik Hofman wrote:
It's committed. Thanks!
Oops, very fast!
It made me realize there was another joystick configuration file that
needed to be committed.
Erik
___
Flightgear-devel mailing
Curtis L. Olson wrote:
There are
maybe two dozen small files, quite a bit of detail. Anyone interested in
taking this and configuring them for our DC-3? If so I'll pass them
along.
This is from about a year ago ... Jim did anything ever come of this?
Would be a cool addition to the FG DC-3.
Jim Wilson wrote:
Actually I did pass those along to someone who was working on a DC3 cockpit at
the time and then later dropped it. If anyone is interested let me know and
I'll send a link. They are pretty good samples. Almost all are 8-bit already.
If you sent them over I'll free some time
Curtis L. Olson wrote:
In Linux isnan() is defined in math.h. Is this a portable function
(errr macro) available to everyone?
I need the following for IRIX:
#include ieeefp.h
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
Curtis L. Olson wrote:
Curtis L. Olson wrote:
I'm flying at 11,000' MSL in the default jsbsim C172. There are two
cloud layers, one below me at 9641' MSL (few) and one above me at
14441 (scattered.) My airspeed indicator is reading about 97 kts.
Winds start with 20kts @ 250 deg ground
Jim Wilson wrote:
What you don't see are all the emergency vehicles and foam off to the left of
this view. I was kind of wondering about the angle...like where or what the
photo was shot from. Pretty colors though, especially compared to Bangor in
February.
It is St. Maarten Princess Juliana
Curtis L. Olson wrote:
Hi Erik,
I'm Flying along at 3500' doing about 115 kias. There's a scattered
cloud layer about 800' below me, however, it is outrunning me in the
same direction I'm going. This amount of cloud movement can't be right,
so I assert there is a bug in the cloud movement
David Megginson wrote:
Erik Hofman wrote:
The clouds are moving in the right direction at the right speed. I've
checked again this today. The problem must be somewhere else.
Are you sure that they're not moving relative to the aircraft, instead
of relative to a fixed point on the ground?
Yes
Curtis L. Olson wrote:
Erik Hofman wrote:
The clouds are moving in the right direction at the right speed. I've
checked again this today. The problem must be somewhere else.
So you are saying that it's normal that the clouds are outrunning my
aircraft They must have been doing at least
Curtis L. Olson wrote:
I'm not disagreeing with you, all I'm saying is that there are times
when the clouds aren't moving correctly. :-)
Next time this happens you might want to check the environment settings.
The lowest wind speed is the reported one, the other layers are
generated by
Roy Vegard Ovesen wrote:
On Fri, 27 Feb 2004 09:39:14 +0100, Roy Vegard Ovesen
[EMAIL PROTECTED] wrote:
I should mention that I am using Cygwin.
I think this is the problem where cygwin was installed together with
XFree86. So far everybody has advised not to install XFree86 on cygwin,
but
Roy Vegard Ovesen wrote:
Basically you would move the texture offsets rather than the surface
itself.
Is this possible with 2D instruments too?
I don't think so. About everybody want the 2D instruments gone ...
Erik
___
Flightgear-devel mailing
Norman Vine wrote:
I don't think so. About everybody want the 2D instruments gone ...
There will always be a place for a 2D instrument panels
For Instructor panels and as the texture for flat 3D panels
No need the 2D panel code for both of them. I'm not sure why you would
advise on using 2d
Norman Vine wrote:
I realize that most on this list are after a 'first person' experience
but this is by no means the only use of a simulator :-)
Almost all of the time I keep the possibility of a full size
professional simulator in the back of my mind. The good thing about
FlightGear is that
David Megginson wrote:
Erik Hofman wrote:
Modified Files:
radar_misc.rgb Log Message:
Add support for a storm blib
Excellent.
As far as I know, civilian airliners carry radar that is capable only of
detecting weather, not small things like aircraft. They also use a
separate radar system
David Megginson wrote:
Erik Hofman wrote:
I know that in Europe they recently added a requirement for collision
detection after two civilian aircraft hit each other when the ATC had
given inappropriate directions.
Is that a requirement for TCAS, or for something else in addition to TCAS
Jorge Van Hemelryck wrote:
On Wed, 25 Feb 2004 22:55:50 +0100
Erik Hofman wrote:
It should also be working with the latest version of FlightGear.
And if they patched FlightGear to support their software they *must*
send you the source at your request (GPL compatibility).
How interesting... I
David Megginson wrote:
Martin Spott wrote:
Great idea - unfortunately 'fgfs' now dies with a segmentation fault
just a split second after the FlightGear window appears (Linux),
Yes, I was using the wrong executable to test it. Give me about an
hour, and I'll revert if I cannot fix the
Melchior FRANZ wrote:
* Martin Spott -- Thursday 26 February 2004 12:45:
I thank you very much for implementing real weather and proxy support.
This is really a great improvement !
I'm quite happy about it, too. It really gives a special feeling to
start from ULLI with the real, actual weather
David Luff wrote:
Umm, I would have thought that that only applies if they redistribute their
patched version of FlightGear.
If they don't redistribute it, then there would be no patch.
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
Martin Spott wrote:
Erik Hofman wrote:
Add an option to define the proxy settings (used by metar data
fetching only at this time). Usage: --proxy=user:[EMAIL PROTECTED]:port
The notation works for me - as long as I don't have to use proxy
authorization. Thanks,
If authentication support
Martin Spott wrote:
Erik Hofman wrote:
If they don't redistribute it, then there would be no patch.
Hello Martin, For the time being, we are going to stick with the 0.9.2
version because it works. The protocol we use is the UDP-based external
FDM. We form the structure NetFDM as defined
Martin Spott wrote:
Frederic BOUVIER wrote:
Martin Spott wrote:
proxy-username ?
When I use libcurl to do that, there is a single field called CURLOPT_PROXYUSERPWD
and the format is 'username:passwd'. You should try that syntax with FG.
Sorry, this does not work, I get a TCP_DENIED on my
Martin Spott wrote:
anyone be so kind to look at the patch and give a suggestion how to
deal/proceed with these changes ?
Just be very persistent, state clearly this patch is needed for AIX
before a new stable release is scheduled.
Erik
___
David Luff wrote:
On 2/24/04 at 8:44 PM Erik Hofman wrote:
I have followed an AI Cessna once but I lost in when it literally flew
through a mountain, so I guess it is distance limited.
Well that's just great, the first person to notice that AI planes fly
though mountains comes from Holland
Joshua W. Keane wrote:
Don't you just hate bugs!?
The problem is that i'm using a precompiled or prebuilt version of
flightgear, v0.9.2 because it is currently the version supported by the
aerosim blockset for matlab/simulink.
It should also be working with the latest version of FlightGear.
And
Durk Talsma wrote:
Hey Folks,
So, I was wondering if a project like this would be interesting for
FlightGear. I was already pleasantly surprised when I discovered AI
airplanes, at a local Dutch airport (EHGG) when demonstrating FlightGear to
a friend last week, so I assume that FlightGear can
Curtis L. Olson wrote:
Martin Spott wrote:
Wouldn't it make sense to put it into a separate thread - similar to
the preloading of scenery chunks ?
Yup, that and making smooth transitions when the weather does change
would be the next two logical steps in the process.
A shorter HTTP time-out
Andy Ross wrote:
Erik Hofman wrote:
Does ffloor exists for Solaris?
Why do we care? Just call floor(), which is in the ANSI C standard.
The extra precision won't hurt anyone, and there is zero performance
difference.
Because I didn't know about floor() (the manpage of floorf didn't report
it's
Curtis L. Olson wrote:
If there aren't any major objections, I can commit these changes. The
performance problems of doing a live www fetch only happen with the live
weather updater is on, so there isn't any difference if you run in
default mode.
Sounds good, implement first, optimize
Jim Wilson wrote:
Dang, those should have been floor not floorf. My bad. Can you fix that Erik?
Done.
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Jon Berndt wrote:
Like I said, this all builds fine under gcc. Can anyone tell me what I need
to do?
Is this for JSBSim standalone, or for FlightGear/JSBSim?
For the later, the entry for borland in SimGear/simgear/compiler.h might
be outdated.
Erik
Curtis L. Olson wrote:
Just in case anyone is scratching their heads over this nonsense commit,
I think I made a procedural mistake on my end ... missed one change in
my commit last night, then had to rechange the file to get it to work
correctly this morning.
:-)
I had been searching for
Martin Spott wrote:
Hello,
it might be useful to add '-lxnet' to the linker command line for
'metar' - at least on Solaris I get a lot of 'undefined symbols' it I
omit that:
Done.
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
David Megginson wrote:
Erik Hofman wrote:
Sounds good, implement first, optimize later.
The standard Unix developer's rules (from memory):
1. Make it work.
2. Make it right.
3. Make it efficient.
I've worked as a consultant on too many projects where people have done
these steps in reverse
Martin Spott wrote:
Martin Spott wrote:
Hello,
it might be useful to add '-lxnet' to the linker command line for
'metar' - at least on Solaris I get a lot of 'undefined symbols' it I
omit that:
the same with 'js_server',
Done, Any others?
;-)
Erik
Pablo J. Rogina wrote:
I'm very interested about the recent discussion regarding the new
capabilities of FG with live weather data.
Please don't stick only to getting the data from the Web. For me, it would
be nice to let FG get the data also from files in the local hard disk as
well (think of
Martin Spott wrote:
I'll include the necessary shared libraries (libjpeg for IRIX and GCC
runtime libraries for Solaris) in a new package unter the same version
number this evening,
IRIX users can also install ifl_eoe.sw.c++
Erik
___
Flightgear-devel
Curtis L. Olson wrote:
Curtis L. Olson wrote:
I'll try and check in my changes shortly.
Ok, committed. Now what we *really* need is a mechanism to update
weather condtions as we fly based on the nearest weather station.
First of all, thanks for adding this to the code while I was away,
Curtis L. Olson wrote:
I notice that the cloud layers are moving. At one point it almost
looked like they were keeping up with my Cessna 172, is that intentional
or did a cloud positioning bug creep in?
The clouds already moved along with the wind for a couple of months, but
since we've only
David Megginson wrote:
Erik Hofman wrote:
I notice that the cloud layers are moving. At one point it almost
looked like they were keeping up with my Cessna 172, is that
intentional or did a cloud positioning bug creep in?
The clouds already moved along with the wind for a couple of months
Martin Spott wrote:
Melchior FRANZ [EMAIL PROTECTED] wrote:
That's funny, since truncf has been removed yesterday. Are you talking
about an old version?
Absolutely the same revision and date here. I don't have any idea if
'truncf' and 'floorf' belong together but I can state that the latter
is
Erik Hofman wrote:
Martin Spott wrote:
Absolutely the same revision and date here. I don't have any idea if
'truncf' and 'floorf' belong together but I can state that the latter
is definitely present:
Does ffloor exists for Solaris?
Yuck, Solaris defines truncf but not floorf!
http
Hi,
Thanks to Melchior I and David M. I was able to implement live weather
support in FlightGear today.
For now it can be used by specifying:
--prop:/environment/params/real-world-weather-fetch=true
Erik
___
Flightgear-devel mailing list
[EMAIL
Jim Wilson wrote:
My apologies for not following up sooner. When I later did a make clean it
became an issue for me as well. I cannot tell you why at this point, except
that truncf is a) non-standard and b) in glibc (on redhat). There may be some
header required that isn't there, other than
Curtis L. Olson wrote:
Hi, quick announcement ... baby! Amelia Esther, 8lbs 1oz, born 6:12am
this morning, less than 1 hour from first contraction to delivery. 12
minutes from arrival at the hospital to delivery. Everyone is doing
good. I'll be pretty much offline for a couple days. If I
Arnt Karlsen wrote:
On Mon, 16 Feb 2004 19:57:37 +0100,
Erik Hofman wrote in message
http://www.a1.nl/~ehofman/fgfs/fgfsDList.jpg
I tried to find out what could make this happen, but without any
success so far.
Does anybody have any idea what might go wrong here?
..too much beer
Martin Spott wrote:
Ooops I remember seeing these effects with XFree86/DRI during the
pre-4.3 development phase then hardware-TL was enabled on a Radeon9100
card. Did your experiment at least serve the goal to increase the frame
rate on the O2 ?
It looks like it did increase the framerate.
Norman Vine wrote:
$ cvs diff leaf.cxx
Index: leaf.cxx
===
RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/scene/tgdb/leaf.cxx,v
retrieving revision 1.2
diff -r1.2 leaf.cxx
227c227
sgSetVec2( tmp2, texcoord[0], texcoord[1] );
Richard Bytheway wrote:
There was a comment on the /. discussion on this subject that the examiners have a quota of patents applications to process each week, so there is little incentive to dig too deep. I hope this is not the case, but it might be.
Ok. But since the patent request was filed
Martin Spott wrote:
When you take the 'philosophical' route, I agree - in almost _every_
situation it's a big fault to delete detail/resolution from your raw
data.
On the other hand: 8 kHz, 8 bit is not that bad. German ISDN telephony
has this resolution and to my impression the audible quality
Hi,
After reading that OpenGL would be optimized on IRIX when using display
lists I decided to do some trial runs with FlightGear. Unfortunately the
exact same thing that happened to VBO's (odd colors when using VBO's)
also happens to DList (at least on my O2).
Jon Berndt wrote:
I give up. Sort of.
No need to IMHO. I think we now have an excellent solution.
Could someone file a patent request for this?
There are some gotcha's involved which could mean some other
points/locations should be exposed also in the future, but that's about it.
Erik
Russell Suter wrote:
Of course someone must know this relationship. That doesn't mean they
must be the same point. Someone must not only know the relationship but
also be able to calculate, measure, or WAG a delta x,y,z between these
two frames of reference and put them in the XML wrapper file.
kreuzritter wrote:
Upgrade:
And how to simplify it and integrate it nicly into flightgear so that it is
still fast enough.
I also gave up the idea of limiting the number of wing sections to only 4,
imho this should depend on the type of airplane, so i thought about
a dynamic range of wing
Frederic Bouvier wrote:
I wrote:
could you please add the binary tag to the textures you added in CVS.
Thanks from a windows user
Could someone with CVS write access add the -kb sticky tag to these files :
Thank you very much
I get a permission denied. This has to wait until Curtis fixes
Mally wrote:
You may not be a patent lawyer, but that's a convincing sounding explanation
of
the legal position.
PS. I'm just wondering if you have any thoughts on my earlier question, i.e.
whether what's being patented has to be something non-obvious?
I didn't notice anything not obvious.
They
Andy Ross wrote:
Running it under a separate FDM handler is something that the C++
code just doesn't support yet, though. It's probably not hugely
difficult to make work, though.
Thinking about:
1. inherit the main FDM's moments and forces
2. transpose them to the appropriate location.
3. Use
Norman Vine wrote:
Hmm.. conventional radar usage is perhaps a bit of a stretch but things such
as automated landings use radar verification where being off by half the length
of a 747 could lead to 'interesting' things .. there are other interesting uses for
radar like things too that are
Lee Elliott wrote:
Agreed, a simple 'ballastics' FDM would be a far better solution, but then
someone's got to design code it.
Which reminds me, an FDM (Yasim, UIUC/LaRCsim or JSBSim) could spawn an
AIModel object which has (simple) ballistic trajectory support.
Erik
Jim Wilson wrote:
The _only_ difference between now and what we had before is now the position
may be reported at a fixed location on the aircraft by JSBsim. Before it was
reported at the _current_ center of gravity which varies according to load,
fuel consumption, etc. I'm sorry to be so
Josh Babcock wrote:
Or just have a command that creates an object at a certain point with a
certain velocity vector and orientation.
I think you still need the moments to get a decent traject match.
Erik
Josh
Erik Hofman wrote:
Andy Ross wrote:
Running it under a separate FDM handler
Martin Spott wrote:
Erik Hofman [EMAIL PROTECTED] wrote:
Curtis L. Olson wrote:
The Hawker Hunter has been committed to CVS and seems to fly quite nicely.
For decent hardware. [...]
I was surprized that the frame rate for the Hunter on an Octane is not
that bad. It is obviously better than
kreuzritter wrote:
There was a discussion in August 2003 about
switching from Glut to SDL+OpenGL, what is
the current status about this discussion?
Are any decisions made so far?
The dependencies of GLUT have been removed wherever possible. There are
a few remaining areas but the fact that plib
1101 - 1200 of 2467 matches
Mail list logo
