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 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 the upcoming binary releases with a crease-patched version of current PLIB CVS ? My Win32 build has it. I test it again and then send it to Curt. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
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 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 the upcoming binary releases with a crease-patched version of current PLIB CVS ? I've tried it on 4 systems now and not run into any problems. It certainly makes sense to me. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: releases
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 that might serve as a reference if people tend to agree :-) ftp://ftp.uni-duisburg.de/FlightGear/Source/plib-20041010-crease.tar.gz Another question related to the recent performance increases - did the dlists patch make it into the final release? -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: releases
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 a reference if people tend to agree :-) ftp://ftp.uni-duisburg.de/FlightGear/Source/plib-20041010-crease.tar.gz Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: releases
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 patched version here within the next couple of minutes that might serve as a reference if people tend to agree :-) ftp://ftp.uni-duisburg.de/FlightGear/Source/plib-20041010-crease.tar.gz Another question related to the recent performance increases - did the dlists patch make it into the final release? Yes, and it is mentionned in the NEWS files -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
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 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 the upcoming binary releases with a crease-patched version of current PLIB CVS ? I will Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: releases
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. Greetings Mathias On Dienstag 12 Oktober 2004 19:14, 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 that might serve as a reference if people tend to agree :-) ftp://ftp.uni-duisburg.de/FlightGear/Source/plib-20041010-crease.tar.gz Martin. -- Mathias Frhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:releases FlightGear-0.9.6.tar.gz, NONE,
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 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 the upcoming binary releases with a crease-patched version of current PLIB CVS ? I will 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. Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
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
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 patch below will cure the joystick problem on Windows :
Index: jsWindows.cxx
===
RCS file: /cvsroot/plib/plib/src/js/jsWindows.cxx,v
retrieving revision 1.5
diff -u -r1.5 jsWindows.cxx
--- jsWindows.cxx21 Sep 2004 11:45:55 -1.5
+++ jsWindows.cxx7 Oct 2004 21:47:48 -
@@ -126,7 +126,7 @@
// X,Y,Z,R,U,V,POV - not necessarily the first n of these.
if ( os-jsCaps.wCaps JOYCAPS_HASPOV )
{
- num_axes = _JS_MAX_AXES ;
+ num_axes = _JS_MAX_AXES_WIN ;
min [ 7 ] = -1.0 ; max [ 7 ] = 1.0 ; // POV Y
min [ 6 ] = -1.0 ; max [ 6 ] = 1.0 ; // POV X
}
-Fred
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re:[Flightgear-cvslogs] CVS:releases FlightGear-0.9.6.tar.gz, NONE,
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
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 patch below will cure the joystick problem on Windows :
Index: jsWindows.cxx
===
RCS file: /cvsroot/plib/plib/src/js/jsWindows.cxx,v
retrieving revision 1.5
diff -u -r1.5 jsWindows.cxx
--- jsWindows.cxx21 Sep 2004 11:45:55 -1.5
+++ jsWindows.cxx7 Oct 2004 21:47:48 -
@@ -126,7 +126,7 @@
// X,Y,Z,R,U,V,POV - not necessarily the first n of these.
if ( os-jsCaps.wCaps JOYCAPS_HASPOV )
{
- num_axes = _JS_MAX_AXES ;
+ num_axes = _JS_MAX_AXES_WIN ;
min [ 7 ] = -1.0 ; max [ 7 ] = 1.0 ; // POV Y
min [ 6 ] = -1.0 ; max [ 6 ] = 1.0 ; // POV X
}
Oh well! Thanks for that, I'll keep it until I have time to work on Cygwin
again.
V.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: releases
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 selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: source/src/Scenery newcache.cxx, 1.3, 1.4 tileentry.cxx, 1.36, 1.37 tileentry.hxx, 1.11, 1.12 tilemgr.cxx, 1.40, 1.41
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 the tile paging system much more robust when position change is very rapid and sporadic. Recall that we must load 3d models in the main render thread because model loading can trigger opengl calls (i.e. with texture loading) and all opengl calls *must* happen in the main render thread. To accomplish this we load the base tile in the pager thread and build a work queue of external models that need to be loaded. We never allow a tile to be paged out of the tile cache until all it's pending model loads are complete. However, when changing position very rapidly, we can quickly create a huge backlog of pending model loads because we are changing positions faster than we can load the associated models for the existing tiles. The end result is that tiles that are long out of range can't be removed because there is still a huge backlog of pending model load requests and memory blows up. This change being committed allows the tile paging system to remove tiles if they are out of range, even when there are pending models to load. The model loading code in the render thread can now check to see if the tile exists and discard any model load request for tiles that no longer exist. This situation should never occur in normal operation, but could occur in contrived 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 distributed across a large area. Is it possible for a legit model load to be lost because the model queue gets ahead of the tiles? I know, it's a dumb question, but I won't have a chance to look myself for a few days anyway. That's a good question. I'm pretty sure that's something I thought through carefully when I wrote the code originally, and there shouldn't be any increased chance of a lost legit load. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/docs-mini README.sound, 1.2,
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: [...] Don't you mean ~/.openalrc ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/docs-mini README.sound, 1.2,
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 appropriate: [...] Don't you mean ~/.openalrc ? Yes, thanks. This is fixed now. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: source/src/Scenery newcache.cxx, 1.3, 1.4 tileentry.cxx, 1.36, 1.37 tileentry.hxx, 1.11, 1.12 tilemgr.cxx, 1.40, 1.41
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 paging system much more robust when position change is very rapid and sporadic. Recall that we must load 3d models in the main render thread because model loading can trigger opengl calls (i.e. with texture loading) and all opengl calls *must* happen in the main render thread. To accomplish this we load the base tile in the pager thread and build a work queue of external models that need to be loaded. We never allow a tile to be paged out of the tile cache until all it's pending model loads are complete. However, when changing position very rapidly, we can quickly create a huge backlog of pending model loads because we are changing positions faster than we can load the associated models for the existing tiles. The end result is that tiles that are long out of range can't be removed because there is still a huge backlog of pending model load requests and memory blows up. This change being committed allows the tile paging system to remove tiles if they are out of range, even when there are pending models to load. The model loading code in the render thread can now check to see if the tile exists and discard any model load request for tiles that no longer exist. This situation should never occur in normal operation, but could occur in contrived 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 distributed across a large area. Is it possible for a legit model load to be lost because the model queue gets ahead of the tiles? I know, it's a dumb question, but I won't have a chance to look myself for a few days anyway. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: source/src/Scenery newcache.cxx, 1.3, 1.4 tileentry.cxx, 1.36, 1.37 tileentry.hxx, 1.11, 1.12 tilemgr.cxx, 1.40, 1.41
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 distributed across a
large area.
Ooh. This issue is exactly the sort of thing why I put these
os.system('sleep 3') calls into my script querying heights for
the Runway Distance Remaining signs. I'll have to rebuild from
CVS and see if I can change these to 1's, or get rid of them
altogether. Cool. Thanks.
-c
--
Chris Metzler [EMAIL PROTECTED]
(remove snip-me. to email)
As a child I understood how to give; I have forgotten this grace since I
have become civilized. - Chief Luther Standing Bear
pgpI4kgJGHYIq.pgp
Description: PGP signature
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
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 do so in case of of doubt.
What? The cloud base from temperature and dewpoint?
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 the height above GND of your cloud base if you
know elevation and the spread (temperature at GND - dewpoint).
And then:
$ ./metar -e `zcat $FG_ROOT/Airports/default.apt.gz|awk '/ LOWW /{print $5}'` -c
LOWW
I agree, this is a bit complicated for the average user ;-))
Maybe it would make more sense to intregrate this logic into FlightGear
in order to make the weather model more realistic,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
* 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 elevation as well
What? The cloud base from temperature and dewpoint?
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 the height above GND of your cloud base if you
know elevation and the spread (temperature at GND - dewpoint).
OK. I read your sentence as: You could calculate the cloud base from
temperature and dewpoint. And you could also calculate the airport
elevation from them ... which would have been quite surprising (and
unbelievable).
And then:
$ ./metar -e `zcat $FG_ROOT/Airports/default.apt.gz|awk '/ LOWW /{print $5}'` -c
LOWW
I agree, this is a bit complicated for the average user ;-))
Maybe it would make more sense to intregrate this logic into FlightGear
in order to make the weather model more realistic,
That's of course done in fgfs!
m.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
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 the height above GND of your cloud base if you know elevation and the spread (temperature at GND - dewpoint). OK. I read your sentence as: You could calculate the cloud base from temperature and dewpoint. And you could also calculate the airport elevation from them ... My sentence has a different meaning: If you know elevation and spread (spread: temperature at airport elevation minus dewpoint), then you can calculate the cloud base, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main metar_main.cxx, 1.2,
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 to let 'metar' honour the respective parameters in a ~/.fgfsrc file (proxy settings for example) in the same the way, 'fgfs' does !? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main metar_main.cxx, 1.2,
* 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 having to find the config file on each supported platform (MICROS~1? eew) and parsing it. Sounds a bit like outside the scope of a little tool that is mainly thought for SGMetar developers. A better and easier solution would probably be to parse the http_proxy environment variable. (That's what other commandline tools like lynx, wget, w3m, ... are doing.) And most MICROS~1 users may not know it, but Windows has environment variables, too. What I would rather like to see is a METAR report dialog in fgfs that would be accessible via menu (or even pop up automatically on startup if the user has requested this per property). And, yes, I know that implementing this would be my job then. :-) m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
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 Feasible? hmm This would involve having to find the config file on each supported platform (MICROS~1? eew) and parsing it. I thought one might encapsulate the respective FG functions into a lib and link 'metar' against it Just a quick idea - please disregard. Another 'metar' thing: 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 ^^^ 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, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
* 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 Unix-like and doesn't require an fgfs config. You know, fgrun notoriously overwrites ~/.fgfsrc ... which I consider a bug, btw. :-] And for the MICROS~1 people: http://www.google.com/search?q=windows+set+environment+variables (These variables don't need to be set in *.BAT files, they can also be set system wide.) 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 ^^^ 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! ;-) I did it that way because this couldn't be translated into reliable fgfs properties anyway. Should it report clouds at 5000 ft then? Or at 1 ft? Or none? But you are right, the report should consider that. I'll fix it. OTOH, that isn't really a problem: $ ./metar -v EDLN Proxy host: 'localhost' Proxy port: '3128' INPUT: 2004/08/17 09:50 EDLN 170950Z 18005KT SCT023 23/16 Q1008 [...] See? No CAVOK! m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
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! ;-) Hey, I'm just trying to practice what I've learnt and I'm happy that I actually _did_ understand it - so please don't disturb me :-))) I did it that way because this couldn't be translated into reliable fgfs properties anyway. Should it report clouds at 5000 ft then? Or at 1 ft? OVC at 5001 ft GND not to make it _too_ easy for the pilot ;-) OTOH, that isn't really a problem: $ ./metar -v EDLN Proxy host: 'localhost' Proxy port: '3128' INPUT: 2004/08/17 09:50 EDLN 170950Z 18005KT SCT023 23/16 Q1008 Booohoo, sniff Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main metar_main.cxx, 1.3,
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. ^^^ :-))) Thanks, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
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 ^^^ [...] I did it that way because this couldn't be translated into reliable fgfs properties anyway. Should it report clouds at 5000 ft then? Or at 1 ft? 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. This raises a question. We usually calculate 100 m per degree celsius (wet adiabatic), today I read a paper and noticed that some people take 122 m per degree (dry adiabatic). I think (natuarally ;-) our assumption comes closer to reality when you're dealing with low hanging clouds. What do you use outside Europe (Germany) ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
* 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.
What? The cloud base from temperature and dewpoint?
And then:
$ ./metar -e `zcat $FG_ROOT/Airports/default.apt.gz|awk '/ LOWW /{print $5}'` -c LOWW
The whole command line will hardly be used by anybody. That's just left over
from plans to integrate SGMetar in fgrun. Now that fgfs has METAR support
built-in it only serves as a demo for how to use SGMetar to assemble a command
line. The report, OTOH, does IMHO not need the METAR station elevation, not
more than it would need the full station name. And that is hardly deducible
from the data set without external information. Don't think too hard about
extensions to the SGMetar test program! :-]
m.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Docs/InstallGuide/html
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 least post them on the devel-list. I thought I did that, didn't I? Erik -- Searching for a 60 to 100 passenger Jetliner? http://www.rekkof.nl/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs]
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. You'd better mail such changes to me or at least post them on the devel-list. I thought I did that, didn't I? At least I didn't realize ;-) BTW, I didn't find your change in the current CVS checout of the base package. Could you tell me the lines you changed ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs]
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 anything). Is the documentation still maintained by someone? Erik -- Searching for a 60 to 100 passenger Jetliner? http://www.rekkof.nl/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs]
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 'docs/'-tree used not to show up on the 'cvslogs' list - at least not _my_ changes Is the documentation still maintained by someone? I try my best - although my time is limited and usuallythe changes in FlightGear, that have substantial effect on the manual, come faster than I manage to follow Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: [Flightgear-cvslogs]
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 package. Changes in the 'docs/'-tree used not to show up on the 'cvslogs' list - at least not _my_ changes 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=Flight Gear-0.9sortby=date This URL should be useful for those tracking changes to the Docs http://cvs.flightgear.org/cgi-bin/viewcvs/viewcvs.cgi/data/Docs/InstallGuide/html/?cvsroot=FlightGear-0.9 HTH Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs]
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 appropriate text passage in the sources, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data options.xml, 1.31, 1.32
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 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data options.xml, 1.31, 1.32
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 specifying --airport-id=KSFO or specifying --airport=KSFO as far as I know. Besides the options hes been marked obsolete for more then a year now. -- Searching for a 60 to 100 passenger Jetliner? http://www.rekkof.nl/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data options.xml, 1.31, 1.32
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. There should be no difference between specifying --airport-id=KSFO or specifying --airport=KSFO as far as I know. Besides the options hes been marked obsolete for more then a year now. One should remain ;-) Indeed, the two options have the same effect, setting /sim/presets/airport-id 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. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data options.xml, 1.31, 1.32
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. for consistency. I think people prefer the shorter options (it's pretty-much implied that it has to be a unique identifier). All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data options.xml, 1.31, 1.32
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 for a 60 to 100 passenger Jetliner? http://www.rekkof.nl/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data options.xml, 1.31, 1.32
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 --vor-id, --ndb to --ndb-id, etc. for consistency. I think people prefer the shorter options (it's pretty-much implied that it has to be a unique identifier). Ok, that's a valid point. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Docs/InstallGuide/html
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 them on the devel-list. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_init.cxx, 1.104, 1.105 main.cxx, 1.171, 1.172
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 developers at microsoft anyway? ;-) Since when have they had developers? ..define developer, the SCO Group claims to have 4000 world wide. ;-) Hehe...well let's see: anyone who ever purchased any of SCO's Compilers/Development Packages (since 1982) plus everyone who ever purchased or downloaded SCO's skunkware CD that with gcc on it. Then add 20% for piracy and that gives you 3981. Close enough :-) Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_init.cxx, 1.104, 1.105 main.cxx, 1.171, 1.172
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 strange part is never having noticed this before now. What is it with these developers at microsoft anyway? ;-) Since when have they had developers? ..define developer, the SCO Group claims to have 4000 world wide. ;-) Hehe...well let's see: anyone who ever purchased any of SCO's Compilers/Development Packages (since 1982) plus everyone who ever purchased or downloaded SCO's skunkware CD that with gcc on it. Then add 20% for piracy and that gives you 3981. Close enough :-) ..aaand, deduct the registered 8,000 or so Groklawyers, we do it for copright law enforcement fun. ;-) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_init.cxx, 1.104, 1.105 main.cxx, 1.171, 1.172
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? ;-) Since when have they had developers? ..define developer, the SCO Group claims to have 4000 world wide. ;-) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_init.cxx, 1.104, 1.105 main.cxx, 1.171, 1.172
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.
C++ provides keyword equivalents to some operators:
and
and_eq =
bitand
bitor |
compl ~
not !
or ||
or_eq |=
xor ^
xor_eq ^=
not_eq !=
However it seems that we should use the traditional operators to prevent
msvc from choking.
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? ;-)
Best,
Jim
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_init.cxx, 1.104, 1.105 main.cxx, 1.171, 1.172
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.
C++ provides keyword equivalents to some operators:
and
and_eq =
bitand
bitor |
compl ~
not !
or ||
or_eq |=
xor ^
xor_eq ^=
not_eq !=
However it seems that we should use the traditional operators to prevent
msvc from choking.
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? ;-)
They don't consider that a variable declared in the initialization part of a for loop
must be seen as local to the loop. So, don't ask them to add new keywords.
They just invent new languages ( C#, J#, ... ) ;-)
I am not using their latest version though, but I am not keen to multiply
programming styles in a single program.
-Fred
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_init.cxx, 1.104, 1.105 main.cxx, 1.171, 1.172
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 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_init.cxx, 1.104, 1.105 main.cxx, 1.171, 1.172
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 possible again.
[...]
! if ( global_multi_loop 0) {
! // first run the flight model each frame until it is intialized
! // then continue running each frame only after initial scenery
load is complete.
! if (!cur_fdm_state-get_inited() or
fgGetBool(sim/sceneryloaded)) {
^^
Are we silently migrating the code to Pascal ?
This doesn't compile with MSVC.
***
*** 1331,1334
--- 1340,1350
// END Tile Manager udpates
+ if (!fgGetBool(sim/sceneryloaded) and
globals-get_tile_mgr()-all_queues_empty() and cur_fdm_state-get_inited())
{
^^^
^^^
Same here.
-Fred
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_init.cxx, 1.104, 1.105 main.cxx, 1.171, 1.172
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
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs]CVS: FlightGear/src/Mainfg_init.cxx, 1.104, 1.105 main.cxx, 1.171, 1.172
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 about MSVC++, but how about ios646.h ?
and why not
#define BEGIN {
#define END }
?
More seriously, does it brings us something we are missing
with || or ?
-Fred
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs]CVS: FlightGear/src/Mainfg_init.cxx, 1.104, 1.105 main.cxx, 1.171, 1.172
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 missing
with || or ?
Well, I guess it probably wasn't noticed - don't worry: I would bet Erik
is going to change the stuff anyway ;-)
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_init.cxx, 1.104, 1.105 main.cxx, 1.171, 1.172
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 making
midair starts in the KSFO area possible again.
[...]
! if ( global_multi_loop 0) {
! // first run the flight model each frame until it is intialized
! // then continue running each frame only after initial scenery
load is complete.
! if (!cur_fdm_state-get_inited() or
fgGetBool(sim/sceneryloaded)) {
^^
Are we silently migrating the code to Pascal ?
This doesn't compile with MSVC.
***
*** 1331,1334
--- 1340,1350
// END Tile Manager udpates
+ if (!fgGetBool(sim/sceneryloaded) and
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. Most of my day job work has been in java
lately...which certainly doesn't allow such englishisms :-)
The only time I ever did any Pascal programming was back in the eighties, for
a this guy I knew with a chain of video stores. He bought some program from a
company that went under and need something fixed.
Sorry about that :-)
Best,
Jim
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_init.cxx, 1.104, 1.105 main.cxx, 1.171, 1.172
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 equivalents to some operators:
and
and_eq =
bitand
bitor |
compl ~
not !
or ||
or_eq |=
xor ^
xor_eq ^=
not_eq !=
However it seems that we should use the traditional operators to prevent
msvc from choking.
Bernie
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Airports basic.dat.gz, 1.5,
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 LFZZ/Chambley in basic.dat and runways.dat to some useful code _before_ the next scenery release ? LFZZ is the default code for all French airfields that are not further specified - which results in multiple entries in Robin's database that are named LFZZ. I've found two possible codes for Chambley Airbase. LCHM according to http://dss.ucar.edu/datasets/ds900.0/data/pre73 and FX01 on http://www.fortunecity.com/marina/harbourside/2145/id28_m.htm Maybe Frederic has a suggestion which one to prefer hello Frederic ;-) I started pointing Robin to the existence of this airfiled in spring 2002 !!! (see ftp://ftp.ihg.uni-duisburg.de/FlightGear/Devel/FX01.apt). Two years have passed since but unfortunately he still refuses to apply a unique code to Chambley which makes this airfield pretty useless in FlightGear :-( Thanks, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/737 737-set.xml, 1.4, 1.5
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 properties for the entire application. Just for the record, this _used_ to be an aircraft feature to turn of aircraft specific audio events Erik Index: 737-set.xml === RCS file: /var/cvs/FlightGear-0.9/data/Aircraft/737/737-set.xml,v retrieving revision 1.4 retrieving revision 1.5 diff -C2 -r1.4 -r1.5 *** a/737-set.xml 20 Mar 2004 16:39:11 - 1.4 --- b/737-set.xml 14 May 2004 15:54:22 - 1.5 *** *** 18,22 sound -audibletrue/audible pathAircraft/737/Sounds/737-sound.xml/path /sound --- 18,21 ___ Flightgear-cvslogs mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-cvslogs 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: source/src/GUI dialog.cxx, 1.12, 1.13 dialog.hxx, 1.4, 1.5 prop_picker.cxx, 1.4, 1.5 prop_picker.hxx, 1.3, 1.4
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 anyway. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: source/src/GUI dialog.cxx, 1.12, 1.13 dialog.hxx, 1.4, 1.5 prop_picker.cxx, 1.4, 1.5 prop_picker.hxx, 1.3, 1.4
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 annoyance, for me anyway. Me too. :) As far as I can tell, plib represents modality via typing only. If the top-level puObject in a stack is a puPopup, then you get a normal non-modal window. If it happens to be a puDialogBox (a subclass of puPopup), then it behaves modally because it gets special-cased by the event propagation code. There is actually no C++ code in the puDialogBox class at all. It exists only to be a distinguishable type for the event handler. This is, IMHO, a questionable design decision; a boolean flag on puPopup* would have been much simpler. As is, I couldn't make modal dialogs draggable without essentially cutting and pasting code. (FWIW, it didn't seem like moving a modal alert dialog was a very important feature, so I didn't.) Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: source/src/FDM/YASim Propeller.cpp, 1.3, 1.4
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: Reverse the sense of manual propellers. Low numbers == fast propeller, silly. Index: Propeller.cpp === RCS file: /var/cvs/FlightGear-0.9/source/src/FDM/YASim/Propeller.cpp,v retrieving revision 1.3 retrieving revision 1.4 diff -C2 -r1.3 -r1.4 *** a/Propeller.cpp 1 May 2004 00:25:56 - 1.3 --- b/Propeller.cpp 1 May 2004 15:18:27 - 1.4 *** *** 63,67 // base value. if (_manual) ! _j0 = _baseJ0 * Math::pow(2, 4*_proppitch - 2); float tipspd = _r*omega; --- 63,67 // base value. if (_manual) ! _j0 = _baseJ0 * Math::pow(2, 2 - 4*_proppitch); float tipspd = _r*omega; ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: source/src/FDM/YASim Propeller.cpp, 1.3, 1.4
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, basically. The core change was to fix manual pitch propellers such that a 0.5 value for the axis input matched the value that was solved for in the configuration. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: source/src/FDM/YASim Propeller.cpp, 1.3, 1.4
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 previous checkin, basically. The core change was to fix manual pitch propellers such that a 0.5 value for the axis input matched the value that was solved for in the configuration. Ah ok. I'll take a look back further. Sometime in the next few days I should be able to do test the changes with the p51d. 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?) I realize the main project is adding turboprop, which is itself very exciting! Thanks, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: source/src/FDM/YASim Propeller.cpp, 1.3, 1.4
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 should be sane now. It would be nice to add stuff like a windmiling parameter to the configuration, so the user can tune it, but the ridiculous torques produces should be fixed. I honestly haven't had time to actually fly this thing yet. I wrote a little program to generate graphs of torque vs. RPM, which looked good though. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/docs-mini README.sound, NONE,
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 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 with OpenAL ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/docs-mini README.sound, NONE,
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 with OpenAL ? This has nothing to do with OpenAL. This article was already written before Curtis started implementing it. 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 completely. This document is just an explanation on using FlightGear with KDE/Arts enabled. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/docs-mini README.sound, NONE,
* 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 completely. aRts is really not such a great thing. It started as a software synthesizer and (because there was no sound daemon at that time) was then enhanced with a DE interface. KDE 4 will use one of NMM, MAS, gstreamer. (Not decided yet.) Still, fgfs (and every other sound related application) works very well for me under KDE. And: - aRts can use ALSA - KDE can play sound without aRts (AFAIK; haven't tried) m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/docs-mini README.sound, NONE,
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 directly using the ALSA layer with OpenAL ? This has nothing to do with OpenAL. This article was already written before Curtis started implementing it. 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 completely. This document is just an explanation on using FlightGear with KDE/Arts enabled. 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. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/docs-mini README.sound, NONE,
* 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 kernels. m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/docs-mini README.sound, NONE,
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 the latest 2.6.* Linux kernels. Sure, the most widely used sound option doesn't work correct. That makes sense. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs]
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 ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/docs-mini README.sound, NONE,
* 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 doesn't work correct. That makes sense. I may of course be wrong. But this was the impression I got from reading the Linux kernel mailing list (lkml), the kde-core, kde-devel, and kde-amarok (sound development) lists, and from regularly updating to the latest ALSA (now as part of the kernel; separately before) and at least once every week to the latest version of aRts. :-P m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/docs-mini README.sound, NONE,
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 sound option doesn't work correct. That makes sense. I may of course be wrong. But this was the impression I got from reading the Linux kernel mailing list (lkml), the kde-core, kde-devel, and kde-amarok (sound development) lists, and from regularly updating to the latest ALSA (now as part of the kernel; separately before) and at least once every week to the latest version of aRts. :-P Ah well, lest be positive. It's a good thing that ALSA has evolved an a feature rich GPL'ed sound system for Linux that (almost) supports a large number of sound cards from different vendors. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/docs-mini README.sound, NONE,
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 the sound device after a timeout if nothing was being played, so that (statistically, at least) applications that need exclusive access will see an open device. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Input input.cxx, 1.43, 1.44 input.hxx, 1.17, 1.18
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 different configuration files for Windows. Possible values are: Windows, UNIX or All. Not specifying the tag equals to 'All'. Just curious, why is this required? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Input input.cxx, 1.43, 1.44 input.hxx, 1.17, 1.18
* 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 don't always agree on axis numeration. m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Input input.cxx, 1.43, 1.44 input.hxx, 1.17, 1.18
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 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. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Input input.cxx, 1.43, 1.44 input.hxx, 1.17, 1.18
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'. Just curious, why is this required? Someone hasn't been hanging out on the IRC server. :) 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 platforms, but us Linux folks are more or less helpless to handle these cases. There are similar complaints on the avsim.com forum too. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Input input.cxx, 1.43, 1.44 input.hxx, 1.17, 1.18
* 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 *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. m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Input input.cxx, 1.43, 1.44 input.hxx, 1.17, 1.18
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 platforms, but us Linux folks are more or less helpless to handle these cases. There are similar complaints on the avsim.com forum too. Andy With the AvSim forum, the FlightGear mailing lists, and other forums that have seen wider discussions of FlightGear and its consituent programs, I think FAQs take on a whole new importance. I'm getting ready to field one for JSBSim, too. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Input input.cxx, 1.43, 1.44 input.hxx, 1.17, 1.18
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 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. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Input input.cxx, 1.43, 1.44 input.hxx, 1.17, 1.18
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 actually works in windows put together pronto. We can go back after the fact and make the solution more elegant, but right now novice windows users just think we're broken. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re: [Flightgear-cvslogs]CVS: FlightGear/src/Input input.cxx, 1.43, 1.44 input.hxx, 1.17, 1.18
Could the joystick file have a section which defines virtual named axes (pitch, roll, yaw, throttle, hat_x, hat_y etc) which are mapped to the appropriate FG input (elevator, aileron, rudder, throttle, view x and view y), and then have a section for each OS which maps axis numbers 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, 1.44 input.hxx, 1.17, 1.18 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 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. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel __ __ This e-mail has been scanned for all viruses by Star Internet. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk __ __ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Input input.cxx, 1.43, 1.44 input.hxx, 1.17, 1.18
* 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 situation. I meant not acceptable as in I won't maintain two versions of my Cyborg-Gold-3d-USB joystick config. I don't care otherwise. m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Input input.cxx, 1.43, 1.44 input.hxx, 1.17, 1.18
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 something show up that is elegant and that works in every situation. I meant not acceptable as in I won't maintain two versions of my Cyborg-Gold-3d-USB joystick config. I don't care otherwise. Me too for the Thrustmaster one ... Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Input input.cxx, 1.43, 1.44 input.hxx, 1.17, 1.18
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 in every situation. I meant not acceptable as in I won't maintain two versions of my Cyborg-Gold-3d-USB joystick config. I don't care otherwise. 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 ... Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Input input.cxx, 1.43, 1.44 input.hxx, 1.17, 1.18
* 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 commandproperty-scale/command property/controls/flight/rudder/property offset type=double0.0/offset factor type=double1.0/factor power type=double2.0/power /binding /axis m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Input input.cxx, 1.43, 1.44 input.hxx, 1.17, 1.18
* 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 unix=2 windows=3 Whereby unix would be an alias for n and the line could also be written as axis n=2 windows=3 No need for shared files. m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Input input.cxx, 1.43, 1.44 input.hxx, 1.17, 1.18
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 available in the resulting property tree. Again, let's solve the problem right now so we don't lose new users, then figure out how to handle it cleanly later on. Maybe it will turn out that a standard axis swap will work for all or most joysticks. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Input input.cxx, 1.43, 1.44 input.hxx, 1.17, 1.18
* 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 property tree. They don't need to be in the property tree: if there is a windows attribute and fgfs is running on Windows, then don't store the axis definition for axis 2 but for axis 3 *while parsing*. Why would we want to access this information later on? (Do I misunderstand something? I admit that I don't understand all the XML parser implications.) m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Input input.cxx, 1.43, 1.44 input.hxx, 1.17, 1.18
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 the resulting property tree. They don't need to be in the property tree: if there is a windows attribute and fgfs is running on Windows, then don't store the axis definition for axis 2 but for axis 3 *while parsing*. Why would we want to access this information later on? (Do I misunderstand something? I admit that I don't understand all the XML parser implications.) 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... Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Input input.cxx, 1.43, 1.44 input.hxx, 1.17, 1.18
* 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 can't we say there
something like:
attval = atts.getValue(n);
winval = atts.getValue(n_win);// or windows
int index = 0;
if (attval != 0) {
if (winval != -1 current_os == windows)
index = atoi(winval);
else
index = atoi(attval);
st.counters[name] = SG_MAX2(st.counters[name], index+1);
} else {
index = st.counters[name];
st.counters[name]++;
}
... assuming that a non existent attribute returns -1.
m.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Input input.cxx, 1.43, 1.44 input.hxx, 1.17, 1.18
* 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. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs]CVS: FlightGear/src/Input input.cxx, 1.43, 1.44 input.hxx, 1.17, 1.18
Is all this required? Surely the axes mapping difference is consistant. So that all the would be required is to apply the appropraite mapping at compile time. I don't think there is a need to have glorified or different config files for joysticks. On Tuesday 27 April 2004 15:32, Richard Bytheway wrote: Could the joystick file have a section which defines virtual named axes (pitch, roll, yaw, throttle, hat_x, hat_y etc) which are mapped to the appropriate FG input (elevator, aileron, rudder, throttle, view x and view y), and then have a section for each OS which maps axis numbers 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, 1.44 input.hxx, 1.17, 1.18 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 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. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel __ __ This e-mail has been scanned for all viruses by Star Internet. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk __ __ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main main.cxx, 1.151, 1.152 options.cxx, 1.52, 1.53
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 probably not a big deal ... but that was the reason we used cout's here. Ah, you're right. I forgot about that. And I believe I was the one who proposed that in the first place ... Hmm, maybe we should add a SG_ALWAYS next to SG_ALERT et all and remove the --without-loggin option completely? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main main.cxx, 1.151, 1.152 options.cxx, 1.52, 1.53
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 ... but that was the reason we used cout's here.
Curt.
Erik Hofman wrote:
Update of /var/cvs/FlightGear-0.9/FlightGear/src/Main
In directory baron:/tmp/cvs-serv29723
Modified Files:
main.cxx options.cxx
Log Message:
Frederic Bouvier:
trying the --show-aircraft option, I noticed that I had
no output. This is because there are still output to
cout or cerr, that are not triggering my console patch
for windows. The patch attached use SG_LOG instead.
A request to hit a key is also added because otherwise,
the console window will disappear as soon as the program
stop.
This problem is minor though given the fact that fgfs.exe
is shipped with fgrun that do show the available aircraft
in a much nicer manner.
Index: main.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Main/main.cxx,v
retrieving revision 1.151
retrieving revision 1.152
diff -C2 -r1.151 -r1.152
*** a/main.cxx 19 Mar 2004 03:30:18 - 1.151
--- b/main.cxx 30 Mar 2004 09:05:05 - 1.152
***
*** 1511,1518
// tell the operator how to use this application
! cerr endl Base package check failed ... \
Found version base_version at: \
! globals-get_fg_root() endl;
! cerr Please upgrade to version: required_version endl;
exit(-1);
}
--- 1511,1522
// tell the operator how to use this application
! SG_LOG( SG_GENERAL, SG_ALERT, endl Base package check failed ... \
Found version base_version at: \
! globals-get_fg_root() );
! SG_LOG( SG_GENERAL, SG_ALERT, Please upgrade to version: required_version );
! #ifdef _MSC_VER
! SG_LOG( SG_GENERAL, SG_ALERT, Hit a key to continue... );
! cin.get();
! #endif
exit(-1);
}
Index: options.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Main/options.cxx,v
retrieving revision 1.52
retrieving revision 1.53
diff -C2 -r1.52 -r1.53
*** a/options.cxx 26 Feb 2004 12:57:38 - 1.52
--- b/options.cxx 30 Mar 2004 09:05:05 - 1.53
***
*** 1763,1769
sort(aircraft.begin(), aircraft.end());
! cout Available aircraft: endl;
for ( unsigned int i = 0; i aircraft.size(); i++ ) {
! cout aircraft[i] endl;
}
}
--- 1763,1773
sort(aircraft.begin(), aircraft.end());
! SG_LOG( SG_GENERAL, SG_ALERT, Available aircraft: );
for ( unsigned int i = 0; i aircraft.size(); i++ ) {
! SG_LOG( SG_GENERAL, SG_ALERT, aircraft[i] );
}
+ #ifdef _MSC_VER
+ SG_LOG( SG_GENERAL, SG_ALERT, Hit a key to continue... );
+ cin.get();
+ #endif
}
___
Flightgear-cvslogs mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-cvslogs
--
Curtis Olson Intelligent Vehicles Lab FlightGear Project
Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED]
Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main main.cxx, 1.151, 1.152 options.cxx, 1.52, 1.53
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
probably not a big deal ... but that was the reason we used cout's here.
Curt.
Ack. I will send a better patch to Erik ASAP. I just need to popup the
console window on Windows because I made it non existent by default.
-Fred
Erik Hofman wrote:
Update of /var/cvs/FlightGear-0.9/FlightGear/src/Main
In directory baron:/tmp/cvs-serv29723
Modified Files:
main.cxx options.cxx
Log Message:
Frederic Bouvier:
trying the --show-aircraft option, I noticed that I had
no output. This is because there are still output to
cout or cerr, that are not triggering my console patch
for windows. The patch attached use SG_LOG instead.
A request to hit a key is also added because otherwise,
the console window will disappear as soon as the program
stop.
This problem is minor though given the fact that fgfs.exe
is shipped with fgrun that do show the available aircraft
in a much nicer manner.
Index: main.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Main/main.cxx,v
retrieving revision 1.151
retrieving revision 1.152
diff -C2 -r1.151 -r1.152
*** a/main.cxx 19 Mar 2004 03:30:18 - 1.151
--- b/main.cxx 30 Mar 2004 09:05:05 - 1.152
***
*** 1511,1518
// tell the operator how to use this application
! cerr endl Base package check failed ... \
Found version base_version at: \
! globals-get_fg_root() endl;
! cerr Please upgrade to version: required_version endl;
exit(-1);
}
--- 1511,1522
// tell the operator how to use this application
! SG_LOG( SG_GENERAL, SG_ALERT, endl Base package check failed ... \
Found version base_version at: \
! globals-get_fg_root() );
! SG_LOG( SG_GENERAL, SG_ALERT, Please upgrade to version: required_version );
! #ifdef _MSC_VER
! SG_LOG( SG_GENERAL, SG_ALERT, Hit a key to continue... );
! cin.get();
! #endif
exit(-1);
}
Index: options.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Main/options.cxx,v
retrieving revision 1.52
retrieving revision 1.53
diff -C2 -r1.52 -r1.53
*** a/options.cxx 26 Feb 2004 12:57:38 - 1.52
--- b/options.cxx 30 Mar 2004 09:05:05 - 1.53
***
*** 1763,1769
sort(aircraft.begin(), aircraft.end());
! cout Available aircraft: endl;
for ( unsigned int i = 0; i aircraft.size(); i++ ) {
! cout aircraft[i] endl;
}
}
--- 1763,1773
sort(aircraft.begin(), aircraft.end());
! SG_LOG( SG_GENERAL, SG_ALERT, Available aircraft: );
for ( unsigned int i = 0; i aircraft.size(); i++ ) {
! SG_LOG( SG_GENERAL, SG_ALERT, aircraft[i] );
}
+ #ifdef _MSC_VER
+ SG_LOG( SG_GENERAL, SG_ALERT, Hit a key to continue... );
+ cin.get();
+ #endif
}
___
Flightgear-cvslogs mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-cvslogs
--
Curtis Olson Intelligent Vehicles Lab FlightGear Project
Twin Cities [EMAIL PROTECTED] [EMAIL PROTECTED]
Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: releases FlightGear-0.9.4.tar.gz, NONE,
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 current state of cvs as of today, so if more people tried the cvs version and made patches along the way, we'd have less surprises on release day. I agree with Curt. There are two basic strategies for releasing: 1. Release rarely, testing every release exhaustively first. 2. Release often, testing every release only lightly. I think that #2 works better for most cases -- many bugs won't show up during testing by the members of the developers' list anyway, so it's best to get the release out into the wild and find the real problems earlier rather than later. I know that some people like the idea of separate development and stable branches, but unless we're dealing with critical core infrastructure like a kernel or Web server, it's hard to motivate people to spend all the extra time to backport bug fixes and OS compability changes to the stable branch: it often ends up that the development branch is more stable than the so-called stable branch anyway, while making twice as much work for the maintainers. 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. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: releases FlightGear-0.9.4.tar.gz, NONE,
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 0.9.4 release is simply the current state of cvs as of today, so if more people tried the cvs version and made patches along the way, we'd have less surprises on release day. I agree with Curt. There are two basic strategies for releasing: 1. Release rarely, testing every release exhaustively first. 2. Release often, testing every release only lightly. I think that #2 works better for most cases -- many bugs won't show up during testing by the members of the developers' list anyway, so it's best to get the release out into the wild and find the real problems earlier rather than later. At one time I think I would have leaned toward #1 but have since become a #2 fan. I was going to say this yesterday, but I also realize that doing #2 often involves quite a time commitment. Would it make sense to run a nightly script for folks that don't run cvs? Or is that just a waste of bandwidth? Maybe binaries are the ticket. How about various team members running nightly build scripts and then uploading the results somewhere? I know that some people like the idea of separate development and stable branches, but unless we're dealing with critical core infrastructure like a kernel or Web server, it's hard to motivate people to spend all the extra time to backport bug fixes and OS compability changes to the stable branch: it often ends up that the development branch is more stable than the so-called stable branch anyway, while making twice as much work for the maintainers. That's right. Maybe some day simgear, but I would think that backporting efforts would be driven by the requirements of the backporters rather than anticipated as a requirement. 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 raised an issue about something that might be missing in the subsystem design. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: releases FlightGear-0.9.4.tar.gz, NONE,
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 last week raised an issue about something that might be missing in the subsystem design. Maybe it's time to start some sort of to-do list with issues that _have_ to be addressed for a 1.0 release. I agree we're close to be able to earn the 1.0 version number. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: releasesFlightGear-0.9.4.tar.gz, NONE,
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 raised an issue about something that might be missing in the subsystem design. I also think we should begin to move to 1.0. About initialization, there is still an issue where --wp and --flight-plan are not working ( read segfaulting ) because they rely on the presence of the Airport/Fixes databases that can only be initilized after the --fg-root option is known. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/bo105/Models README, NONE,
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 strobes, beacons, and nav lights - fix the disappearing shadow problem 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 :-) Martin. BTW: Thanks for the colour (and the choice), a salomonian decision. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/bo105/Models README, NONE,
* 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 supposed to do loopings with unmodified BO105, let alone with a BO105CBS (which the 3D model is). BTW: Thanks for the colour (and the choice), a salomonian decision. Well, there were two votes for yellow, two for olive, and one for violet. Of course, my vote should count more, but then I thought that fgfs' first and only helicopter better not be a military one (given the violent state the world is currently in). But note that I despise pacifism as much as I love peace. :-) I turned the README file into a patch that can be applied: $ patch README # switch to military $ patch -R README # switch back to civilian m. PS: the military one is prettier! :-P ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/bo105/Models README, NONE,
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 solution. (You aren't supposed to do loopings with unmodified BO105, let alone with a BO105CBS (which the 3D model is). BTW: Thanks for the colour (and the choice), a salomonian decision. Well, there were two votes for yellow, two for olive, and one for violet. Of course, my vote should count more, but then I thought that fgfs' first and only helicopter better not be a military one (given the violent state the world is currently in). But note that I despise pacifism as much as I love peace. :-) I turned the README file into a patch that can be applied: $ patch README # switch to military $ patch -R README # switch back to civilian m. PS: the military one is prettier! :-P ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel I vote for some medevac livery. They tend to be attractive an a flashy sort of way, and it gives you the opportunity to add all sorts of neat stuff in the back of the cabin to suck up that extra video memory. I also think that the military BO105s are pretty ugly with the missile sight tacked on over the cockpit and the TOW tubes just kind of bolted onto the side. Josh ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
