Martin Spott wrote:
Curtis L. Olson wrote:
Update of /var/cvs/FlightGear-0.9/releases
In directory baron:/tmp/cvs-serv18174
Added Files:
FlightGear-0.9.6.tar.gz
Log Message:
Official source release for v0.9.6
I'm asking just to find out: Do we all agree that it makes much
Martin Spott wrote:
Curtis L. Olson wrote:
Update of /var/cvs/FlightGear-0.9/releases
In directory baron:/tmp/cvs-serv18174
Added Files:
FlightGear-0.9.6.tar.gz
Log Message:
Official source release for v0.9.6
I'm asking just to find out: Do we all agree that it makes much sense
to build
Martin Spott wrote:
Martin Spott wrote:
I'm asking just to find out: Do we all agree that it makes much sense
to build the upcoming binary releases with a crease-patched version
of current PLIB CVS ?
Ahem, for this purpose I'll have put a patched version here within the
next couple of minutes
Martin Spott wrote:
I'm asking just to find out: Do we all agree that it makes much sense
to build the upcoming binary releases with a crease-patched version
of current PLIB CVS ?
Ahem, for this purpose I'll have put a patched version here within the
next couple of minutes that might serve as
Selon Jon Stockill [EMAIL PROTECTED]:
Martin Spott wrote:
Martin Spott wrote:
I'm asking just to find out: Do we all agree that it makes much sense
to build the upcoming binary releases with a crease-patched version
of current PLIB CVS ?
Ahem, for this purpose I'll have put a
Martin Spott wrote:
Curtis L. Olson wrote:
Update of /var/cvs/FlightGear-0.9/releases
In directory baron:/tmp/cvs-serv18174
Added Files:
FlightGear-0.9.6.tar.gz
Log Message:
Official source release for v0.9.6
I'm asking just to find out: Do we all agree that it makes much sense
to build
Martin,
If so, you might want to include some updated 3d models. For example the 737
is still flat shaded and the adf instrument is still ordered in in the wrong
direction in current cvs base package.
I am currently reviewing our models and will provide a patch later this
evening.
Erik Hofman wrote:
Sent: 12 October 2004 18:42
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:releases
FlightGear-0.9.6.tar.gz, NONE,
Martin Spott wrote:
Curtis L. Olson wrote:
Update of /var/cvs/FlightGear-0.9/releases
Vivian Meazza wrote :
Hmmm ... last time I tried Plib cvs (last week) there seemed to be some
problem with joystick axes under Cygwin. I reverted to 1.8.3, no problem.
Lack of time has precluded further investigation.
I already posted on that subject on the plib list but without any response.
The
Frederic Bouvier wrote:
Sent: 12 October 2004 20:36
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] Re:[Flightgear-cvslogs] CVS:releases
FlightGear-0.9.6.tar.gz, NONE,
Vivian Meazza wrote :
Hmmm ... last time I tried Plib cvs (last week) there seemed to be some
Mathias Fr??hlich wrote:
I am currently reviewing our models and will provide a patch later this
evening.
I'd be glad to 'maintain' a temporary PLIB package for FlightGear if
people welcome this effort but I don't want to cross anyone's plans,
Martin.
--
Unix _IS_ user friendly - it's just
Jim Wilson wrote:
Curtis L. Olson said:
Update of /var/cvs/FlightGear-0.9/source/src/Scenery
In directory baron:/tmp/cvs-serv20966/Scenery
Modified Files:
newcache.cxx tileentry.cxx tileentry.hxx tilemgr.cxx
Log Message:
Make a subtle change to tile loading/unloading policy in order to make
Erik Hofman wrote:
+ OpenAL setup for general use (Linux)
+ -
+ As of July 2004 it is best to add at least the following line to your
+ ~/.fgfsrc file on Linux because it wil find out what audio backend to
+ use, starting with the most appropriate:
[...]
Martin Spott wrote:
Erik Hofman wrote:
+ OpenAL setup for general use (Linux)
+ -
+ As of July 2004 it is best to add at least the following line to your
+ ~/.fgfsrc file on Linux because it wil find out what audio backend to
+ use, starting with the most
Curtis L. Olson said:
Update of /var/cvs/FlightGear-0.9/source/src/Scenery
In directory baron:/tmp/cvs-serv20966/Scenery
Modified Files:
newcache.cxx tileentry.cxx tileentry.hxx tilemgr.cxx
Log Message:
Make a subtle change to tile loading/unloading policy in order to make the tile
Curtis L. Olson said:
This situation should never occur in normal operation, but could occur
incontrived situations where an external script was rapidly changing
the simulator position to then be able to query FG terrain height, and
doing this for a large number of points that are
Melchior FRANZ wrote:
* Martin Spott -- Tuesday 17 August 2004 15:28:
I just realized you already calculate the rel. humidity from
temperature and dewpoint. You could calculate the cloud base from these
two numbers and the airport elevation as well - at least our instructor
taught us to
* Martin Spott -- Thursday 19 August 2004 13:16:
Melchior FRANZ wrote:
* Martin Spott -- Tuesday 17 August 2004 15:28:
I just realized you already calculate the rel. humidity from
temperature and dewpoint. You could calculate the cloud base from these
two numbers and the airport
Melchior FRANZ wrote:
* Martin Spott -- Thursday 19 August 2004 13:16:
Yes, the dew point represents the temperature, when humidity
precipitates. In wet adiabatic conditions, which are likely to
predominate, temperature decreases 1 degree Celsius per 100 m altitude.
Now you can calculate
Erik Hofman wrote:
Update of /var/cvs/FlightGear-0.9/FlightGear/src/Main
In directory baron:/tmp/cvs-serv21379
Modified Files:
metar_main.cxx
Log Message:
Some code cleanups, and add a number of command line options.
In this context an idea comes to my mind: Would'nt it be useful
* Martin Spott -- Tuesday 17 August 2004 11:09:
In this context an idea comes to my mind: Would'nt it be useful to let
'metar' honour the respective parameters in a ~/.fgfsrc file (proxy
settings for example) in the same the way, 'fgfs' does !?
Useful?yes
Feasible? hmm
This would involve
Melchior FRANZ wrote:
* Martin Spott -- Tuesday 17 August 2004 11:09:
In this context an idea comes to my mind: Would'nt it be useful to let
'metar' honour the respective parameters in a ~/.fgfsrc file (proxy
settings for example) in the same the way, 'fgfs' does !?
Useful?yes
* Martin Spott -- Tuesday 17 August 2004 12:24:
I thought one might encapsulate the respective FG functions into a lib
and link 'metar' against it Just a quick idea - please
disregard.
I've done the environment thing. Works well and doesn't require to mess with
the libs. Also, it's more
Melchior FRANZ wrote:
As far as I've learnt meteo stuff (I have my theoretical test wednesday
morning :-/ CAVOC translates into visibility 10 km (~ 7 miles) or
greater and no clouds below 5000 ft GND. I thought, clear skies is
being abbreviated by SKC,
Sure. Don't be so picky! ;-)
Erik Hofman wrote:
Update of /var/cvs/FlightGear-0.9/FlightGear/src/Main
In directory baron:/tmp/cvs-serv1037
Modified Files:
metar_main.cxx
Log Message:
The next version of the two hourly metar update from Melchior: add proxy handling.
Melchior FRANZ wrote:
* Martin Spott -- Tuesday 17 August 2004 12:24:
vpngw: 12:07:27 ~ bin/metar -v EDLN
INPUT: 2004/08/17 08:50
EDLN 170850Z VRB03KT CAVOK 22/17 Q1008
METAR Report ^
[...]
Sky condition: clear skies
* Martin Spott -- Tuesday 17 August 2004 15:28:
I just realized you already calculate the rel. humidity from
temperature and dewpoint. You could calculate the cloud base from these
two numbers and the airport elevation as well - at least our instructor
taught us to do so in case of of doubt.
Martin Spott wrote:
Erik Hofman wrote:
Update of /var/cvs/FlightGear-0.9/data/Docs/InstallGuide/html
In directory baron:/tmp/cvs-serv7474/InstallGuide/html
Modified Files:
getstartch2.html
Log Message:
Reffer to /usr/locla/share/FlightGear now.
You'd better mail such changes to me or at
Erik Hofman wrote:
Martin Spott wrote:
Erik Hofman wrote:
Update of /var/cvs/FlightGear-0.9/data/Docs/InstallGuide/html
In directory baron:/tmp/cvs-serv7474/InstallGuide/html
Modified Files:
getstartch2.html
Log Message:
Reffer to /usr/locla/share/FlightGear now.
Martin Spott wrote:
BTW, I didn't find your change in the current CVS checout of the base
package. Could you tell me the lines you changed ?
The *base* package? I don't think anything changed there (I searched for
/usr/local/lib in all the documents, and if it didn't show up I didn't
change
Erik Hofman wrote:
Martin Spott wrote:
BTW, I didn't find your change in the current CVS checout of the base
package. Could you tell me the lines you changed ?
The *base* package?
I assume the location of the HTML file you changed is somewhere down in
the base package. Changes in the
Martin Spott writes:
Erik Hofman wrote:
Martin Spott wrote:
BTW, I didn't find your change in the current CVS checout of the base
package. Could you tell me the lines you changed ?
The *base* package?
I assume the location of the HTML file you changed is somewhere down in
the base
Norman Vine wrote:
I think this is the change in question
http://cvs.flightgear.org/cgi-bin/viewcvs/viewcvs.cgi/data/Docs/InstallGuide/html/getstartch2.html.diff?r1=1.3r2=1.4cvsroot=FlightGear-0.9sortby=date
Hey, _this_ is really neat a tool !
Thanks for the link, it enabled me to find the
Erik Hofman wrote:
Modified Files:
options.xml
Log Message:
Remove an obsolete option for airport-id.
Erik, the option require an ICAO id, so I think this is
the right option and find more logical to deprecate
--airport instead.
-Fred
___
Frederic Bouvier wrote:
Erik Hofman wrote:
Modified Files:
options.xml
Log Message:
Remove an obsolete option for airport-id.
Erik, the option require an ICAO id, so I think this is
the right option and find more logical to deprecate
--airport instead.
There should be no difference between
Erik Hofman wrote:
Frederic Bouvier wrote:
Erik Hofman wrote:
Modified Files:
options.xml
Log Message:
Remove an obsolete option for airport-id.
Erik, the option require an ICAO id, so I think this is
the right option and find more logical to deprecate
--airport instead.
Frederic Bouvier wrote:
Remove an obsolete option for airport-id.
Erik, the option require an ICAO id, so I think this is
the right option and find more logical to deprecate
--airport instead.
I'm with Erik on this one. Otherwise, we'd need to change --vor to
--vor-id, --ndb to --ndb-id, etc.
Frederic Bouvier wrote:
It was just a problem of consistency between the name of the option
and what it is really doing and expecting as argument.
I noticed you didn't touch options.cxx yet so both are still valid.
Yep. And I intend to keep it that way for at least a few months more.
--
Searching
David Megginson wrote:
Frederic Bouvier wrote:
Remove an obsolete option for airport-id.
Erik, the option require an ICAO id, so I think this is
the right option and find more logical to deprecate
--airport instead.
I'm with Erik on this one. Otherwise, we'd need to change --vor to
Erik Hofman wrote:
Update of /var/cvs/FlightGear-0.9/data/Docs/InstallGuide/html
In directory baron:/tmp/cvs-serv7474/InstallGuide/html
Modified Files:
getstartch2.html
Log Message:
Reffer to /usr/locla/share/FlightGear now.
You'd better mail such changes to me or at least post
Arnt Karlsen said:
On Fri, 23 Jul 2004 16:00:08 +0100, Al wrote in message
[EMAIL PROTECTED]:
On Friday 23 July 2004 15:23, Jim Wilson wrote:
Sure enough, it's right there in Stroustrup. The strange part is
never having noticed this before now. What is it with these
On Mon, 26 Jul 2004 18:35:47 -, Jim wrote in message
[EMAIL PROTECTED]:
Arnt Karlsen said:
On Fri, 23 Jul 2004 16:00:08 +0100, Al wrote in message
[EMAIL PROTECTED]:
On Friday 23 July 2004 15:23, Jim Wilson wrote:
Sure enough, it's right there in Stroustrup. The
On Fri, 23 Jul 2004 16:00:08 +0100, Al wrote in message
[EMAIL PROTECTED]:
On Friday 23 July 2004 15:23, Jim Wilson wrote:
Sure enough, it's right there in Stroustrup. The strange part is
never having noticed this before now. What is it with these
developers at microsoft anyway? ;-)
Bernie Bright said:
Jim Wilson wrote:
globals-get_tile_mgr()-all_queues_empty() and cur_fdm_state-get_inited())
{
^^^
^^^
Same here.
That's a head scratcher. Never would have thought that would compile like
that. Learn something new
Jim Wilson wrote:
Bernie Bright said:
Jim Wilson wrote:
globals-get_tile_mgr()-all_queues_empty() and cur_fdm_state-get_inited())
{
^^^
^^^
Same here.
That's a head scratcher. Never would have thought that would compile like
that. Learn something new everyday.
On Friday 23 July 2004 15:23, Jim Wilson wrote:
Sure enough, it's right there in Stroustrup. The strange part is never
having noticed this before now. What is it with these developers at
microsoft anyway? ;-)
Since when have they had developers?
Cheers,
Al
Erik Hofman wrote:
Update of /var/cvs/FlightGear-0.9/FlightGear/src/Main
In directory baron:/tmp/cvs-serv28544/src/Main
Modified Files:
fg_init.cxx main.cxx
Log Message:
Jim Wilson: This patch prevents FDM execution until intial scenery load
completes making
midair starts in the KSFO area
Frederic Bouvier wrote:
! if (!cur_fdm_state-get_inited() or
fgGetBool(sim/sceneryloaded)) {
^^
Are we silently migrating the code to Pascal ?
This doesn't compile with MSVC.
lol, GREAT :-)
don't know about MSVC++, but how about ios646.h ?
Boris Koenig wrote:
Frederic Bouvier wrote:
! if (!cur_fdm_state-get_inited() or
fgGetBool(sim/sceneryloaded)) {
^^
Are we silently migrating the code to Pascal ?
This doesn't compile with MSVC.
lol, GREAT :-)
don't know
Frederic Bouvier wrote:
Boris Koenig wrote:
Are we silently migrating the code to Pascal ?
This doesn't compile with MSVC.
lol, GREAT :-)
don't know about MSVC++, but how about ios646.h ?
and why not
#define BEGIN {
#define END }
?
:-))
More seriously, does it brings us something we are
Frederic Bouvier said:
Erik Hofman wrote:
Update of /var/cvs/FlightGear-0.9/FlightGear/src/Main
In directory baron:/tmp/cvs-serv28544/src/Main
Modified Files:
fg_init.cxx main.cxx
Log Message:
Jim Wilson: This patch prevents FDM execution until intial scenery load
completes
Jim Wilson wrote:
globals-get_tile_mgr()-all_queues_empty() and cur_fdm_state-get_inited())
{
^^^
^^^
Same here.
That's a head scratcher. Never would have thought that would compile like
that. Learn something new everyday.
C++ provides keyword
Curtis L. Olson wrote:
Update of /var/cvs/FlightGear-0.9/data/Airports
In directory baron:/tmp/cvs-serv21708
Modified Files:
basic.dat.gz runways.dat.gz
Log Message:
Updated airport, runway, taxiway, windsock, beacon, and tower data.
Curt, would you _please_ :-) manually change
Curtis L. Olson wrote:
Update of /var/cvs/FlightGear-0.9/data/Aircraft/737
In directory baron:/tmp/cvs-serv16470/Aircraft/737
Modified Files:
737-set.xml
Log Message:
Property /sim/sound/audible renamed to /sim/sound/pause
Individual aircraft -set.xml files shouldn't set global sound/volume
Andy Ross said:
snip
Also, the
property picker is now non-modal, I presume the modality wasn't an
intentional feature.
It either wasn't an option then or something in pui was broken...can't
remember which. If it works...great! That's probably been the #1 debugging
annoyance, for me
Jim Wilson wrote:
Andy Ross wrote:
Also, the property picker is now non-modal, I presume the modality
wasn't an intentional feature.
It either wasn't an option then or something in pui was
broken...can't remember which. If it works...great! That's
probably been the #1 debugging
Maybe I'm misunderstanding why you are doing this. Lower pitch angle, fast
spinning prop. That doesn't makes sense?
Best,
Jim
Andy Ross said:
Update of /var/cvs/FlightGear-0.9/source/src/FDM/YASim
In directory baron:/tmp/cvs-serv7517
Modified Files:
Propeller.cpp
Log Message:
Jim Wilson wrote:
Maybe I'm misunderstanding why you are doing this. Lower pitch
angle, fast spinning prop. That doesn't makes sense?
Not pitch angle: A lower value of _j0 indicates a low advance ratio,
which increases windmilling speed. This was just a sign bug to the
previous checkin,
Andy Ross said:
Jim Wilson wrote:
Maybe I'm misunderstanding why you are doing this. Lower pitch
angle, fast spinning prop. That doesn't makes sense?
Not pitch angle: A lower value of _j0 indicates a low advance ratio,
which increases windmilling speed. This was just a sign bug to the
Jim Wilson wrote:
Is any of this addressing the low rpm propeller issue discussed last
week? (In other words, should I bother trying to correctly adjust
the p51d prop config yet?)
In theory, yes. I haven't had a whole lot of time to test it yet, but
the slow/windmilling propeller regime
Erik Hofman wrote:
Update of /var/cvs/FlightGear-0.9/FlightGear/docs-mini
In directory baron:/tmp/cvs-serv6438
Added Files:
README.sound
Log Message:
Add an explanation for using Arts.
--- NEW FILE ---
ALSA and Arts
-
This article leads me
Martin Spott wrote:
ALSA and Arts
This article leads me to the assumption that OpenAL at least on Linux
is situated _always_ on top of the ALSA OSS emulation layer and does
not use the ALSA interface directly but I find it hard to believe
Why should I avoid directly using the ALSA layer
* Erik Hofman -- Wednesday 28 April 2004 13:22:
The major problem here is Arts that doesn't play nice with programs that
don't support Arts directly. This problem has annoyed me so much that if
I had to chose an desktop manager it would never be KDE until they
decide to stop using Art
Erik Hofman said:
Martin Spott wrote:
ALSA and Arts
This article leads me to the assumption that OpenAL at least on Linux
is situated _always_ on top of the ALSA OSS emulation layer and does
not use the ALSA interface directly but I find it hard to believe
Why should I avoid
* Melchior FRANZ -- Wednesday 28 April 2004 13:46:
- aRts can use ALSA
- KDE can play sound without aRts (AFAIK; haven't tried)
Oh, I forgot to mention: the main problems with aRts and ALSA seem
to lie in ALSA, at least for some chips (e.g. AC97). This improved
vastly in the latest 2.6.* Linux
Melchior FRANZ wrote:
* Melchior FRANZ -- Wednesday 28 April 2004 13:46:
- aRts can use ALSA
- KDE can play sound without aRts (AFAIK; haven't tried)
Oh, I forgot to mention: the main problems with aRts and ALSA seem
to lie in ALSA, at least for some chips (e.g. AC97). This improved
vastly in
Erik Hofman wrote:
This document is just an explanation on using FlightGear with KDE/Arts
enabled.
Ah, thanks. I didn't realize this,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
* Erik Hofman -- Wednesday 28 April 2004 14:15:
Melchior FRANZ wrote:
Oh, I forgot to mention: the main problems with aRts and ALSA seem
to lie in ALSA, at least for some chips (e.g. AC97). This improved
vastly in the latest 2.6.* Linux kernels.
Sure, the most widely used sound option
Melchior FRANZ wrote:
* Erik Hofman -- Wednesday 28 April 2004 14:15:
Melchior FRANZ wrote:
Oh, I forgot to mention: the main problems with aRts and ALSA seem
to lie in ALSA, at least for some chips (e.g. AC97). This improved
vastly in the latest 2.6.* Linux kernels.
Sure, the most widely used
Jim Wilson wrote:
Is this still true? I'm running KDE and can't remember the last
time artsd got in the way. To be honest though, I don't recall what
changed. Maybe I just turned off most of the stupid sounds in the
kde apps.
My impression was that recent versions of arts and esd released
Erik Hofman said:
Update of /var/cvs/FlightGear-0.9/FlightGear/src/Input
In directory baron:/tmp/cvs-serv26245
Modified Files:
input.cxx input.hxx
Log Message:
Make it possible to define a target-platform tag in the joystick
configuration file. This would make it possible to have
* Jim Wilson -- Tuesday 27 April 2004 15:12:
Erik Hofman said:
Make it possible to define a target-platform tag in the joystick
configuration file. This would make it possible to have different
configuration files for Windows.
Just curious, why is this required?
Because Unix and Windows
Melchior FRANZ wrote:
* Jim Wilson -- Tuesday 27 April 2004 15:12:
Erik Hofman said:
Make it possible to define a tag in the joystick
configuration file. This would make it possible to have different
configuration files for Windows.
Just curious, why is this required?
Because
Jim Wilson wrote:
Erik Hofman checked in:
Make it possible to define a target-platform tag in the joystick
configuration file. This would make it possible to have different
configuration files for Windows. Possible values are: Windows, UNIX
or All. Not specifying the tag equals to 'All'.
* Frederic Bouvier -- Tuesday 27 April 2004 15:49:
Melchior FRANZ wrote:
Because Unix and Windows don't always agree on axis numeration.
In fact, they never agree. axis 2 3 are reverted, and the hat has
different numbering, for the same joystick name.
So we'd need two config files for
On Tue, 27 Apr 2004 06:58:41 -0700
Andy Ross [EMAIL PROTECTED] wrote:
Many/most of the joysticks don't work for windows users. They
download the program, try it, and then complain when the view is
constantly spinning around. One presumes the axis mappings are
simply different between the
Melchior FRANZ wrote:
So we'd need two config files for *every* joystick (with more than
two axes)? That's IMHO not acceptable. I'd rather prefer a mechanism
that makes one and the same config file work for both systems then.
After endless times of no discussion and no solutions I hacked
Erik Hofman wrote:
After endless times of no discussion and no solutions I hacked
something together that works for every situation. Not acceptable
won't do in this case unless I see something show up that is elegant
and that works in every situation.
Agreed. We need to get something
axes as defined in the file.
Richard
-Original Message-
From: Erik Hofman [mailto:[EMAIL PROTECTED]
Sent: 27 April 2004 3:21 pm
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] Re: [Flightgear-cvslogs]CVS:
FlightGear/src/Input input.cxx, 1.43, 1.44 input.hxx, 1.17
* Erik Hofman -- Tuesday 27 April 2004 16:21:
Melchior FRANZ wrote:
So we'd need two config files for *every* joystick (with more than
two axes)? That's IMHO not acceptable.
Not acceptable won't do in this case unless I see something show up
that is elegant and that works in every
On Dienstag, 27. April 2004 16:33, Melchior FRANZ wrote:
* Erik Hofman -- Tuesday 27 April 2004 16:21:
Melchior FRANZ wrote:
So we'd need two config files for *every* joystick (with more than
two axes)? That's IMHO not acceptable.
Not acceptable won't do in this case unless I see
Melchior FRANZ wrote:
* Erik Hofman -- Tuesday 27 April 2004 16:21:
Melchior FRANZ wrote:
So we'd need two config files for *every* joystick (with more than
two axes)? That's IMHO not acceptable.
Not acceptable won't do in this case unless I see something show up
that is elegant and that works
* Erik Hofman -- Tuesday 27 April 2004 16:37:
I bet you can come up with a clever solution where only the platform
specific part are in the actual configuration file and everything else
gets included from a shared file ...
axis unix=2 windows=3
descRudder/desc
binding
* Melchior FRANZ -- Tuesday 27 April 2004 16:49:
* Erik Hofman -- Tuesday 27 April 2004 16:37:
I bet you can come up with a clever solution where only the platform
specific part are in the actual configuration file and everything else
gets included from a shared file ...
axis
Melchior FRANZ wrote:
Whereby unix would be an alias for n and the line could also be
written as
axis n=2 windows=3
This is syntactically cleaner, but the code changes required are
severe. XML Attributes in property files are interpreted only by the
SimGear property parser, they aren't
* Andy Ross -- Tuesday 27 April 2004 17:23:
Melchior FRANZ wrote:
axis n=2 windows=3
This is syntactically cleaner, but the code changes required are
severe. XML Attributes in property files are interpreted only by the
SimGear property parser, they aren't available in the resulting
Melchior FRANZ wrote:
* Andy Ross -- Tuesday 27 April 2004 17:23:
Melchior FRANZ wrote:
axis n=2 windows=3
This is syntactically cleaner, but the code changes required are
severe. XML Attributes in property files are interpreted only by the
SimGear property parser, they aren't available in
* Erik Hofman -- Tuesday 27 April 2004 17:50:
Right now code other than SimGear's property I/O code can access the
attributes. To get this working I need to access them in FlightGear, but
every(?) attribute other than n= is disregarded...
I still don't get it. In props_io.cxx:164ff, why
* Melchior FRANZ -- Tuesday 27 April 2004 18:20:
winval = atts.getValue(n_win);// or windows
[...]
if (winval != -1 current_os == windows)
[...]
... assuming that a non existent attribute returns -1.
It's a string or char* and does of course return 0. :-)
m.
to virtual
axes as defined in the file.
Richard
-Original Message-
From: Erik Hofman [mailto:[EMAIL PROTECTED]
Sent: 27 April 2004 3:21 pm
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] Re: [Flightgear-cvslogs]CVS:
FlightGear/src/Input input.cxx, 1.43
Curtis L. Olson wrote:
I should point out that the reason these were setup as cout was so
that we wouldn't lose all output if someone compiled with the
--without-logging option. Now that our default output is much less
verbose, people are probably not compiling with this option so it's
I should point out that the reason these were setup as cout was so
that we wouldn't lose all output if someone compiled with the
--without-logging option. Now that our default output is much less
verbose, people are probably not compiling with this option so it's
probably not a big deal ...
Curtis L. Olson wrote:
I should point out that the reason these were setup as cout was so
that we wouldn't lose all output if someone compiled with the
--without-logging option. Now that our default output is much less
verbose, people are probably not compiling with this option so it's
Curtis L. Olson wrote:
The other thing to consider is everyone seems to have one more fix
they'd like to get in. If we waited for everyone to be happy, we
literally would never be able to have a release. At some point we have
to draw the line and ship. The 0.9.4 release is simply the
David Megginson said:
Curtis L. Olson wrote:
The other thing to consider is everyone seems to have one more fix
they'd like to get in. If we waited for everyone to be happy, we
literally would never be able to have a release. At some point we have
to draw the line and ship. The
Jim Wilson wrote:
David Megginson said:
I would support a 4-week code freeze before 1.0, however, and I do think
it's just about time for a 1.0.
We're close, maybe next release, but I think we need to get the
subsystem/initialization thing straightened out first. Fred's fix for the
tilemanager
Jim Wilson wrote:
I would support a 4-week code freeze before 1.0, however, and I do think
it's just about time for a 1.0.
We're close, maybe next release, but I think we need to get the
subsystem/initialization thing straightened out first. Fred's fix for the
tilemanager last week
Erik Hofman wrote:
Update of /var/cvs/FlightGear-0.9/data/Aircraft/bo105/Models
In directory baron:/tmp/cvs-serv12689/Models
Modified Files:
bo105.ac bo105.xml
Added Files:
README bo105-1.rgb bo105.nas
Removed Files:
shadow.rgb
Log Message:
Melchior FRANZ:
- add
* Martin Spott -- Friday 26 March 2004 15:37:
Ha, there is a funny effect: Did you ever fly a loop which shadowing
enabled ? When I do this, I see the shadow flipping through the sky -
similar to a meteorite :-)
Whoops ... I'll look into it, but I don't promise a solution. (You aren't
Melchior FRANZ wrote:
* Martin Spott -- Friday 26 March 2004 15:37:
Ha, there is a funny effect: Did you ever fly a loop which shadowing
enabled ? When I do this, I see the shadow flipping through the sky -
similar to a meteorite :-)
Whoops ... I'll look into it, but I don't promise a
201 - 300 of 698 matches
Mail list logo
