[Flightgear-devel] Bug in python script FGFSDemo.py
Hi All, I am starting a personal coding project which will require a GUI to connect to fgfs in order to read and write to the internal properties. (That's the current scope in a 10 words or less). As I was going through the src/scripts/python directory I saw FGFSDemo.py and had a quick read thought it could be interesting and ran it. While it basically works, it displays errors on the console due to (I assume) the internal properties having changed since it was last updated. I'm happy to work through the code and fix these issues but will occasionally need some advice on what the new property should be. For example when clicking on the weather tab, the wind direction is displayed correctly but the other fields are blank with the following traceback being dumped on the console. The application continues to run however. Traceback (most recent call last): File lib-tk/Tkinter.py, line 1348, in __call__ return self.func(*args) File lib-tk/Tkinter.py, line 459, in callit func(*args) File FGFSDemo.py, line 162, in lambda self.after_id = self.after( 1000, lambda self=self: self.update_page() ) File FGFSDemo.py, line 160, in update_page page.update_fields() File FGFSDemo.py, line 37, in update_fields f.update_field(self.fgfs) File FGFSDemo.py, line 22, in update_field self.field.entry.insert(0, val) File lib-tk/Tkinter.py, line 2317, in insert self.tk.call(self._w, 'insert', index, string) TclError: wrong # args: should be .46912504842648.46912504842720.nbframe.weather.46912504862264.46912504862624.frame.entry insert index text Regards George - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Custom Scenery generation
Hello! Martin Spott wrote: Actually, after Ralf already added _significant_ improvement to the TerraGear tools, I plan to set up some automatic batch-processing for the FlightGear Scenery - although currently I'm not sure how long it will take to 'aquire' the necessary recources ;-) To clarify what Martin is referring to: I have created two additional TerraGear preprocessing tools, namely a GDAL-based chopper for DEM data and an OGR-based vector data decoder. However, I'd like to test them some more before submitting the patches, specifically as the GDAL-chopper still introduces some artifacts in the scenery which I'm currently tracking down. The GDAL-based DEM-chopper can read all GDAL-supported raster formats. This was necessary as we want to use preprocessed SRTM-data from http://srtm.csi.cgiar.org/ which is available as GeoTIFF only. The possibility to use any other GDAL-supported formats is merely a nice by-product as I didn't want to write another GeoTIFF-reader and using an external GeoTIFF-only-library when GDAL is available was somehow pointless. The OGR-based decoder was inspired by Martin to ease processing for the case when we will be building scenery on the same machine/network where also the landcover/terrain database will reside. We can then directly process the vector data from the database to TerraGear chopped polygons and avoid the intermediate step via shapefiles. As a nice by-product the OGR-decoder opens up a huge set of input formats without additional work being required. At some point we might even want to drop the specific shape- and TGVPF-decoders to reduce maintenance effort. The patches are already in the SVN-trunk of fgfs-builder: http://svn.qmx-systems.com/fgfsbuilder/trunk I'll try to keep them current while I'm continuously fixing stuff. To my knowledge the intention is to let LinuxTag take place at this year's location, the Berlin Expo Center under the Funkturm for several years to follow. Well, in that case, we have the chance to have our Berlin scenery grow and getting improved step by step every year. ;-) Cheers, Ralf - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FG segfault
Hi, Just did an update from cvs of the latest and greatest, build went just fine, but... at run time, the program segfaults after the welcome screen comes up. Before running down the halls screaming and setting my hair on fire, thought an update to the base package might be appropriate ;-) Problem is, can't seem to find a link on the website to a cvs version of the base package. Any suggestions where to look Thanks John W. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG segfault
John Wojnaroski schrieb: Hi, Just did an update from cvs of the latest and greatest, build went just fine, but... at run time, the program segfaults after the welcome screen comes up. Before running down the halls screaming and setting my hair on fire, thought an update to the base package might be appropriate ;-) Problem is, can't seem to find a link on the website to a cvs version of the base package. Any suggestions where to look Thanks John W. John, it seems to me you are *not* using any CVS-program, so for download with your browser have a look here http://cvs.flightgear.org/cgi-bin/viewvc/viewvc.cgi/data/ Regards Georg EDDW - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG segfault
It's been a while, I found it. JW John Wojnaroski wrote: Hi, Just did an update from cvs of the latest and greatest, build went just fine, but... at run time, the program segfaults after the welcome screen comes up. Before running down the halls screaming and setting my hair on fire, thought an update to the base package might be appropriate ;-) Problem is, can't seem to find a link on the website to a cvs version of the base package. Any suggestions where to look Thanks John W. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] altimeter, encoder, and kap140
Hi All, I have been communicating off and on with both John Denker and Roy Vegard Ovesen off list concerning this topic. I am running an edit of John's most recent altimetry patch and have modified kap140.nas, altimeter.cxx, and altimeter.hxx so that the altitude capture in the kap140 is using the same atmosphere model as the altimeter. It is also using the altimeter.cxx as the encoder, bypassing encoder.cxx. When near sea level, the cvs encoder.cxx did not report the same pressure altitude as the altimeter with kollsman set to 29.92. By replacing the encoder.cxx with the new altimeter.cxx, this is fixed. Why does the kap140 need info from the altimeter other than the pressure altitude? The altitude capture in the current cvs kap140.nas used altFt = pressureAltitude + hpartial * (baroSetting - 29.92) and compared this to the target altitude. The problem with this is two fold. The second term is a linear approximation to the h(baroSetting,29.92). But h( , ) was the function before altAlert in kap140.nas. It used two transcendental functions each frame and was not the same function now used by John to model the atmosphere (close in the troposphere, but not the same). The attached patch uses the PA (rounded to the nearest 10 ft.) from the new altimeter.cxx and a baro-offset = kollsman offset with baro setting replacing the altimeter setting. Why is that necessary? Well, there are three different numbers that matter. There is the Alt inhg returned by metar. There is the setting the pilot puts in the kollsman window, and there is the baro setting the pilot enters in the KAP140. The KAP140 must use the baro setting and the PA returned by the encoding altimeter to get the term altFt it compares to the target altitude. It has access to the static pressure according to the KAP140 manual, but could use a power function approximation similar to what John's altimeter uses to compute the baro offset w/o knowing the static pressure. Then altFt = PA - baroOffset. The patch attached models the following pilot errors correctly. Case 1: Pilot enters the QNH in baro setting on the KAP140 but does not enter QNH correctly in the kollsman window of the altimeter. If he sets the target altitude and arms it, the AC will still capture the right altitude, but the indicated altitude will be wrong. Case 2: Pilot enters QNH correctly in the kollsman window on the altimeter, but sets baro setting wrong. Even if he sets the target altitude right and arms it, the AC will capture the wrong altitude. For example, if the baro setting is 29.92, the KAP140 will capture PA which is only correct if QNH = 29.92. But since he got QNH right in the kollsman window, the indicated altitude will be correct, telling him he captured the wrong altitude. I modified John's code so the altimeter picks up baro setting from /autopilot/KAP140/settings/baro-setting-inhg and uses this to compute baroOffset using the same interpolation function model, _altimeter.kollsman_ft(baro_setting). I also rearranged the truncation of pressure altitude in John's code so the indicated altitude is computed before the pressure altitude is rounded and saved. John, you may have already caught and corrected this bug. I consider this combined patch to be a significant improvement to FlightGear. Where you will notice the improvement the most is 1) Mountain airports with QNH != 29.92, 2) Flying down glide slopes to a mountain airport (indicated DH will be close to accurate, often avoiding a crash situation should you fly the approach with the present cvs.) 3) The captured altitude for the KAP140 will be as accurate as it is with real autopilots. I am sure John can point out other situations the new atmosphere model improves. I want both John and Roy to try this patch before we consider submitting it to cvs. Of course, anyone can try it and comment. Is the encoder used anywhere other than by the KAP140? If so, we should use a separate instantiation as suggested by John. Regards, -- Dave Perry altimetry.tar.gz Description: application/compressed-tar - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Weekly CVS Changelog Summary: SimGear
2f585eeea02e2c79d7b1d8c4963bae2d - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Weekly CVS Changelog Summary: FlightGear source
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-02-19_10:18:57 (mfranz) /var/cvs/FlightGear-0.9/source/scripts/example/remote.html s/--props/--telnet/ (I may do that. I wrote this file. :-) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-02-19_14:52:53 (mfranz) /var/cvs/FlightGear-0.9/source/src/Network/props.cxx fix set command: allow strings to contain spaces =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-02-19_14:52:55 (mfranz) /var/cvs/FlightGear-0.9/source/src/Network/props.cxx fix set command: allow strings to contain spaces =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-02-19_16:52:52 (curt) /var/cvs/FlightGear-0.9/source/utils/GPSsmooth/UGear.hxx Update the ugear health structure to match the microgear code. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-02-19_21:13:01 (curt) /var/cvs/FlightGear-0.9/source/utils/GPSsmooth/UGear.cxx /var/cvs/FlightGear-0.9/source/utils/GPSsmooth/UGear_main.cxx Fix a couple data packet decoding mistakes. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-02-20_05:35:58 (mfranz) /var/cvs/FlightGear-0.9/source/utils/Modeller/fgfs_animation.py /var/cvs/FlightGear-0.9/source/utils/Modeller/fgfs_animation.py animation plugin for Blender 2.43 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-02-20_05:35:59 (mfranz) /var/cvs/FlightGear-0.9/source/utils/Modeller/fgfs_animation.py animation plugin for Blender 2.43 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-02-20_15:12:44 (mfranz) /var/cvs/FlightGear-0.9/source/src/Network/props.cxx remove show command from help screen (command can be removed later) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-02-20_15:12:56 (mfranz) /var/cvs/FlightGear-0.9/source/src/Network/props.cxx remove show command from help screen (command can be removed later) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-02-21_15:11:15 (curt) /var/cvs/FlightGear-0.9/source/utils/GPSsmooth/UGear.cxx /var/cvs/FlightGear-0.9/source/utils/GPSsmooth/UGear.hxx /var/cvs/FlightGear-0.9/source/utils/GPSsmooth/UGear_main.cxx Fix a bug in file logging (add an ignore checksum option just to humor myself.) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-02-23_15:34:34 (mfranz) /var/cvs/FlightGear-0.9/source/src/Instrumentation/vertical_speed_indicator.cxx Nick WARNE: fix property name =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-02-23_15:34:41 (mfranz) /var/cvs/FlightGear-0.9/source/src/Instrumentation/vertical_speed_indicator.cxx Nick WARNE: fix property name =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-02-24_13:43:19 (mfranz) /var/cvs/FlightGear-0.9/source/src/GUI/layout.cxx don't descend into nasal groups to avoid padding space beind added around =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-02-24_13:43:21 (mfranz) /var/cvs/FlightGear-0.9/source/src/GUI/layout.cxx don't descend into nasal groups to avoid padding space beind added around 2f585eeea02e2c79d7b1d8c4963bae2d - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Weekly CVS Changelog Summary: FlightGear data
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
2007-02-18_02:17:21 (sydadams)
/var/cvs/FlightGear-0.9/data/Aircraft/dhc2/dhc2F-set.xml
added a start-on-water property in the set file for KSFO...
gear up , winch and water rudders down are set at startup, but not properly
re-initialized if a reset is done during runtime...working on that
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
2007-02-18_02:17:22 (sydadams)
/var/cvs/FlightGear-0.9/data/Aircraft/dhc2/dhc2F.xml
/var/cvs/FlightGear-0.9/data/Aircraft/dhc2/Nasal/dhc2.nas
added a start-on-water property in the set file for KSFO...
gear up , winch and water rudders down are set at startup, but not properly
re-initialized if a reset is done during runtime...working on that
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
2007-02-18_11:21:50 (mfranz)
/var/cvs/FlightGear-0.9/data/preferences.xml
- add property /sim/startup/terminal-ansi-colors {BOOL}. This is used
by debug.nas to turn on/off syntax coloring for dumped data (which
is desirable as compound data types can fill several screens with
rather hard to read data). Unfortunately, it can't be reliably deduced
from the OS whether ANSI colors are available or not.
- move multiplayer chat properties to where they belong
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
2007-02-18_11:21:51 (mfranz)
/var/cvs/FlightGear-0.9/data/Nasal/debug.nas
- add property /sim/startup/terminal-ansi-colors {BOOL}. This is used
by debug.nas to turn on/off syntax coloring for dumped data (which
is desirable as compound data types can fill several screens with
rather hard to read data). Unfortunately, it can't be reliably deduced
from the OS whether ANSI colors are available or not.
- move multiplayer chat properties to where they belong
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
2007-02-18_12:33:11 (mfranz)
/var/cvs/FlightGear-0.9/data/Input/Joysticks/Saitek/Cyborg-Gold-3d-USB.xml
- replace [OFF, ON][i] with faster ternary operators (which didn't
exist when this was written)
- cosmetics
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
2007-02-18_18:26:42 (sydadams)
/var/cvs/FlightGear-0.9/data/Aircraft/dhc2/dhc2F-set.xml
/var/cvs/FlightGear-0.9/data/Aircraft/dhc2/dhc2F.xml
/var/cvs/FlightGear-0.9/data/Aircraft/dhc2/Nasal/dhc2.nas
move start-up water position to a better spot... still some bugs to work out ...
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
2007-02-19_06:12:57 (martin)
/var/cvs/FlightGear-0.9/data/Aircraft/pa24-250/Models/mag.sw/Attic/mag_switch.ac
/var/cvs/FlightGear-0.9/data/Aircraft/pa24-250/Models/mag.sw/Attic/mag_switch.rgb
/var/cvs/FlightGear-0.9/data/Aircraft/pa24-250/Models/mag.sw/Attic/mags.xml
Dave Perry:
This patch makes the pa24 changes to use the mag.sw from Instruments 3d.
Changed the mag_switch.ac to include the pick rectangles and the
mags.xml to use the pick automation. Also includes the edits to
pa28-161.xml and pa28-161-set.xml to use the 3d radio stack.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
2007-02-19_06:18:34 (martin)
/var/cvs/FlightGear-0.9/data/Aircraft/pa24-250/Models/pa24-250.xml
Dave Perry:
This patch makes the pa24 changes to use the mag.sw from Instruments 3d.
Changed the mag_switch.ac to include the pick rectangles and the
mags.xml to use the pick automation. Also includes the edits to
pa28-161.xml and pa28-161-set.xml to use the 3d radio stack.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
2007-02-19_06:18:35 (martin)
/var/cvs/FlightGear-0.9/data/Aircraft/pa24-250/Panel/pa24-panel.xml
/var/cvs/FlightGear-0.9/data/Aircraft/pa28-161/pa28-161-set.xml
/var/cvs/FlightGear-0.9/data/Aircraft/pa28-161/Models/pa28-161.xml
Dave Perry:
This patch makes the pa24 changes to use the mag.sw from Instruments 3d.
Changed the mag_switch.ac to include the pick rectangles and the
mags.xml to use the pick automation. Also includes the edits to
pa28-161.xml and pa28-161-set.xml to use the 3d radio stack.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
2007-02-19_15:20:08 (curt)
/var/cvs/FlightGear-0.9/data/Aircraft/F4U/f4u-set.xml
/var/cvs/FlightGear-0.9/data/Aircraft/F4U/f4u-yasim.xml
/var/cvs/FlightGear-0.9/data/Aircraft/F4U/f4u.nas
/var/cvs/FlightGear-0.9/data/Aircraft/F4U/Models/crosshair.rgb
/var/cvs/FlightGear-0.9/data/Aircraft/F4U/Models/f4u-1.rgb
Detlef Faber:
This is an update for the F4U, improved FDM, removed n/N key binding,
added a pilot and a gunsight, improved prop animation, model
improvements.
These files are not needed anymore:
F4U/Models/f4u-5.rgb
F4U/Models/pdisk.rgb
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
2007-02-19_15:20:10 (curt)
/var/cvs/FlightGear-0.9/data/Aircraft/F4U/Models/f4u-2.rgb
/var/cvs/FlightGear-0.9/data/Aircraft/F4U/Models/f4u-3.rgb
Detlef Faber:
This is an update for the F4U, improved FDM, removed n/N key binding,
added a pilot
Re: [Flightgear-devel] altimeter, encoder, and kap140
On 02/25/2007 12:30 AM, Dave Perry wrote: I have been communicating off and on with both John Denker and Roy Vegard Ovesen off list concerning this topic. I am running an edit of John's most recent altimetry patch and have modified kap140.nas, altimeter.cxx, and altimeter.hxx so that the altitude capture in the kap140 is using the same atmosphere model as the altimeter. It is also using the altimeter.cxx as the encoder, bypassing encoder.cxx. When near sea level, the cvs encoder.cxx did not report the same pressure altitude as the altimeter with kollsman set to 29.92. By replacing the encoder.cxx with the new altimeter.cxx, this is fixed. Roger. Why does the kap140 need info from the altimeter other than the pressure altitude? The altitude capture in the current cvs kap140.nas used altFt = pressureAltitude + hpartial * (baroSetting - 29.92) and compared this to the target altitude. The problem with this is two fold. The second term is a linear approximation to the h(baroSetting,29.92). But h( , ) was the function before altAlert in kap140.nas. It used two transcendental functions each frame and was not the same function now used by John to model the atmosphere (close in the troposphere, but not the same). By saving the result, you only need to do two transcendental functions every time the pilot changes the baro setting (not two per frame) which seems affordable. By the way ... avoiding transcendental functions is not necessarily necessary nor sufficient for good programming. I've measured a few examples relevant to FG, and found that the transcendental functions are only percentage points slower than the interpolation tables that are being used to speed things up. It seems likely that a table small enough to be fast isn't accurate, and a table big enough to be accurate isn't fast. As the saying goes, premature optimization is the root of all evil. I would like to see some actual factual measurements before making very many decisions about what to optimize and how to optimize it. there are three different numbers that matter. There is the Alt inhg returned by metar. There is the setting the pilot puts in the kollsman window, and there is the baro setting the pilot enters in the KAP140. Yes, that's clear. The KAP140 must use the baro setting and the PA returned by the encoding altimeter to get the term altFt it compares to the target altitude. It has access to the static pressure according to the KAP140 manual, but could use a power function approximation similar to what John's altimeter uses to compute the baro offset w/o knowing the static pressure. I don't see how that could possibly work. Encoded pressure altitude and static pressure are two versions of the same idea. Comparing them cannot give any information about the present value and/or desired value of the baro setting. Then altFt = PA - baroOffset. The patch attached models the following pilot errors correctly. What patch? Case 1: Pilot enters the QNH in baro setting on the KAP140 but does not enter QNH correctly in the kollsman window of the altimeter. If he sets the target altitude and arms it, the AC will still capture the right altitude, but the indicated altitude will be wrong. That's clear. Case 2: Pilot enters QNH correctly in the kollsman window on the altimeter, but sets baro setting wrong. Even if he sets the target altitude right and arms it, the AC will capture the wrong altitude. For example, if the baro setting is 29.92, the KAP140 will capture PA which is only correct if QNH = 29.92. But since he got QNH right in the kollsman window, the indicated altitude will be correct, telling him he captured the wrong altitude. That's clear. I modified John's code so the altimeter picks up baro setting from /autopilot/KAP140/settings/baro-setting-inhg and uses this to compute baroOffset using the same interpolation function model, _altimeter.kollsman_ft(baro_setting). No comment until I see the code. I also rearranged the truncation of pressure altitude in John's code so the indicated altitude is computed before the pressure altitude is rounded and saved. John, you may have already caught and corrected this bug. I quite intentionally rounded the pressure altitude not the indicated altitude. This is a realistic model of the action of a blind encoder, which knows nothing of the baro setting. There are multiple mechanical and electrical reasons why the blind encoder should round the pressure altitude. I see no corresponding reasons why the autopilot should round the indicated altitude, or expect the encoder to do so. In short, I see no reason to think that it is a bug to apply (when requested!) rounding to the pressure altitude. I consider this combined patch to be a significant improvement to FlightGear. Where you will notice the improvement the most is 1) Mountain airports with QNH != 29.92, 2) Flying down glide slopes to a
