Curtis L. Olson wrote:
However, these values are interpolated (and thus overwritten)
constantly. I think these need to be written to the
/environment/config/... tree for all the boundary and aloft layers.
Then when the environment manager reinit() is called these values will
be loaded into
David Megginson wrote:
Yes, it needs to be cleaned up and properly documented. The idea is
that you can have an environment manager that sets the values under
/environment as you fly. The hard-coded manager right now uses the
/environment/config values; I assume (though I haven't checked)
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.
I vote for some sort of simple approach that just warps the values when
ever they change. Once
Curtis L. Olson wrote:
I vote for some sort of simple approach that just warps the values when
ever they change. Once we get the nearest station updating working,
then we could do something slightly nicer by interpolating the old/new
values over time so they change smoothly. Personally I
Curtis L. Olson wrote:
But this assumes that the aircraft is properly initialized at ground
level at the station id location when the properties are set.
You don't have to known anything about the station elevation when you set
pressure-sea-level-inHg, so there's no need for the aircraft to be
On Sunday 22 February 2004 14:38, David Megginson wrote:
Curtis L. Olson wrote:
I vote for some sort of simple approach that just warps the values when
ever they change. Once we get the nearest station updating working,
then we could do something slightly nicer by interpolating the old/new
David Megginson [EMAIL PROTECTED] wrote:
Here's my suggestion: forget about the internal environment manager (disable
it, if possible) and for now, manage the weather entirely though an external
daemon written in Perl, Python, Java, C, C++, PHP, or what-have-you.
On the one hand it's nice
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
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, but
since we've only used
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,
I hope this was not chosen intentionally ;-)
Aircraft/737/Instruments/Textures/eicas background.rgb
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--
Hello,
something is hindering me to compile FlightGear on Solaris. Does anyone
know where I should look for a declaration of this function ? This
simply does not exist on my Solaris:
make[3]: Entering directory `/usr/local/src/FlightGear/src/Cockpit'
if g++ -mcpu=hypersparc -mtune=hypersparc
* Martin Spott -- Sunday 22 February 2004 21:30:
something is hindering me to compile FlightGear on Solaris. Does anyone
know where I should look for a declaration of this function ? This
simply does not exist on my Solaris:
That's funny, since truncf has been removed yesterday. Are you
Erik Hofman wrote:
Indeed, the code reads the metar code at startup only.
Ok, this is useful enough if you want to shoot approaches to a specific
airport.
I had it setup to fetch the data every reset (handy for getting the
right weather when changing airports, but unfortunately at this time
every
Melchior FRANZ [EMAIL PROTECTED] wrote:
That's funny, since truncf has been removed yesterday. Are you talking
about an old version?
$ cvs log -rHEAD panel.cxx|tail -5
revision 1.27
date: 2004/02/20 07:54:26; author: ehofman; state: Exp; lines: +2 -9
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!
Erik Hofman said:
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
I've got code that compiles under many compilers, but Borland C++BuilderX is
telling me something is awry. I have several classes each in the JSBSim
namespace (in fact ALL of our classes are in the JSBSim namespace). I have
one file in which I define a main() that uses some of the classes. I
Jim Wilson wrote:
Dang, those should have been floor not floorf.
worksforme. Thanks for your input,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--
Erik Hofman wrote:
I haven't had any thoughts on how to update the weather while flying
around other than the fact that it might be a good idea to have
hexagonal cloud chunks each representing (a mix of) the reported cloud
base at distant metar stations.
Ok, this was just too tempting to not
Erik Hofman writes:
http://www.dinkumware.com/conform_c.html
Hmm.. that document is not really upto date
at least with respect to MingW32
as there are many changes well over a year old that
correct some of the 'deficiencies' reported
note some of the things reported still hold though
I've added some more funtionality to the GPS module (gps.cxx). I can
define a waypoint as lon and lat values, or I can input the waypoint ID
(this currently only works for airport IDs). Now the distance, bearing and
time to the waypoint is calculated. I can also set the desired course to
fly
On Monday 23 February 2004 00:24, Roy Vegard Ovesen wrote:
I've added some more funtionality to the GPS module (gps.cxx). I can
define a waypoint as lon and lat values, or I can input the waypoint ID
(this currently only works for airport IDs). Now the distance, bearing and
time to the
I am trying to update my autopilot route code to reflect the latest
changes. I read a set of points from a table in a database.
I used to use globals-get_route()-add_waypoint( *wp );
to add the waypoints and then I would activate the autopilot by calling,
On Monday 23 February 2004 00:56, Seamus Thomas Carroll wrote:
I am trying to update my autopilot route code to reflect the latest
changes. I read a set of points from a table in a database.
I used to use globals-get_route()-add_waypoint( *wp );
to add the waypoints and then I would activate
Seamus Thomas Carroll wrote:
I am trying to update my autopilot route code to reflect the latest
changes. I read a set of points from a table in a database.
I used to use globals-get_route()-add_waypoint( *wp );
to add the waypoints and then I would activate the autopilot by calling,
Roy Vegard Ovesen said:
I've added some more funtionality to the GPS module (gps.cxx). I can
define a waypoint as lon and lat values, or I can input the waypoint ID
(this currently only works for airport IDs). Now the distance, bearing and
time to the waypoint is calculated. I can also set
Sorry for the OT message:
Just got http://www.linuxsimulations.org up and running again,
seriously lacking in much at the moment. Hopefully will be better this
time! Especially as I live in a house, much less likely to be moving
soon :).
Many thanks,
Matt
PS Also now back with broadband
David Megginson writes:
Jim Wilson wrote:
I wonder if this could be incorporated (or interfaced) to the current waypoint
management code. And, for the pilots on the list, do some GPS units also
calculate elevations to plug in for VNAV operation, fuel estimation, etc?
Every GPS I've
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?
Why do we care? Just call floor(), which is in the
32 matches
Mail list logo
