Re: [Flightgear-devel] Re: [Autopilot] first post
Martin Spott wrote: Just for the record - I assume he's been asking on the 'wrong' list :-) Hi I have displayed our telemetry data using a friend's flightsim installation. For the communications, we have used the ivy software bus (http://www.tls.cena.fr/products/ivy/). As I don't own a windows box, this solution is not a viable option for me. I have tried to use flightgear, but i could not figure the format of their data from the source code. I have asked for help on their mailing list but got no answer. I gave up for the moment. The only mention of this guy in the archive is here and he got a response : http://baron.flightgear.org/pipermail/flightgear-devel/2003-August/019888.html -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] autoflight
David Culp wrote: Would anyone be interested in an autoflight subsystem that acts as a higher-level controller of the autopilot? If been thinking of making one to avoid lots of nasal code which I've been using to almost, but not quite, model a Boeing autoflight system. What is needed is a way to keep track of the various autoflight modes and to automatically switch from one to another. For instance, switching from level-change to altitude-capture, and from approach mode to autoland mode, to name two examples. The way I want to see scripting end up is that the script controls the workflow, but most of this stuff is done using pain C++ code. That would make it both flexible and fast. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Aircraft directory name changes?
Lee Elliott wrote: The obvious, to me at least, way ahead will be for each aircraft to have it's own custom panels and sound effects, and to this end I just bundled everything that was used by the a/c into the directory until I could improve it. The down-side is that while the a/c is still being developed, as it obviously still is, there will be a degree of duplicated data. I don't want to step on anyones toes here, and I do want to express that in general I really like your aircraft, but I also agree with Melchior here. I've been trying to get the download size of the base package decreased wherever possible (removing alpha layers from textures that don't use them for example, although this also saves texture memory on the video card). And the way your aircraft are bundled right now isn't very effective with regards to base package size. I have been using ISDN to download the base package for a long time and every Mb download size takes another 2 minutes of *payed* telephone costs (even 3 minutes for analog modem users). We can't seriously expect every one on the world to do that because you feel like it. I'm not going to say this has to be changed for the upcoming release, but try to keep that in mind for the next updates. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] animation problem (bo105 shadow)
Lee Elliott wrote: I'm glad someone else mentioned this:) I've noticed the same thing, and depending on which way you're looking, there are distinct 'ridges' or creases in the cloud layers, seemingly as a consequence of the reduced cloud layer radii. Just for the record, the cloud radii hasn't been changed, just the fact that it fades out to the edges. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] autoflight
Erik Hofman wrote David Culp wrote: Would anyone be interested in an autoflight subsystem that acts as a higher-level controller of the autopilot? If been thinking of making one to avoid lots of nasal code which I've been using to almost, but not quite, model a Boeing autoflight system. What is needed is a way to keep track of the various autoflight modes and to automatically switch from one to another. For instance, switching from level-change to altitude-capture, and from approach mode to autoland mode, to name two examples. The way I want to see scripting end up is that the script controls the workflow, but most of this stuff is done using pain C++ code. ^^ That would make it both flexible and fast. Freudian slip? Regards Vivian Meazza ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Engine directory
Jon Berndt wrote: There is an idea being discussed by some that involves a bit of a change with the directory structure. The Engine/ directory in the base package has been used by JSBSim as a storage place for engine configuration files. This allows for aircraft to reuse engines from this one spot. However, the actual value of having that single directory for engines is not being realized. There simply aren't many aircraft that we model (or are likely to model) that use the same engine. Also, the files are miniscule. If an additional search path was added for a location in which to look for engine definition files - say, in the aircraft directory - then that might allow tar files to be made pretty much plug-n-play. All the relevant aircraft files (including 3D models and instrument panels ??) could be tarred up and hosted on the JSBSim web site (for JSBSim aircraft, which are the ones in question at the moment). Are there any good reasons NOT to do this? I can't think of any. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] autoflight
Vivian Meazza wrote: Erik Hofman wrote The way I want to see scripting end up is that the script controls the workflow, but most of this stuff is done using pain C++ code. ^^ That would make it both flexible and fast. Freudian slip? Hehe, that must be it. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Engine directory
On Dienstag, 23. März 2004 05:22, Jon Berndt wrote: There is an idea being discussed by some that involves a bit of a change with the directory structure. The Engine/ directory in the base package has been used by JSBSim as a storage place for engine configuration files. This allows for aircraft to reuse engines from this one spot. However, the actual value of having that single directory for engines is not being realized. There simply aren't many aircraft that we model (or are likely to model) that use the same engine. Also, the files are miniscule. If an additional search path was added for a location in which to look for engine definition files - say, in the aircraft directory - then that might allow tar files to be made pretty much plug-n-play. All the relevant aircraft files (including 3D models and instrument panels ??) could be tarred up and hosted on the JSBSim web site (for JSBSim aircraft, which are the ones in question at the moment). Are there any good reasons NOT to do this? No, I don't think so. Do you plan to *move* all JSBSim aircraft out of flightgear onto the JSBSim web page, or would you just maintaine them as a whole in JSBSim like the aerodynamic tables are maintained now? 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] Engine directory
Are there any good reasons NOT to do this? No, I don't think so. Do you plan to *move* all JSBSim aircraft out of flightgear onto the JSBSim web page, or would you just maintain them as a whole in JSBSim like the aerodynamic tables are maintained now? Mathias It wouldn't be a requirement - to store JSBSim aircraft at the JSBSim web site - I'm not even sure it would really need to be in CVS (I hadn't thought of that part, yet). But, it just seems to make sense that there ought to be a central repository for JSBSim aircraft (and where better than the JSBSim site?), and installation ought to be very simple. It is also envisioned the site/page would provide information on using the aircraft, and perhaps other useful stuff, as well. Dave Culp raised this idea the other day - he already has a hangar here: http://home.comcast.net/~davidculp2/hangar/hangar.html I don't want to interfere with the FlightGear base directory storage, however, there appears to be coming a time when maybe the base package needs to be culled of some aircraft models - at least eventually the number of aircraft modeled will become so large that it's just not feasible or desirable to hold all of them in the base package. I think the hangar approach is a good one. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Engine directory
On Dienstag, 23. März 2004 11:34, Jon Berndt wrote: It wouldn't be a requirement - to store JSBSim aircraft at the JSBSim web site - I'm not even sure it would really need to be in CVS (I hadn't thought of that part, yet). But, it just seems to make sense that there ought to be a central repository for JSBSim aircraft (and where better than the JSBSim site?), and installation ought to be very simple. It is also envisioned the site/page would provide information on using the aircraft, and perhaps other useful stuff, as well. Dave Culp raised this idea the other day - he already has a hangar here: http://home.comcast.net/~davidculp2/hangar/hangar.html I don't want to interfere with the FlightGear base directory storage, however, there appears to be coming a time when maybe the base package needs to be culled of some aircraft models - at least eventually the number of aircraft modeled will become so large that it's just not feasible or desirable to hold all of them in the base package. I think the hangar approach is a good one. I was just asking. I am looking forward to a new hangar tab on the JSBSim web page. ;-) And I might have a candidate for this in the near future ... Models in cvs will be a good idea I think. The are partialy already in JSBSims CVS. At least the aerodynamic tables and the engines are there. Maintaining an aircraft as a whole on one cvs server is better than spreading parts of the configuration over several cvs servers. If we do so, we might think about our current JSBSim directory structure a bit, but that's OT here. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] 0.9.4pre1 configure problem
I've downloaded plib-1.8.1, simgear-0.3.5pre1 and flightgear-0.9.4pre1 and attempted to build on Cygwin. I have a problem with the --with-package=$PATH_TO_PACKAGE options on the Flightgear configure stage. plib was configured --prefix=/home/dave/fgfs_pre/plib simgear was configured --prefix=/home/dave/fgfs_pre/simgear --with-plib=/home/dave/fgfs_pre/plib and seemed to build and install OK. I configured flightgear with the following: CFLAGS=-Wall -O2 CXXFLAGS=-Wall -O2 ./configure --prefix=/home/dave/fgfs_pre/flightgear --with-plib=/home/dave/fgfs_pre/plib --with-simgear=/home/dave/fgfs_pre/simgear Initially It compained about the wrong simgear version, so I removed all traces of SimGear from the normal locations (/usr/local/[include|lib]) and tried again. Now it complains that simgear is not present. Simgear appeared to install correctly: $ ls /home/dave/fgfs_pre/simgear include lib $ ls /home/dave/fgfs_pre/simgear/include/simgear bucket debugio misc route serial sound timing xml compiler.h environment magvar nasal scene sg_inlines.h structure version.h constants.h ephemerismathprops screen sg_traits.hxx threads xgl $ ls /home/dave/fgfs_pre/simgear/lib libsgbucket.a libsgephem.a libsgmath.a libsgprops.a libsgsky.alibsgthreads.a libsgclouds3d.a libsgio.alibsgmisc.a libsgroute.a libsgsound.a libsgtiming.a libsgdebug.alibsgmagvar.alibsgmodel.a libsgscreen.a libsgstructure.a libsgxgl.a libsgenvironment.a libsgmaterial.a libsgnasal.a libsgserial.a libsgtgdb.a libsgxml.a Relevant section of config.log is: configure:9082: checking simgear/version.h usability configure:9094: g++ -c -Wall -O2 -I/usr/local/include conftest.cc 5 conftest.cc:68:29: simgear/version.h: No such file or directory configure:9100: $? = 1 configure: failed program was: | /* confdefs.h. */ | As far as I can see it's not picking up the --with-simgear= option and using it for the check. Am I correct in thinking that it should? It's probably not picking up the plib location either, but my CVS plib is very recent so that's probably not breaking it. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs]
Curtis L. Olson wrote: Please feel free to forward the announcement to freshmeat. I assume someone has to have a user account at freshmeat, the Project Admin for FlightGear on freshmeat is - you guess it - Curt Olson :-) 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] Communication with FlightGear
I have tried to use flightgear, but i could not figure the format of their data from the source code. I have asked for help on their mailing list but got no answer. I gave up for the moment. You can drive FlightGear with external data in NMEA format for instance, either by serial port or by network Please take a look at file README.IO under the source/docs-mini folder. You'll get a complete description of paramters and examples to start FlightGear that way. Hope that helps! Pablo J. Rogina ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs]
Martin Spott wrote: Curtis L. Olson wrote: Please feel free to forward the announcement to freshmeat. I assume someone has to have a user account at freshmeat, the Project Admin for FlightGear on freshmeat is - you guess it - Curt Olson :-) Martin. Hmmm, I haven't touched anything at fresh meat for years, would anyone be willing to take this over? How have recent updates been getting in there? Curt. -- 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
Re: [Flightgear-devel] 0.9.4pre1 configure problem
David Luff wrote:
I've downloaded plib-1.8.1, simgear-0.3.5pre1 and flightgear-0.9.4pre1 and
attempted to build on Cygwin. I have a problem with the
--with-package=$PATH_TO_PACKAGE options on the Flightgear configure stage.
plib was configured --prefix=/home/dave/fgfs_pre/plib
simgear was configured --prefix=/home/dave/fgfs_pre/simgear
--with-plib=/home/dave/fgfs_pre/plib and seemed to build and install OK.
I configured flightgear with the following:
CFLAGS=-Wall -O2 CXXFLAGS=-Wall -O2 ./configure
--prefix=/home/dave/fgfs_pre/flightgear
--with-plib=/home/dave/fgfs_pre/plib
--with-simgear=/home/dave/fgfs_pre/simgear
Initially It compained about the wrong simgear version, so I removed all
traces of SimGear from the normal locations (/usr/local/[include|lib]) and
tried again. Now it complains that simgear is not present. Simgear
appeared to install correctly:
$ ls /home/dave/fgfs_pre/simgear
include lib
$ ls /home/dave/fgfs_pre/simgear/include/simgear
bucket debugio misc route serial sound
timing xml
compiler.h environment magvar nasal scene sg_inlines.h structure
version.h
constants.h ephemerismathprops screen sg_traits.hxx threads
xgl
$ ls /home/dave/fgfs_pre/simgear/lib
libsgbucket.a libsgephem.a libsgmath.a libsgprops.a
libsgsky.alibsgthreads.a
libsgclouds3d.a libsgio.alibsgmisc.a libsgroute.a
libsgsound.a libsgtiming.a
libsgdebug.alibsgmagvar.alibsgmodel.a libsgscreen.a
libsgstructure.a libsgxgl.a
libsgenvironment.a libsgmaterial.a libsgnasal.a libsgserial.a
libsgtgdb.a libsgxml.a
Relevant section of config.log is:
configure:9082: checking simgear/version.h usability
configure:9094: g++ -c -Wall -O2 -I/usr/local/include conftest.cc 5
conftest.cc:68:29: simgear/version.h: No such file or directory
configure:9100: $? = 1
configure: failed program was:
| /* confdefs.h. */
|
As far as I can see it's not picking up the --with-simgear= option and
using it for the check. Am I correct in thinking that it should? It's
probably not picking up the plib location either, but my CVS plib is very
recent so that's probably not breaking it.
Cheers - Dave
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
David,
In line #110 of the FG configure.ac, try changing:
EXTRA_DIRS=/usr/local
to:
EXTRA_DIRS=${EXTRA_DIRS} /usr/local
I will make the change in CVS.
Regards,
Curt.
--
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
Re: [Flightgear-devel] 0.9.4pre1 configure problem
On 3/23/04 at 7:42 AM Curtis L. Olson wrote:
In line #110 of the FG configure.ac, try changing:
EXTRA_DIRS=/usr/local
to:
EXTRA_DIRS=${EXTRA_DIRS} /usr/local
I will make the change in CVS.
Thanks, I completely removed both plib and simgear from the normal location
and tested that, and it works great :-)
However, after removing plib I went back and tested SimGear-0.3.5pre1's
configure, and it appears not to have a --with-plib option at all. IMHO it
would be useful to add this, especially as folk having linking problems
with packages are often advised on the list to install plib and/or simgear
to their own location. The patch below seems to work (most of it is simply
copied from FlightGear's configure.ac).
Cheers - Dave
Index: configure.ac
===
RCS file: /var/cvs/SimGear-0.3/SimGear/configure.ac,v
retrieving revision 1.55
diff -u -r1.55 configure.ac
--- a/configure.ac 22 Mar 2004 19:12:23 - 1.55
+++ b/configure.ac 23 Mar 2004 14:26:28 -
@@ -91,6 +91,14 @@
AC_DEFINE([FG_NDEBUG], 1, [Define for no logging output])
fi
+# specify the plib location
+AC_ARG_WITH(plib, [ --with-plib=PREFIX Specify the prefix path to
plib])
+
+if test x$with_plib != x ; then
+echo plib prefix is $with_plib
+EXTRA_DIRS=${EXTRA_DIRS} $with_plib
+fi
+
# Specify if we want to build with Norman's jpeg image server support.
# This requires libjpeg to be installed and available.
# Default to with_jpeg_server=no
@@ -127,7 +135,7 @@
if test -d /opt/X11R6 ; then
EXTRA_DIR2=/opt/X11R6
fi
-EXTRA_DIRS=$EXTRA_DIR1 $EXTRA_DIR2
+EXTRA_DIRS=${EXTRA_DIRS} $EXTRA_DIR1 $EXTRA_DIR2
;;
esac
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs]
Curtis L. Olson wrote: Hmmm, I haven't touched anything at fresh meat for years, would anyone be willing to take this over? How have recent updates been getting in there? There must be some person 'owning' the account for the FlightGear project page on freshmeat. The last update was for 0.9.2, 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: CH Pro Yoke and Linux 2.6.3
On Mon, 2004-03-22 at 21:42, David Megginson wrote: Melchior FRANZ wrote: Does the js interface output anything (as in $ cat /dev/input/js0)? If yes, then you might be able to fix the problem by simply calibrating ($ jscal /dev/input/js0). Some people are convinced that USB joysticks don't need calibration under Linux, but that's wrong. And some of the sticks are so extremely uncalibrated that they don't do anything useful at all. The buttons don't respond either, and the yoke worked fine under the (patched) 2.4.* kernels. There's definitely a problem, still, with the Linux 2.6.* HID support. David, I just found this which might help : http://bugme.osdl.org/show_bug.cgi?id=2226 I'll try it out when I get home from work. - Simon. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: CH Pro Yoke and Linux 2.6.3
Simon Hollier wrote: I just found this which might help : http://bugme.osdl.org/show_bug.cgi?id=2226 I'll try it out when I get home from work. It works! For anyone not following the link, if I do cat /proc/bus/usb/devices *after* plugging in my CH Yoke and Rudder pedals, they start working (Kernel 2.6.4). They do not work until I enter the command. If I unplug them and plug them in again, I have to rerun the 'cat' command. I'm guessing that the CH devices don't get initialized fully by default, but that they do get initialized as a side-effect of listing the USB devices. It's probably just a missing line in the USB code somewhere. Thanks for the help, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain model holes
On Mon 22. March 2004 19:37, you wrote: Hi all, So I am asking for a way, or technique so as when rendering an object after another, to avoid rendering the part of the object that is vertically (same x,z coords) covered by the previous object, so as to avoid mixing them. Here (http://students.ceid.upatras.gr/~mantesat/render.jpg) is a quick note about the clipping I want to achieve. It is a side view of a rendering of a terrain model, consisting of three datasets. How does FlightGear face similar problems? Thanks in advance Athanasios Mantes FlightGear doesn't face similar problems. Sorry Regards, Madr -- Martin Dressler e-mail: [EMAIL PROTECTED] http://www.musicabona.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] More 0.9.4pre1 feedback
Seems to work fine on Cygwin, apart from the --with-package=PREFIX configuration issues already posted. Nice job everyone. I committed a crucial ATC fix to avoid crashes a couple of hours after the pre-release came out - I'm assuming it will make it into the final release? There are about 7 meg of .xcf files in the model subdirs of the 747 and the p51d. Am I correct in thinking we normally remove these? Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain model holes
Martin Dressler wrote: On Mon 22. March 2004 19:37, you wrote: So I am asking for a way, or technique so as when rendering an object after another, to avoid rendering the part of the object that is vertically (same x,z coords) covered by the previous object, so as to avoid mixing them. Here (http://students.ceid.upatras.gr/~mantesat/render.jpg) is a quick note about the clipping I want to achieve. It is a side view of a rendering of a terrain model, consisting of three datasets. How does FlightGear face similar problems? FlightGear doesn't face similar problems. Sorry but there is a resembling situation. As I understand FlightGear _is_ capable of dealing with datasets of different resolutions. The situation is solved by having all data chunks comply with a distinct naming scheme based on the geographical location of each chunk. The a search path for scenery data is set up and when the tile manager requests a new tile he fetches the first one that appears in the search path. Appropriate ordering is achieved by placing the highest resolution chunks into the directory that appears first in the path, 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] More 0.9.4pre1 feedback
On Tue, 23 Mar 2004, David Luff wrote: Seems to work fine on Cygwin, apart from the --with-package=PREFIX configuration issues already posted. Nice job everyone. Yup - it's a flawless build on slackware with: plib 1.8.1 SimGear 0.5.4pre1 FlighGear 0.9.4pre1 I've not had chance to do much testing yet, but first impressions are good. I'll also be including fgrun in the package - is there likely to be a release newer than 0.4.2 in time to include in the packages? -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot fun
Lee Elliott wrote: On Monday 22 March 2004 16:01, Martin Spott wrote: Try this: Choose the YF-23, start FlightGear, set the autopilot for altitude (1000+ ft) and heading in the first step, set speed (some 350 kts) as a second step and watch a wild horse riding through the air :-) The latest YF-23 pending update (note name change from 'yf23') has an auto take-off function in the AP that does pretty much that just by selecting 'TO' mode. Great, the autopilot behaves much calmer than the previous one, although it still starts to oscillate a bit when I exceed 650 kts, 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] More 0.9.4pre1 feedback
Jon Stockill wrote: I'll also be including fgrun in the package - is there likely to be a release newer than 0.4.2 in time to include in the packages? What's wrong with 0.4.2, it's one week old? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More 0.9.4pre1 feedback
Erik Hofman wrote: Jon Stockill wrote: I'll also be including fgrun in the package - is there likely to be a release newer than 0.4.2 in time to include in the packages? What's wrong with 0.4.2, it's one week old? Nothing wrong, it's just that we made a few enhancement, like aircraft alias filtering, display of aircraft name instead of file names, constant aspect ratio, airport list refresh button or small fix in resizing. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain model holes
Martin Spott wrote: Martin Dressler wrote: On Mon 22. March 2004 19:37, you wrote: So I am asking for a way, or technique so as when rendering an object after another, to avoid rendering the part of the object that is vertically (same x,z coords) covered by the previous object, so as to avoid mixing them. Here (http://students.ceid.upatras.gr/~mantesat/render.jpg) is a quick note about the clipping I want to achieve. It is a side view of a rendering of a terrain model, consisting of three datasets. How does FlightGear face similar problems? FlightGear doesn't face similar problems. Sorry but there is a resembling situation. As I understand FlightGear _is_ capable of dealing with datasets of different resolutions. The situation is solved by having all data chunks comply with a distinct naming scheme based on the geographical location of each chunk. The a search path for scenery data is set up and when the tile manager requests a new tile he fetches the first one that appears in the search path. Appropriate ordering is achieved by placing the highest resolution chunks into the directory that appears first in the path, Martin. Does this mean that all datasets are divided in tiles of the same dimension? If that is true, then the resolution of the datasets displayed is a multiple of a pre-agreed quantum. (Forgive me if all that is trivial to flightgear developers, but I'm new to the subject...) N ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More 0.9.4pre1 feedback
Erik Hofman wrote: Frederic BOUVIER wrote: Erik Hofman wrote: Jon Stockill wrote: I'll also be including fgrun in the package - is there likely to be a release newer than 0.4.2 in time to include in the packages? What's wrong with 0.4.2, it's one week old? Nothing wrong, it's just that we made a few enhancement, like aircraft alias filtering, display of aircraft name instead of file names, constant aspect ratio, airport list refresh button or small fix in resizing. And where's 0.4.3? Not for the moment, should ask Bernie. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More 0.9.4pre1 feedback
Frederic BOUVIER wrote: Erik Hofman wrote: And where's 0.4.3? Not for the moment, should ask Bernie. You make it too easy for me... (The aspect ration alone would call for a new release :-) ) Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Terrain model holes
Athanasios Mantes writes: Martin Spott wrote: Martin Dressler wrote: So I am asking for a way, or technique so as when rendering an object after another, to avoid rendering the part of the object that is vertically (same x,z coords) covered by the previous object, so as to avoid mixing them. Here (http://students.ceid.upatras.gr/~mantesat/render.jpg) is a quick note about the clipping I want to achieve. It is a side view of a rendering of a terrain model, consisting of three datasets. How does FlightGear face similar problems? FlightGear doesn't face similar problems. Sorry but there is a resembling situation. As I understand FlightGear _is_ capable of dealing with datasets of different resolutions. The situation is solved by having all data chunks comply with a distinct naming scheme based on the geographical location of each chunk. The a search path for scenery data is set up and when the tile manager requests a new tile he fetches the first one that appears in the search path. Appropriate ordering is achieved by placing the highest resolution chunks into the directory that appears first in the path, Does this mean that all datasets are divided in tiles of the same dimension? If that is true, then the resolution of the datasets displayed is a multiple of a pre-agreed quantum. (Forgive me if all that is trivial to flightgear developers, but I'm new to the subject...) There is only one data set for the terrain at run time in FGFS Any merging is done off line ahead of time in a preprocessing operation that takes 'days' for the whole world The resultant tiles may be of different size depending exactly where you are but any required edge matching is all done offline ahead of time in the preprocessing step. Run time merging of different datasets is a difficult problem and is currently beyond the scope of the FGFS Terrain engine Good luck Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain model holes
Norman Vine wrote: Athanasios Mantes writes: Martin Spott wrote: Martin Dressler wrote: So I am asking for a way, or technique so as when rendering an object after another, to avoid rendering the part of the object that is vertically (same x,z coords) covered by the previous object, so as to avoid mixing them. Here (http://students.ceid.upatras.gr/~mantesat/render.jpg) is a quick note about the clipping I want to achieve. It is a side view of a rendering of a terrain model, consisting of three datasets. How does FlightGear face similar problems? FlightGear doesn't face similar problems. Sorry but there is a resembling situation. As I understand FlightGear _is_ capable of dealing with datasets of different resolutions. The situation is solved by having all data chunks comply with a distinct naming scheme based on the geographical location of each chunk. The a search path for scenery data is set up and when the tile manager requests a new tile he fetches the first one that appears in the search path. Appropriate ordering is achieved by placing the highest resolution chunks into the directory that appears first in the path, Does this mean that all datasets are divided in tiles of the same dimension? If that is true, then the resolution of the datasets displayed is a multiple of a pre-agreed quantum. (Forgive me if all that is trivial to flightgear developers, but I'm new to the subject...) There is only one data set for the terrain at run time in FGFS Any merging is done off line ahead of time in a preprocessing operation that takes 'days' for the whole world The resultant tiles may be of different size depending exactly where you are but any required edge matching is all done offline ahead of time in the preprocessing step. Run time merging of different datasets is a difficult problem and is currently beyond the scope of the FGFS Terrain engine I'll also chime in that the original poster appeared to be approaching this issue with the assumption that a regular grid of data will be used ... probably assuming some sort of CLOD or ROAM type algorithm. FlightGear as Norman points out preprocesses all the terrain data and chooses the highest resolution data set available for any given tile. It then runs a data reduction algorithm to generate a smaller subset of points that approximate the original set within some error tolerance. The resulting set of points is *not* a regular grid. Instead, the points are concentrated in rougher areas and spread thinner in smoother areas. We triangulate the resulting set of points to produce the surface we render. At the moment we produce and draw only a single level of detail for the entire world. This was a design choice that made a lot of sense at the time we made it, and still makes sense for many reasons today. Don't get me wrong, this approach has it's downsides too, so there is room for debate and differences of opinion on the subject. However, we have done a pretty good job of making this approach work pretty well for our needs. If anyone is disturbed by our approach, they are very welcome to produce an alternate scheme that runs in parallel to the current default scheme. It is no small task though which is why I suspect no one has attempted to do this. And many of the other approaches we could try have their own sets of disadvantages, and often don't scale well to covering the entire world. Regards, Curt. -- 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
Re: [Flightgear-devel] More 0.9.4pre1 feedback
David Luff said: Seems to work fine on Cygwin, apart from the --with-package=PREFIX configuration issues already posted. Nice job everyone. I committed a crucial ATC fix to avoid crashes a couple of hours after the pre-release came out - I'm assuming it will make it into the final release? There are about 7 meg of .xcf files in the model subdirs of the 747 and the p51d. Am I correct in thinking we normally remove these? As the author of those xcf files, I'd agree that's a good question. :-) It would be very nice to be able to store both gimp and blender source files, have them eliminated from the distribution, but right there in cvs. I am not sure how that is best done. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More 0.9.4pre1 feedback
Jim Wilson wrote: As the author of those xcf files, I'd agree that's a good question. :-) It would be very nice to be able to store both gimp and blender source files, have them eliminated from the distribution, but right there in cvs. I am not sure how that is best done. This is exactly the sort of stuff we want to catch in the pre-releases. Should just be a simple addition of --exclude='*.xcf' in the tar command line to make sure these don't get into the next base package. Regards, Curt. -- 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
Re: [Flightgear-devel] Terrain model holes
On Tuesday 23 March 2004 20:24, Curtis L. Olson wrote: We triangulate the resulting set of points to produce the surface we render. At the moment we produce and draw only a single level of detail for the entire world. This was a design choice that made a lot of sense at the time we made it, and still makes sense for many reasons today. Just a question: What kind of reasons were that? Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain model holes
Oliver C. wrote: Just a question: What kind of reasons were that? Simplicity. Stability. CPU usage. Rendering performance. Ease of development and maintenance. Robustness in the face of non-heightmap geometry features (roads, airport cutouts). Texture memory usage (LOD algorithms tend to require unique texturing). The list goes on and on. CLOD algorithms are nifty and elegant. But they ain't easy. They tend to work a lot better as isolated demos than they do as platforms for future development. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain model holes
[EMAIL PROTECTED] wrote: On Tuesday 23 March 2004 20:24, Curtis L. Olson wrote: We triangulate the resulting set of points to produce the surface we render. At the moment we produce and draw only a single level of detail for the entire world. This was a design choice that made a lot of sense at the time we made it, and still makes sense for many reasons today. Just a question: What kind of reasons were that? Primarily, the task of matching a tile of one arbitrary LOD up with it's 8 neighboring tiles, each with their own individual arbitrary LOD's, is a daunting combinatorial task. It may not be obvioius at first glance but if there is even the tiniest rounding error at the join between tiles, this is instantly and *very* annoyingly visible as a crack. There is a long list of ideas you could try to either match the tiles up exactly, or hide the cracks, each has their advantages and disadvantages. But in the end, doing everything with a single consistant LOD was a *lot* easier and we generally get very reasonable performance for normal visibilities in the range 10-20 miles. Curt. -- 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
Re: [Flightgear-devel] Terrain model holes
Andy Ross wrote: Oliver C. wrote: Just a question: What kind of reasons were that? Simplicity. Stability. CPU usage. Rendering performance. Ease of development and maintenance. Robustness in the face of non-heightmap geometry features (roads, airport cutouts). Texture memory usage (LOD algorithms tend to require unique texturing). The list goes on and on. CLOD algorithms are nifty and elegant. But they ain't easy. They tend to work a lot better as isolated demos than they do as platforms for future development. Right, and then try scaling that nifty CLOD demo of a small area to now seamless cover the entire world and allow uninterrupted flights from any point to any point. From what I hear, this is certainly doable, and the major issues can be addressed, but it's a lot of work and no one has yet tackled this in the context of FlightGear. Curt. -- 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
Re: [Flightgear-devel] Re: Aircraft directory name changes?
On Tuesday 23 March 2004 09:20, Erik Hofman wrote: Lee Elliott wrote: The obvious, to me at least, way ahead will be for each aircraft to have it's own custom panels and sound effects, and to this end I just bundled everything that was used by the a/c into the directory until I could improve it. The down-side is that while the a/c is still being developed, as it obviously still is, there will be a degree of duplicated data. I don't want to step on anyones toes here, and I do want to express that in general I really like your aircraft, but I also agree with Melchior here. I've been trying to get the download size of the base package decreased wherever possible (removing alpha layers from textures that don't use them for example, although this also saves texture memory on the video card). And the way your aircraft are bundled right now isn't very effective with regards to base package size. I have been using ISDN to download the base package for a long time and every Mb download size takes another 2 minutes of *payed* telephone costs (even 3 minutes for analog modem users). We can't seriously expect every one on the world to do that because you feel like it. I'm not going to say this has to be changed for the upcoming release, but try to keep that in mind for the next updates. Erik I'll start hosting them on a web-site. Once I've got that organised, of before if you wish, the a/c I've done can be removed from the cvs base package. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Instrument Settings Dialog; Setting the Altimeter
I just squeezed in one little item I thought would be useful for the release, since many aircraft do not have clickable panels. Ctrl-I now pops up an instrument-settings dialog (also available from the menu bar) to change the altimeter setting and adjust the heading indicator. For those of you flying with the live, METAR weather, you've probably noticed that the altimeter is often off by hundreds or sometimes thousands of feet. To fix that, as in real life, you need to do one of two things: 1. Get the altimeter setting from the ATIS and put it into your altimeter -- this is the normal thing to do when you're airborne. 2. Change the altimeter setting until the altimeter reads the correct altitude -- this is the normal thing to do on the ground (but you need to cross-check with the ATIS if available). A big part of flying cross-country in a real plane (below the flight levels) is adjusting the altimeter setting constantly throughout the trip. If you're IFR, ATC will tell you what altimeter setting to use at every handoff (it will be the one that everyone else in your sector is using, based on the largest airport in the sector); if you're VFR, it's up to you to call flight services or local UNICOMs as you fly to keep your altimeter setting up to date. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] autoflight
On Mon, 22 Mar 2004 16:51:00 -0600, David Culp [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: Would anyone be interested in an autoflight subsystem that acts as a higher-level controller of the autopilot? If been thinking of making one to avoid lots of nasal code which I've been using to almost, but not quite, model a Boeing autoflight system. What is needed is a way to keep track of the various autoflight modes and to automatically switch from one to another. For instance, switching from level-change to altitude-capture, and from approach mode to autoland mode, to name two examples. ..another use for this, is for _formation_flight_training_, as in; setup a route, and a formation to fly. Such a system could also take input from, say, AI traffic, an instructor panel, networked FG traffic, or AI flak. /ducks ;-) ..allowing several _different_ types of planes in the formation, will help both training and planning real world formation flight, both for airshows and Oshkosh-arrivals-in-style, as these RL formations often are made up of various similar but different type planes, which may limit manouvering room for the larger formations, who would prefer to avoid a RL scenario causing statements like; Hey, you guy's are running away from us outsiders! Oh, shut up, we're all stalling out over here!. ..it would also help debugging our fdm's, a TwinOtter oughtta move the same, both with JSBSim, yasim and uiuc, with the same ice etc on it. -- ..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] Instrument Settings Dialog; Setting the Altimeter
David Megginson wrote: 1. Get the altimeter setting from the ATIS and put it into your altimeter -- this is the normal thing to do when you're airborne. 2. Change the altimeter setting until the altimeter reads the correct altitude -- this is the normal thing to do on the ground (but you need to cross-check with the ATIS if available). A big part of flying cross-country in a real plane (below the flight levels) is adjusting the altimeter setting constantly throughout the trip. If you're IFR, ATC will tell you what altimeter setting to use at every handoff (it will be the one that everyone else in your sector is using, based on the largest airport in the sector); if you're VFR, it's up to you to call flight services or local UNICOMs as you fly to keep your altimeter setting up to date. David, Your mentioning of this area reminds me of an issue with the altimeter setting. I am told that when you change the setting by 0.1 (i.e. from 29.92 to 30.02) that the altimeter reading should change by about 120 feet. Currently it only changes about 100 feet which is about 20' error per 0.1 inch of hg. A separate, but I think related observation is that if I start out at KDEN with the environment conditions set at 29.92 and the altimeter set at 29.92, the altimeter matches the HUD (true) altitude pretty close (between 5340 and 5350 MSL.) If I then set the environment conditions to 30.12 and set the altimeter also to 30.12, the altimeter reads closer to 5400 which is pretty close to that same 20' error per 0.1 change in pressure. I was showing FG to an FAA guy and a former Air Force instructor and this was one of the first things they spotted. During the demo, the air force instructor (female not that it matters) had an unfortunate complete loss of oil pressure on climb out in the c172, but flew an unpublished back course down to 100' minimums in screaming winds and dropped out of the clouds dead center over the runway right as the engine quit ... Regards, Curt. -- 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
Re: [Flightgear-devel] Instrument Settings Dialog; Setting the Altimeter
David Megginson writes: I just squeezed in one little item I thought would be useful for the release, since many aircraft do not have clickable panels. Ctrl-I now pops up an instrument-settings dialog (also available from the menu bar) to change the altimeter setting and adjust the heading indicator. For those of you flying with the live, METAR weather, you've probably noticed that the altimeter is often off by hundreds or sometimes thousands of feet. To fix that, as in real life, you need to do one of two things: 1. Get the altimeter setting from the ATIS and put it into your altimeter -- this is the normal thing to do when you're airborne. Ack - ATIS isn't giving the altimeter at the moment - I took it out since it was hardwired to 29.92. Is there a property or a function that I can use to get the current value, it would be easy to put in. Also - millibars or inches? Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More 0.9.4pre1 feedback
Curtis L. Olson wrote: This is exactly the sort of stuff we want to catch in the pre-releases. Should just be a simple addition of --exclude='*.xcf' in the tar command line to make sure these don't get into the next base package. Maybe you want to do the same with *.tex ? It won't gain much but it cleans the base package a bit. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: driving FlightGear from an external app
On Sun, 21 Mar 2004 21:22:36 -0500, David Calkins [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: At 09:08 PM 3/21/2004, David Calkins wrote: Can anyone point me in the right direction for some documentation on the relevant protocols for driving FlightGear from an external app? We're involved with UAV control using the PICCOLO autopilot system (www.cloudcaptech.org). .._is_ www.cloudcaptech.org the correct address??? I get nothing (un-known host) on http, dns and whois (NOT FOUND). -- ..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] Instrument Settings Dialog; Setting the Altimeter
On Tue, 23 Mar 2004 20:57:20 +, David Luff [EMAIL PROTECTED] wrote: millibars or inches? Can FG be set up to use millibars/Hecto Pascals for the Altimeter pressure setting and imperial for the rest of the units as we use in the UK? All the best, Matt. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: driving FlightGear from an external app
Arnt Karlsen wrote: .._is_ www.cloudcaptech.org the correct address??? I get nothing ^^^ .com 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] FlightGear 0.9.4pre1 Bug: Ornithoper fails to load
I just downloaded the latest prereleases of FlightGear and SimGear as well as plib-1.8.1. It tried loading the ornithoper, but it fails to load, quitting with a segmentation fault on my linux box (Suse 9.0, amd athlon XP, 2400+, GeForce4 videoboard). Can anybody confirm this? I found this same behavior in last Saturday's cvs version. Cheers, Durk ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear 0.9.4pre1 Bug: Ornithoper fails to load
Durk Talsma wrote: I just downloaded the latest prereleases of FlightGear and SimGear as well as plib-1.8.1. It tried loading the ornithoper, but it fails to load, quitting with a segmentation fault on my linux box (Suse 9.0, amd athlon XP, 2400+, GeForce4 videoboard). Can anybody confirm this? I found this same behavior in last Saturday's cvs version. I think there was a bug that crept in that has now been fixed in cvs (although I haven't had a chance to personally test it yet.) I think I'm going to try for another pre-release tomorrow if I can scrape together enough time. Curt. -- 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
Re: [Flightgear-devel]
David Megginson wrote: I just squeezed in one little item I thought would be useful for the release, since many aircraft do not have clickable panels. Ctrl-I now pops up an instrument-settings dialog (also available from the menu bar) to change the altimeter setting and adjust the heading indicator. For those of you flying with the live, METAR weather, you've probably noticed that the altimeter is often off by hundreds or sometimes thousands of feet. Aaaah, and I wondered where I could find the right button to ajdust the altimeter. In this context it might be nice to have the QNH added to the values that get printed to STDOUT, 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] Instrument Settings Dialog; Setting the Altimeter
David Luff wrote: Ack - ATIS isn't giving the altimeter at the moment - I took it out since it was hardwired to 29.92. Is there a property or a function that I can use to get the current value, it would be easy to put in. Also - millibars or inches? Inches of mercury for North America, please. The property /environment/pressure-sea-level-inhg contains the altimeter setting for the aircraft's current location -- that's not exactly what you want, but until we figure out the best way to interface with the METAR stuff, it will be a good start. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More 0.9.4pre1 feedback
Erik Hofman wrote: Curtis L. Olson wrote: This is exactly the sort of stuff we want to catch in the pre-releases. Should just be a simple addition of --exclude='*.xcf' in the tar command line to make sure these don't get into the next base package. Maybe you want to do the same with *.tex ? It won't gain much but it cleans the base package a bit. Where was the .tex files(s) coming from? Curt. -- 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
Re: [Flightgear-devel] Autopilot fun
Lee Elliott wrote: Ta for pointing out the high-speed oscillation problem - I've got to confess that all the recent AP changes were only tested at relatively low speeds i.e. flying circuits to check take-offs landing. I'll have a look into it. When you're done with that I'll send you my suggestions for auto-landing (despite the fact that I suspect auto-landing to be really boring ;-)) 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] FlightGear 0.9.4pre1 Bug: Ornithoper fails to load
Thanks, I'll give it a try tomorrow. Cheers, Durk On Tuesday 23 March 2004 23:30, Curtis L. Olson wrote: Durk Talsma wrote: I just downloaded the latest prereleases of FlightGear and SimGear as well as plib-1.8.1. It tried loading the ornithoper, but it fails to load, quitting with a segmentation fault on my linux box (Suse 9.0, amd athlon XP, 2400+, GeForce4 videoboard). Can anybody confirm this? I found this same behavior in last Saturday's cvs version. I think there was a bug that crept in that has now been fixed in cvs (although I haven't had a chance to personally test it yet.) I think I'm going to try for another pre-release tomorrow if I can scrape together enough time. Curt. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] 0.9.5pre1: --show-aircraft
Okay I tried testing a few more aircraft, and it appears that --show-aircraft lists a lot more aircraft than are in the current base package. I installed a duplicate copy of the prerelease of the base package, keeping my original CVS distribution. I made sure to use to override the default location of fgroot, using the --fg-root= commandline option. Is this a bug, or just some weirdness of my setup? Cheers, Durk ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Instrument Settings Dialog; Setting the Altimeter
Curtis L. Olson wrote: Your mentioning of this area reminds me of an issue with the altimeter setting. I am told that when you change the setting by 0.1 (i.e. from 29.92 to 30.02) that the altimeter reading should change by about 120 feet. Currently it only changes about 100 feet which is about 20' error per 0.1 inch of hg. All of the pilot training material says 100 ft for every tenth of an inch of Mercury -- I'll check on my altimeter next time I'm at the airport. Here's what the AIP Canada (the official Transport Canada pilot's manual) says: Whether a pilot inadvertently sets an incorrect pressure on the altimeter subscale or sets the correct pressure for one area and then, without altering the setting, flies to an area where the pressure differs, the result is the same -- the zero reference to the altimeter will not be where it should be but will be displaced by an amount proportional to 1000 feet indicated altitude per 1 inch of mercury tha the subscale setting is in error. Both the PPL and IFR written exams have a series of questions on different altimeter-setting scenarios, and both expect 1000 ft per inch of Mercury. The same applies to materials I've read from the U.S. That doesn't mean that they're all right, of course, but it does mean that it's what pilots expect. It is also possible that you might be thinking of density altitude: it changes by approximately 120 ft for every degree Celsius difference from the ISA. A separate, but I think related observation is that if I start out at KDEN with the environment conditions set at 29.92 and the altimeter set at 29.92, the altimeter matches the HUD (true) altitude pretty close (between 5340 and 5350 MSL.) If I then set the environment conditions to 30.12 and set the altimeter also to 30.12, the altimeter reads closer to 5400 which is pretty close to that same 20' error per 0.1 change in pressure. That might be a different problem: a barometric altimeter is sensitive to both pressure and temperature variations. On the ground, the temperature variation is neutralized, since the altimeter-reporting station is subject to the same errors; in the air, it can cause the altimeter to be off by hundreds or even thousands of feet. FlightGear currently assumes that all altimeter settings come from stations at sea level, so I wouldn't be surprised to see errors creep in for higher-elevation stations just from small differences in temperature calculations -- we'll have to find a way to deal with that. I was showing FG to an FAA guy and a former Air Force instructor and this was one of the first things they spotted. During the demo, the air force instructor (female not that it matters) had an unfortunate complete loss of oil pressure on climb out in the c172, but flew an unpublished back course down to 100' minimums in screaming winds and dropped out of the clouds dead center over the runway right as the engine quit ... Yes, I have unfortunately accidents like that a lot in FlightGear -- it's good practice. Note that a 50 ft error is (just) within legal tolerance anyway, even for IFR. Still, since it's not deliberate, we need to look into it. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain model holes
On Mon, 22 Mar 2004 20:37:52 +0200, Athanasios Mantes [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: Hi all, I'm an OpenGL developer, currently developing a small terrain model renderer. I'm sending this message to this list, because I think that developers of FlightGera hav come up with similar subjects and can provide me with a working solution. What I want to achieve is to render multiple terrain grids of different resolution that contain common areas without the rendered models to mix because of the different resolutions used. That is similar to cutting rectangular holes to terrain models, without of course preprocessing, splitting, or braking the initial terrain grids into pieces. Let's say I have three rectangular heightfield grids, the one covering the entire North Anerica terrain, with a resolution of 1 km, a grid covering the USA area with a resolution of 500m and a grid covering the area of Nevada state with a resolution of 100m. I want to be able to render those grids together at the same scene, but because of the different resolutions, the heightfields mix in many cases. So the ideal thing (and what I want to achive), is that when rendering those grids, I want to be able somehow to punch a vertical rectangular hole in the correct position and with the size of the USA grid in the North America grid, place the USA grid there, and then put a verical hole in the Nevada area in the USA grid, and place the Nevada grid. Grids are not aligned, so that can't be done by preprocessing grids and cutting the right holes in them. So I am asking for a way, or technique so as when rendering an object after another, to avoid rendering the part of the object that is vertically (same x,z coords) covered by the previous object, so as to avoid mixing them. Here (http://students.ceid.upatras.gr/~mantesat/render.jpg) is a quick note about the clipping I want to achieve. It is a side view of a rendering of a terrain model, consisting of three datasets. ..how about 2 data mix zones 'between' your own 3 data sets? If the offsets are as wild as in your jpg schetch, you may want to weigh the data over the data mix zone width, and make the zone say a mile wide, so it looks reasonable. How does FlightGear face similar problems? ..discussed by the guys in the thread. -- ..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] FlightGear 0.9.4pre1 Bug: Ornithoper fails to load
Curtis L. Olson said: Durk Talsma wrote: I just downloaded the latest prereleases of FlightGear and SimGear as well as plib-1.8.1. It tried loading the ornithoper, but it fails to load, quitting with a segmentation fault on my linux box (Suse 9.0, amd athlon XP, 2400+, GeForce4 videoboard). Can anybody confirm this? I found this same behavior in last Saturday's cvs version. I think there was a bug that crept in that has now been fixed in cvs (although I haven't had a chance to personally test it yet.) I think I'm going to try for another pre-release tomorrow if I can scrape together enough time. I can confirm that it works from cvs now. The problem affects all the LaRCsim/uiuc models. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Instrument Settings Dialog; Setting the Altimeter
Matthew Law writes: On Tue, 23 Mar 2004 20:57:20 +, David Luff [EMAIL PROTECTED] wrote: millibars or inches? Can FG be set up to use millibars/Hecto Pascals for the Altimeter pressure setting and imperial for the rest of the units as we use in the UK? All the best, I'm sure it can, but maybe not for the next release! Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Instrument Settings Dialog; Setting the Altimeter
Matthew Law wrote: Can FG be set up to use millibars/Hecto Pascals for the Altimeter pressure setting and imperial for the rest of the units as we use in the UK? It's a (relatively) simple matter to make instruments calibrated in millibars instead of inches of mercury; localizing dialog boxes will be a bit trickier, though. In general, I think that our policy should be to follow the nationality of the callsign or markings of each aircraft's 3D model: North American aircraft (like the default 172 and my Warrior model) should use inches of mercury; European aircraft should use millibars. If or when we model old Soviet aircraft, we might need to calibrate the airspeed indicators in kilometers per hour and the altimeters in meters as well (I'm not certain). Eventually, then, someone will need to do a repaint of some of the common aircraft with UK markings and a slightly different panel. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Instrument Settings Dialog; Setting the Altimeter
On Tue, 23 Mar 2004 18:07:34 -0500, David Megginson [EMAIL PROTECTED] wrote: It's a (relatively) simple matter to make instruments calibrated in millibars instead of inches of mercury; localizing dialog boxes will be a bit trickier, though. In general, I think that our policy should be to follow the nationality of the callsign or markings of each aircraft's 3D model: North American aircraft (like the default 172 and my Warrior model) should use inches of mercury; European aircraft should use millibars. If or when we model old Soviet aircraft, we might need to calibrate the airspeed indicators in kilometers per hour and the altimeters in meters as well (I'm not certain). Eventually, then, someone will need to do a repaint of some of the common aircraft with UK markings and a slightly different panel. All the best, David It would be nice to eventually be able to map the relevant instruments to any of these units. In the interests of internationalisation, you understand :-) Incidentally, I believe that Eastern block aircraft flown here have to have an altimeter in feet/millibars onboard. All the best, Matt. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Instrument Settings Dialog; Setting the Altimeter
David Megginson writes: David Luff wrote: Ack - ATIS isn't giving the altimeter at the moment - I took it out since it was hardwired to 29.92. Is there a property or a function that I can use to get the current value, it would be easy to put in. Also - millibars or inches? Inches of mercury for North America, please. The property /environment/pressure-sea-level-inhg contains the altimeter setting for the aircraft's current location -- that's not exactly what you want, but until we figure out the best way to interface with the METAR stuff, it will be a good start. That'll do for now - I'll whack it in hopefully before the release. It will of course be pronounced al-tee-meter instead of the al-tim-iter that I imagine the US uses! Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Clouds artefacts
Frederic BOUVIER wrote: I wrote: We can also begin to think about a multi pass method that would : 1. draw the clouds above the viewer without depth update, 2. draw the scene, 3 .redraw the clouds above with depth test Thinking more about it, for the record if someone wants to toy with this : 0. clear the stencil buffer 1. draw the clouds above the viewer without depth update, 2. draw the scene with stencil buffer write enabled ( terrain and objects overwrite all clouds, even those that are between the viewer and the terrain ) 3 .redraw the clouds above with depth test and stencil test to only update terrain that can be obscured by clouds - this should clear the transparency 'drawn twice' problem With an impact on framerate due to double writing and problem like the one Melchior is experiencing with overlapping semi transparent objects. Haven't thought about it much of that. Obviously, this should be optional to accomodate less capable hardware I manage to implement this algorithm tonight. The results are here : 1. /sim/rendering/multi-pass-clouds=false : http://perso.wanadoo.fr/frbouvi/flightsim/fg-multip-off-1.jpg (204kb) 2. /sim/rendering/multi-pass-clouds=true : http://perso.wanadoo.fr/frbouvi/flightsim/fg-multip-on-1.jpg (198kb) 3 /sim/rendering/multi-pass-clouds=true ( billboard tree detail ) : http://perso.wanadoo.fr/frbouvi/flightsim/fg-multip-on-2.jpg (106kb) If you think it's worth being in the release ( being optional thanks to property ), just speak and I will prepare a patch tomorrow evening ( sky.[ch]xx was touched in SimGear, main.cxx in flightgear, preferences.xml in fgfsbase ) Otherwise, I'll hold off until the release is out. Cheers, -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Instrument Settings Dialog; Setting the Altimeter
David Megginson said: I just squeezed in one little item I thought would be useful for the release, since many aircraft do not have clickable panels. Ctrl-I now pops up an instrument-settings dialog (also available from the menu bar) to change the altimeter setting and adjust the heading indicator. Did you notice that there are problems when a menu dialog is up already and you hit Ctrl-R (presumably Ctrl+I too)? It's like the buttons work on the wrong dialog. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot fun
Martin Spott said: Lee Elliott wrote: Ta for pointing out the high-speed oscillation problem - I've got to confess that all the recent AP changes were only tested at relatively low speeds i.e. flying circuits to check take-offs landing. I'll have a look into it. When you're done with that I'll send you my suggestions for auto-landing (despite the fact that I suspect auto-landing to be really boring ;-)) Hehe...well actually it is pretty exciting from an engineering perspective ;-) For the oscillations, it seems that using the PI simple controller setup fixed this issue in the 747...althought I would have to do a lot more testing at various altitudes and mach numbers to be sure that it is indeed fixed. One thing is that in some cases the 747 would climb to altitude and level off at a stable cruise, but things like turbulance and/or entering a command to change altitude would introduce the porpoising. To test for that quickly, I get the aircraft cruising nice and smooth, then pull the stick all the way back for a couple seconds and let it go (this is a joystick so it springs back to neutral). If things are ok the upset aircraft will stabilize in just a few seconds. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Instrument Settings Dialog; Setting the Altimeter
Matthew Law writes: On Tue, 23 Mar 2004 20:57:20 +, David Luff wrote: millibars or inches? Can FG be set up to use millibars/Hecto Pascals for the Altimeter pressure setting and imperial for the rest of the units as we use in the UK? All the best, OK, by special request the ATIS now puts out millibars for the UK, and inches for the rest of the world. Millibars are to 1 decimal place and inches Hg to 2 eg one-zero-one-three-decimal-two and two-niner-decimal-niner-two Is this reasonable? Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More 0.9.4pre1 feedback
On Tue, 23 Mar 2004 19:34:38 +0100 (CET) Frederic BOUVIER [EMAIL PROTECTED] wrote: Erik Hofman wrote: Frederic BOUVIER wrote: Erik Hofman wrote: Jon Stockill wrote: I'll also be including fgrun in the package - is there likely to be a release newer than 0.4.2 in time to include in the packages? What's wrong with 0.4.2, it's one week old? Nothing wrong, it's just that we made a few enhancement, like aircraft alias filtering, display of aircraft name instead of file names, constant aspect ratio, airport list refresh button or small fix in resizing. And where's 0.4.3? Not for the moment, should ask Bernie. Now that you mention it, there have been a lot of updates the past 10 days. I will get 0.4.3 out real soon. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Instrument Settings Dialog; Setting the Altimeter
On Tue, 23 Mar 2004 22:19:52 +, David Luff [EMAIL PROTECTED] wrote: eg one-zero-one-three-decimal-two You can probably drop the decimal point for millibars. This makes UK flying a lot more realistic now. Thanks :-) All the best, Matt ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Clouds artefacts
Frederic Bouvier said: Frederic BOUVIER wrote: I wrote: We can also begin to think about a multi pass method that would : 1. draw the clouds above the viewer without depth update, 2. draw the scene, 3 .redraw the clouds above with depth test Thinking more about it, for the record if someone wants to toy with this : 0. clear the stencil buffer 1. draw the clouds above the viewer without depth update, 2. draw the scene with stencil buffer write enabled ( terrain and objects overwrite all clouds, even those that are between the viewer and the terrain ) 3 .redraw the clouds above with depth test and stencil test to only update terrain that can be obscured by clouds - this should clear the transparency 'drawn twice' problem With an impact on framerate due to double writing and problem like the one Melchior is experiencing with overlapping semi transparent objects. Haven't thought about it much of that. Obviously, this should be optional to accomodate less capable hardware I manage to implement this algorithm tonight. The results are here : 1. /sim/rendering/multi-pass-clouds=false : http://perso.wanadoo.fr/frbouvi/flightsim/fg-multip-off-1.jpg (204kb) 2. /sim/rendering/multi-pass-clouds=true : http://perso.wanadoo.fr/frbouvi/flightsim/fg-multip-on-1.jpg (198kb) 3 /sim/rendering/multi-pass-clouds=true ( billboard tree detail ) : http://perso.wanadoo.fr/frbouvi/flightsim/fg-multip-on-2.jpg (106kb) If you think it's worth being in the release ( being optional thanks to property ), just speak and I will prepare a patch tomorrow evening ( sky.[ch]xx was touched in SimGear, main.cxx in flightgear, preferences.xml in fgfsbase ) Otherwise, I'll hold off until the release is out. Cheers, -Fred That looks really nice. I hope we can include it. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Clouds artefacts
Frederic Bouvier wrote: If you think it's worth being in the release ( being optional thanks to property ), just speak and I will prepare a patch tomorrow evening ( sky.[ch]xx was touched in SimGear, main.cxx in flightgear, preferences.xml in fgfsbase ) Otherwise, I'll hold off until the release is out. Whether it goes in the release or not is up to Curt, but it looks great, and I notice from the screenshots that your framerate stayed the same. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Instrument Settings Dialog; Setting the Altimeter
Matthew Law wrote: It would be nice to eventually be able to map the relevant instruments to any of these units. In the interests of internationalisation, you understand :-) The problem is that we have to make different textures for the faces, etc., so it will never be automatic. Once you've gone to all that trouble, it's no big deal to make a separate XML animation file. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: driving FlightGear from an external app
On Tue, 23 Mar 2004 22:26:59 + (UTC), Martin Spott [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: Arnt Karlsen wrote: .._is_ www.cloudcaptech.org the correct address??? I get nothing ^^^ .com ..thanks. Oo, _neat_ toys. :-) -- ..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] Instrument Settings Dialog; Setting the Altimeter
Matthew Law writes: On Tue, 23 Mar 2004 22:19:52 +, David Luff wrote: eg one-zero-one-three-decimal-two You can probably drop the decimal point for millibars. Done. This makes UK flying a lot more realistic now. Thanks :-) No problem. However, since the panel altimeter is always still in inches and I can't mentally divide by 33.864 in real time I've made it user settable and defaulted it to inches - you need to start flightgear with --prop:/sim/atc/use-millibars=true, or put it in your preferences.xml. Note that even when set true, you'll still only get millibars in the UK, and eventually other countries that use it, not N America. Once we've got a millibar altimeter for the UK I'll make it the default for the ATC here. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Clouds artefacts
David Megginson wrote: Whether it goes in the release or not is up to Curt, but it looks great, and I notice from the screenshots that your framerate stayed the same. On IRC Fred mentioned that they didn't look correct from above. Let's see if he can track down the problem before the official release ... I'm trying to roll out the next pre release tonight. Curt. -- 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
Re: [Flightgear-devel] More 0.9.4pre1 feedback
On Tue, 23 Mar 2004, Erik Hofman wrote: Jon Stockill wrote: I'll also be including fgrun in the package - is there likely to be a release newer than 0.4.2 in time to include in the packages? What's wrong with 0.4.2, it's one week old? Nothing at all - that's what I'm currently using, but if there was gonna be another update I was tempted to wait until it was ready. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Instrument Settings Dialog; Setting the Altimeter
On Tue, 23 Mar 2004, David Luff wrote: Ack - ATIS isn't giving the altimeter at the moment - I took it out since it was hardwired to 29.92. Is there a property or a function that I can use to get the current value, it would be easy to put in. Also - millibars or inches? I'd prefer it in millibars, but all the instruments seem to be calibrated in inches - any chance of alternate settings disks for the instruments? -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Instrument Settings Dialog; Setting the Altimeter
On Tue, 23 Mar 2004, David Luff wrote: OK, by special request the ATIS now puts out millibars for the UK, and inches for the rest of the world. Millibars are to 1 decimal place and inches Hg to 2 eg one-zero-one-three-decimal-two and two-niner-decimal-niner-two Is this reasonable? Seems fine to me. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Instrument Settings Dialog; Setting the Altimeter
On Tue, 23 Mar 2004 22:19:52 +, David Luff [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: Matthew Law writes: On Tue, 23 Mar 2004 20:57:20 +, David Luff wrote: millibars or inches? Can FG be set up to use millibars/Hecto Pascals for the Altimeter pressure setting and imperial for the rest of the units as we use in the UK? All the best, OK, by special request the ATIS now puts out millibars for the UK, and inches for the rest of the world. Millibars are to 1 decimal place and inches Hg to 2 eg one-zero-one-three-decimal-two and two-niner-decimal-niner-two Is this reasonable? ..yes, for added sim realism, you may want to have all us non-US and non-UK etc in the metric ICAO world, use metric hPa's. ;-) -- ..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: driving FlightGear from an external app
Arnt Karlsen wrote: .._is_ www.cloudcaptech.org the correct address??? I get nothing ^^^ .com ..thanks. Oo, _neat_ toys. :-) VERY neat toys. I wonder if that Crista IMU could be used to drive a ground based artificial horizon... That would come in very handy when I get to the point where I want to run R/C aircraft from my sim cockpit. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot fun
On Tuesday 23 March 2004 22:28, Martin Spott wrote: Lee Elliott wrote: Ta for pointing out the high-speed oscillation problem - I've got to confess that all the recent AP changes were only tested at relatively low speeds i.e. flying circuits to check take-offs landing. I'll have a look into it. When you're done with that I'll send you my suggestions for auto-landing (despite the fact that I suspect auto-landing to be really boring ;-)) Martin. It's not boring - it's an interesting problem:) LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: driving FlightGear from an external app
On Wed, 24 Mar 2004 01:27:58 +0100, Arnt Karlsen [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: On Tue, 23 Mar 2004 22:26:59 + (UTC), Martin Spott [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: Arnt Karlsen wrote: .._is_ www.cloudcaptech.org the correct address??? I get nothing ^^^ .com ..thanks. Oo, _neat_ toys. :-) ..uh-oh, http://cloudcaptech.com/download/FlightGear/0.9.2/ means they _distribute_, no? AFAICT, they need to put the FG sources somewhere like http://cloudcaptech.com/download/FlightGear/0.9.2/source/ too, to comply with the GPL's Section 3: (http://www.gnu.org/licenses/gpl.html#SEC3) 3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following: a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, ( c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.) ). ..guideline questions in http://www.gnu.org/licenses/gpl-violation.html Is source code included in the distribution? Is a written offer for source code included with a distribution of just binaries? http://www.gnu.org/ -- ..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: driving FlightGear from an external app
On Tue, 23 Mar 2004 17:58:51 -0800 (PST), Gene Buckle [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: Arnt Karlsen wrote: .._is_ www.cloudcaptech.org the correct address??? I get nothing ^^^ .com ..thanks. Oo, _neat_ toys. :-) VERY neat toys. I wonder if that Crista IMU could be used to drive a ground based artificial horizon... That would come in very handy when I get to the point where I want to run R/C aircraft from my sim cockpit. ..web camera and an 802.11 link to web site for live footage? ;-) -- ..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: driving FlightGear from an external app
Arnt Karlsen wrote: .._is_ www.cloudcaptech.org the correct address??? I get nothing ^^^ .com ..thanks. Oo, _neat_ toys. :-) VERY neat toys. I wonder if that Crista IMU could be used to drive a ground based artificial horizon... That would come in very handy when I get to the point where I want to run R/C aircraft from my sim cockpit. ..web camera and an 802.11 link to web site for live footage? ;-) 50Mhz R/C gear and 70cm ATV for the video downlink. The plan is for three cameras (left, right and center) for display on the projector screens the sim uses. Now granted, this is a couple of years down the road. I've got a lot of work yet to do on the sim itself. The eventual goal is to have a camera plane like a 12' Telemaster for doing aerial photo work. I'd like to be able to build a 1:5 scale F-15C for doing airshows, but that's a WAY off. :) g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] gl-info suffers from undefined references when linking
gcc -g -O2 -L/usr/X11R6/lib -o gl-info gl-info.o -lGLU -lGL -lXmu -lXt -lSM -lICE -lXi -lXext -lX11 -ldl -lm -lglut /usr/lib/gcc-lib/i486-linux/3.3.3/../../../libglut.so: undefined reference to `glXBindChannelToWindowSGIX' /usr/lib/gcc-lib/i486-linux/3.3.3/../../../libglut.so: undefined reference to `glXCreateContextWithConfigSGIX' /usr/lib/gcc-lib/i486-linux/3.3.3/../../../libglut.so: undefined reference to `glXGetFBConfigAttribSGIX' /usr/lib/gcc-lib/i486-linux/3.3.3/../../../libglut.so: undefined reference to `glXQueryChannelDeltasSGIX' /usr/lib/gcc-lib/i486-linux/3.3.3/../../../libglut.so: undefined reference to `glXChannelRectSyncSGIX' /usr/lib/gcc-lib/i486-linux/3.3.3/../../../libglut.so: undefined reference to `glXChannelRectSGIX' /usr/lib/gcc-lib/i486-linux/3.3.3/../../../libglut.so: undefined reference to `glXQueryChannelRectSGIX' /usr/lib/gcc-lib/i486-linux/3.3.3/../../../libglut.so: undefined reference to `glXGetFBConfigFromVisualSGIX' collect2: ld returned 1 exit status make: *** [gl-info] Error 1 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Ornithopter cockpit
It is far too late for this release, but I promised Michael some instruments for the Ornithopter a while back so I've committed what amounts a rough start. It just affects the ornithopter directory and that seems to work so (hopefully) there will be no breakage. This is what it looks like: http://www.spiderbark.com/fgfs/ornithoptervc.png This is what it should look like: http://www.spiderbark.com/fgfs/ornithopterreal.png I've got a much higher res of these and other views. As you can see there's a lot that's not there, but three significant ones are. I'm going to have to figure out what that green thing on the right does before going much further. And that led display in the center looks important as well (must be the mach indicator? :-)). Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] configure.ac
Okay, I just downloaded the lastest pre2 release, and FlightGear still didn't
build out-of-the-box on my linux machine, because /usr/local/ was missing as
part of the EXTRA_DIRS check. Interestingly, this test is done now for
cygwin, but not for linux. I've included a small patch for configure.ac,
which fixes this. Basically, I just copied and pasted the same test from the
cygwin section. I'm not sure if this is the best solution, but on my system,
FlightGear now compiles wihout a glitch.
113a114,116
if test -d /usr/local ; then
EXTRA_DIRS=${EXTRA_DIRS} /usr/local
fi
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] The glX*SGIX are also a problem for fgfs binary
g++ -DPKGLIBDIR=\/usr/local/lib/FlightGear\ -g -O2 -D_REENTRANT -L/usr/X11R6/lib -o fgfs bootstrap.o ../../src/Main/libMain.a ../../src/Aircraft/libAircraft.a ../../src/ATC/libATC.a ../../src/Cockpit/libCockpit.a ../../src/Cockpit/built_in/libBuilt_in.a ../../src/Controls/libControls.a ../../src/FDM/libFlight.a ../../src/FDM/Balloon/libBalloon.a ../../src/FDM/ExternalNet/libExternalNet.a ../../src/FDM/ExternalPipe/libExternalPipe.a ../../src/FDM/JSBSim/libJSBSim.a ../../src/FDM/YASim/libYASim.a ../../src/FDM/JSBSim/filtersjb/libfiltersjb.a ../../src/FDM/LaRCsim/libLaRCsim.a ../../src/FDM/UIUCModel/libUIUCModel.a ../../src/GUI/libGUI.a ../../src/Autopilot/libAutopilot.a ../../src/Input/libInput.a ../../src/Instrumentation/libInstrumentation.a ../../src/Model/libModel.a ../../src/AIModel/libAIModel.a ../../src/Network/libNetwork.a ../../src/Navaids/libNavaids.a ../../src/Scenery/libScenery.a ../../src/Scripting/libScripting.a ../../src/Sound/libSound.a ../../src/Airports/libAirports.a ../../src/MultiPlayer/libMultiPlayer.a ../../src/Replay/libReplay.a ../../src/Systems/libSystems.a ../../src/Time/libTime.a ../../src/Environment/libEnvironment.a -lsgclouds3d -lsgroute -lsgsky -lsgsound -lsgephem -lsgmaterial -lsgtgdb -lsgmodel -lsgtiming -lsgio -lsgscreen -lsgmath -lsgbucket -lsgprops -lsgdebug -lsgmagvar -lsgmisc -lsgnasal -lsgxml -lsgsound -lsgserial -lsgstructure -lsgenvironment -lsgthreads -lpthread -lplibpu -lplibfnt -lplibjs -lplibnet -lplibssg -lplibsg -lplibul -lz -lGLU -lGL -lXmu -lXt -lSM -lICE -lXi -lXext -lX11 -ldl -lm -lglut -lGLU -lGL -lplibsl -lplibsm /usr/lib/gcc-lib/i486-linux/3.3.3/../../../libglut.so: undefined reference to `glXBindChannelToWindowSGIX' /usr/lib/gcc-lib/i486-linux/3.3.3/../../../libglut.so: undefined reference to `glXCreateContextWithConfigSGIX' /usr/lib/gcc-lib/i486-linux/3.3.3/../../../libglut.so: undefined reference to `glXGetFBConfigAttribSGIX' /usr/lib/gcc-lib/i486-linux/3.3.3/../../../libglut.so: undefined reference to `glXQueryChannelDeltasSGIX' /usr/lib/gcc-lib/i486-linux/3.3.3/../../../libglut.so: undefined reference to `glXChannelRectSyncSGIX' /usr/lib/gcc-lib/i486-linux/3.3.3/../../../libglut.so: undefined reference to `glXChannelRectSGIX' /usr/lib/gcc-lib/i486-linux/3.3.3/../../../libglut.so: undefined reference to `glXQueryChannelRectSGIX' /usr/lib/gcc-lib/i486-linux/3.3.3/../../../libglut.so: undefined reference to `glXGetFBConfigFromVisualSGIX' collect2: ld returned 1 exit status make: *** [fgfs] Error 1 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Clouds artefacts
David Megginson wrote : Frederic Bouvier wrote: If you think it's worth being in the release ( being optional thanks to property ), just speak and I will prepare a patch tomorrow evening ( sky.[ch]xx was touched in SimGear, main.cxx in flightgear, preferences.xml in fgfsbase ) Otherwise, I'll hold off until the release is out. Whether it goes in the release or not is up to Curt, but it looks great, and I notice from the screenshots that your framerate stayed the same. I have a GeForce FX5900. I think it is where the newer cards can give us the additional benefit we are not seeing in triangle crunching. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Clouds artefacts
Curtis L. Olson wrote: David Megginson wrote: Whether it goes in the release or not is up to Curt, but it looks great, and I notice from the screenshots that your framerate stayed the same. On IRC Fred mentioned that they didn't look correct from above. Let's see if he can track down the problem before the official release ... I'm trying to roll out the next pre release tonight. I discovered since then that I started FG with --disable-clouds (!) With --enable-clouds, it is ok. This property ( /environment/clouds/status ) seems to be only tested on clouds drawn below the viewer. So to make it short, it seems to work ok. What this change does not address yet is the fact that we can see the ground over overcast layer through the exhaust beam of the hunter. I can try to look at this tonight and cure the --disable-clouds to really disable clouds. Cheers, -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: gl-info suffers from undefined references
From: Alex Perry [EMAIL PROTECTED] [...] /usr/lib/gcc-lib/i486-linux/3.3.3/../../../libglut.so: undefined reference to `glXChannelRectSGIX' [...] Never mind. It looks like Debian Testing has managed to temporarily have insufficient dependency constraints. It is currently possible to have incompatible versions of glut and glX libraries installed. Other Debian Testing users might avoid doing an upgrade for a few days until packages with correct version requirements have been propagated. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
