Quaxman

The leading problem lies in the fsAerodata correction tool. In the "automatic mode" (the tool processes all airports in runways.xml), some of my addon airports are skipped, therefore elevated. In the "manual mode" with a user specified altitude list, some of my altitude values are skipped and it seems, the tool skipped them as the difference between their altitude and my altitude is lower than 1 ft (but not in every case). I wrote them the issue... OK, I see that I could use the values of runways.txt for my script and either the tool of fsAerodata has to be corrected or I have to write my own tool... Regarding EDDF, I made a little mistake: the last line was already corrected by me. With a virgin FSAD_comms.BGL, it would look this way as FSAD_comms.BGL is delivered with the original altitudes of P3D ICAO linenumber altitude BGL EDDF 000001187422 363.99ft Scenery\0601\scenery\APX50140.bgl EDDF 000002172425 363.99ft ORBX\FTX_EU\FTX_EU_GES_05_SCENERY\scenery\ADE_FTX_GES_EDDF.bgl EDDF 000002353326 364.01ft C:\Games\Aerosoft\Mega Airport Frankfurt Professional\.\scenery\EDDF_AFX-OP07.BGL EDDF 000002377139 363.99ft C:\GAMES\fsAerodata Files\Navigation Data\P3D\PROC_SIDs\scenery\EDDF_SIDS.BGL EDDF 000002377151 363.99ft C:\GAMES\fsAerodata Files\Navigation Data\P3D\PROC_SIDs\scenery\EDDF_STARS.BGL EDDF 000002414647 363.99ft C:\GAMES\fsAerodata Files\Navigation Data\P3D\PROC\scenery\EDDF.BGL EDDF 000002666905 363.99ft C:\GAMES\fsAerodata Files\Navigation Data\Comms\scenery\FSAD_comms.BGL In this case, the correct value that has to be placed in FSAD_comms.BGL is normally the last entry before the fsAerodata files themselves, here 364.01ft from AeroSofts EDDF_AFX-OP07.BGL I want my script as a general tool to check altitude values of P3D's BGLs in the sim's search order (now as with HF2 the method to retrieve the lasting altitude was changed). Regarding P3D, I trust no one 🤭 (not even myself). I hope, fsAerodata could correct the behaviour of its tool...

Yes, I know the discussion. And I spend hours in analyzing why the tool of fsAerodata doesn't handle all my addon airports: It's a rounding problem feet vs. meter (output of makerwys is in feet, BGL definition says meter). I wrote this in their forum with my wish to handle a fixed airport altitude list in meters instead of feet. My thoughts were to avoid processing of the whole P3D airport list, instead giving the fsAerodata tool a fixed list with <ICAO>,<altitude> (as I know my addon airports and have to modify this list only if I buy a new one). They made it possible by a parameter "-f <list>" in their AdjustElevation.exe, but the altitudes have to be specified in feet at the moment. Now I found out, that their tool has to convert feet in meters - according to fsdeveloper.com BGL files contain altitudes in meters and aero.sors.fr states "Altitude is given in 1/1000 m as DWORD". If the difference of an addon airport is small compared to their default altitude (which is P3D default altitude), the AdjustElevation.exe simply ignores the airport and its specified altitude in the list. This seems to be related to rounding issues in their conversion from feet to meters (only my assumption, but that's what I see as result). Now why do I process runways.txt ? To get the correct altitude value for the list file as input to their tool, I have to find out the altitude of the addon BGL in an ascending order in the same way the simulator does it. This lead me to runways.txt. To do this search and display on a convenient way, I wrote the appended script. This works for most addon airports except for airports where the addon BGL altitude is small compared to the base BGLs altitude (the mentioned rounding errors). The script writes on the Powershell console and in a logfile the sorted altitudes of the specified ICAO Ids, e.g.: ICAO linenumber altitude BGL EDDF 000001187422 363.99ft Scenery\0601\scenery\APX50140.bgl EDDF 000002172425 363.99ft ORBX\FTX_EU\FTX_EU_GES_05_SCENERY\scenery\ADE_FTX_GES_EDDF.bgl EDDF 000002353326 364.01ft C:\Games\Aerosoft\Mega Airport Frankfurt Professional\.\scenery\EDDF_AFX-OP07.BGL EDDF 000002377139 363.99ft C:\GAMES\fsAerodata Files\Navigation Data\P3D\PROC_SIDs\scenery\EDDF_SIDS.BGL EDDF 000002377151 363.99ft C:\GAMES\fsAerodata Files\Navigation Data\P3D\PROC_SIDs\scenery\EDDF_STARS.BGL EDDF 000002414647 363.99ft C:\GAMES\fsAerodata Files\Navigation Data\P3D\PROC\scenery\EDDF.BGL EDDF 000002666905 364.20ft C:\GAMES\fsAerodata Files\Navigation Data\Comms\scenery\FSAD_comms.BGL ***** EDDF *** ATTENTION *** BGL with different altitude found ***** Here, I see: EDDF addon airport altitude from the Aerosoft BGL is 364.01ft, so fsAerodata BGL has to be corrected from 364.20ft to 364.01ft - but that doesn't work at the moment. I thought, as a solution, if their AdjustElevation.exe would accept meters instead of feet in the correction list ("-f") and runways.txt could deliver the value in meters, the elevation correction would work even with small differences. p3d45hf2_fsad_altitude_list.zip

Hi, regarding the P3D 4.5 HF2 altitude processing and the problem with fsAerodata Navigraph FSAD_comms.BGL, I wrote a script to check the airport records in runways.txt to scan airports for BGLs with different altitudes. The script works, but now, I detected rounding issues from meters (as defined in the BGL) to feet in the chain runways.txt (alt in ft) -> fsAerodata correction tools (alt in ft) -> FSAD_comms.BGL (alt in meters). My question: would it be possible to enhance the airport lines in runways.txt with the original meters value from the BGLs ? currently: "Airport EDDF :N50:01:59.8986 E008:34:13.6389 363.99ft" enhanced: "Airport EDDF :N50:01:59.8986 E008:34:13.6389 363.99ft 110.947m" (110,947 derived from DWORD 63 B1 01 00) I asked fsAerodata for a modification of the correction tool AdjustElevation.exe to process the input list with the correction values in meters, if both wishes would be fulfilled, one could take the exact altitude value in meters for addon airports from runways.txt, create the input list for AdjustElevation.exe for these airports in meters and correct the fsAerodata FSAD_comms.BGL with this exact altitude value to remove the elevation issues. BTW: I had to create such a correction list as the fsAerodata tool doesn't process all my addon airports and some of the processed ones don't have the correct altitude value. I know, Christmas is nearly over and time for wishes has passed, but maybe you can consider my thoughts in a future update of makerwys.txt ?

Universe is stranger than we imagine. But now my script doesn't show any runway with unknown surface. I'm happy... many thanks for your support !

No real problem as I have vacations, good weather and a bunch of other things to do 😏

And here ESSA (Stockholm Arlanda) APX52100.bgl -> Base ESSA_ADEP4_SL_ORBX_P3D_Statics.bgl -> ORBX Stockholm Arlanda So it happens not only for 29palms. ESSA.zip

OK, I added three BGLs: APX50140.bgl -> Base ADE_FTX_GES_EDDN.bgl -> ORBX germany south EDDN_ADE.bgl -> 29palms EDDN EDDN.zip

Searching runways.txt for " EDDN", I found: 1. Airport EDDN :N49:29:54.9951 E011:04:39.9991 1046ft in file: Scenery\0601\scenery\APX50140.bgl Runway 10 /28 centre: N49:29:55.4486 E011:04:39.3506 1046ft Hdg: 98.600 true (MagVar 1.000), Concrete, 8841 x 148 ft 2. ORBX\FTX_EU\FTX_EU_GES_05_SCENERY\scenery\ADE_FTX_GES_EDDN.bgl Deletions check for Airport EDDN: Delete all runways and starts! 3. Airport EDDN :N49:29:54.9951 E011:04:39.9991 1046ft in file: ORBX\FTX_EU\FTX_EU_GES_05_SCENERY\scenery\ADE_FTX_GES_EDDN.bgl Runway 10 /28 centre: N49:29:55.4486 E011:04:39.3506 1046ft Hdg: 98.600 true (MagVar 1.000), Concrete, 8841 x 148 ft 4. Area.260 "Captain7 - 29Palms - EDDN - Nuremberg" (Layer=260) Path(Local/Remote)=C:\Games\Lockheed Martin\Prepar3D v4\29Palms\Captain7 - 29Palms - EDDN - Nuremberg C:\Games\Lockheed Martin\Prepar3D v4\29Palms\Captain7 - 29Palms - EDDN - Nuremberg\scenery\EDDN_ADE.bgl Delete all runways and starts! 5. C:\Games\Lockheed Martin\Prepar3D v4\29Palms\Captain7 - 29Palms - EDDN - Nuremberg\scenery\EDDN_ADE.bgl Airport EDDN :N49:29:54.9951 E011:04:39.9991 1046ft Runway 10 /28 centre: N49:29:55.4486 E011:04:39.3506 1046ft Hdg: 98.600 true (MagVar 1.000), UNKNOWN 128, 8858 x 243 ft ------------------ So I opened the above mentioned BGL files with ADE 1.76: APX50140.bgl -> RW10/28: Concrete ADE_FTX_GES_EDDN.bgl -> RW10/28: Concrete (ORBX Germany South) EDDN_ADE.bgl -> RW10/28: Concrete I append the BGLs... The same happens for Stockholm Arlanda (ESSA): addon from ORBX. Currently, I cannot attach a file...I will try in a following post.

Hi, I want to use the output of makerwys for a moving map app that doesn't support P3D V4 correctly, so I translate runways.xml to the app's xml format by a Powershell-Script. But it seems, Makerwys (4.872) doesn't give me the right runway material for some (addon ?) airports. Example: runways.txt output for EDDN from 29palms: 1. Makerwys finds the default BGL Scenery\0601\scenery\APX50140.bgl: Runway 10 /28 centre: N49:29:55.4486 E011:04:39.3506 1046ft ... Hdg: 98.600 true (MagVar 1.000), Concrete, 8841 x 148 ft 2. Makerwys finds a delete operation (exclusion BGL ?): ORBX\FTX_EU\FTX_EU_GES_05_SCENERY\scenery\ADE_FTX_GES_EDDN.bgl Deletions check for Airport EDDN: Delete all taxiways! Delete all runways and starts! *** DelBth *** EDDN0100 Lat 49.500549 Long 11.059137 Alt 1046 Hdg 98 Len 8841 Wid 148 ILS 111.30, Flags: GS BC *** DelBth *** EDDN0280 Lat 49.496925 Long 11.096058 Alt 1046 Hdg 278 Len 8841 Wid 148 ILS 109.10, Flags: GS BC 3. Makerwys finds ORBX\FTX_EU\FTX_EU_GES_05_SCENERY\scenery\ADE_FTX_GES_EDDN.bgl (ORBX Germany south) Runway 10 /28 centre: N49:29:55.4486 E011:04:39.3506 1046ft Start 10 : N49:30:01.7655 E011:03:35.1902 1046ft Hdg: 98.6T, Length 8841ft Computed start 10 : Lat 49.500549 Long 11.059138 Start 28 : N49:29:49.1317 E011:05:43.5096 1046ft Hdg: 278.6T, Length 8841ft Computed start 28 : Lat 49.496925 Long 11.096057 Hdg: 98.600 true (MagVar 1.000), Concrete, 8841 x 148 ft 4. Makerwys finds 29palms addon: C:\Games\Lockheed Martin\Prepar3D v4\29Palms\Captain7 - 29Palms - EDDN - Nuremberg\scenery\EDDN_ADE.bgl Delete all taxiways! Delete all runways and starts! 5. Makerwys finds the runways in file: C:\Games\Lockheed Martin\Prepar3D v4\29Palms\Captain7 - 29Palms - EDDN - Nuremberg\scenery\EDDN_ADE.bgl Runway 10 /28 centre: N49:29:55.4486 E011:04:39.3506 1046ft Start 10 : N49:30:01.7655 E011:03:35.1902 1046ft Hdg: 98.6T, Length 8858ft Computed start 10 : Lat 49.500553 Long 11.059102 Start 28 : N49:29:49.1317 E011:05:43.5096 1046ft Hdg: 278.6T, Length 8858ft Computed start 28 : Lat 49.496922 Long 11.096093 Hdg: 98.600 true (MagVar 1.000), UNKNOWN 128, 8858 x 243 ft Output to runways.xml is "<Def>unknown</Def" The same happened to ESSA (Stockholm Arlanda) addon by ORBX or ESSD - so it's not only 29palms. My question: would it be possible for Makerwys to takeover the runway material in the case of runway deletion, if the runway's name is identical ? Especially in the case of mixed grass/hard stuff runways (f.e. ESSD), I find it helpfull to get this information out of the moving map app. regards, Quaxman. Runways - Copy.zip

Sorry for wasting your time, I found a hint in www.fsdeveloper.com , stating: That's a very old limitation of the FSX/P3D rendering engine. For some reason, the sim's built-in instant replay will not render any SimObjects that were injected from SimConnect clients. Tools like SODE, FSDT's couatl and even AI Traffic generators are affected by this. I have posted a request to change this in LM's Prepar3D forum a long time ago, but did not get a response... A workaround to this is to use a 3rd party recorder/replay tool, like FSRecorder or such. The objects are displayed when using those. Meaning: it's not a bug but a feature 🤒 I checked the behaviour, for example of the HOTAS rocker switch, again, it's the same in FSX and P3D: "send to FS as normal axis" -> works in replay mode "send direct to FSUIPC Calibration" : pan heading -> doesn't work in replay mode So, it seems to be a limitation of FSX and P3D. Just to be complete: in FSX, to limit the panning from 180° to some 90°, I modified standard.xml by setting AXIS_PAN_HEADING Value <AxScale> to 127, this doesn't work in P3D V4.2 any more as AxScale has another meaning. So, I limit the panning by setting a FSUIPC factor: 11=3S,256,D,33,0,0,0,*0.65 -{ DIRECT: PanHeading }- That works great in flying , but not in instant replay mode for the above reason. And the reason to drive the HOTAS throttle with FSUIPC is the absence of the function "view zoom set" in the sim itself, thanks to FSUIPC, I can use the big lever for zooming in and out. So, after browsing the whole internet, it seems, the only solution to this (admittedly marginal) problem is to cause Santa Claus to come some months earlier and bring me one of these praised replay plugins...🙂

Hi, what works in FSX, doesn't in P3D V4.2 (installed some days ago with FSUIPC 5.131 registered version): I defined my T.Flight HOTAS throttle to zoom and the rocker switch on the throttle to view panning. Everything works ok when I fly "normally", but in the instant replay mode, the FSUIPC controlled axis don't work. After installing P3D, I defined the whole HOTAS in FSUIPC, but in instant replay mode, even the buttons (view next a.s.o.) do not work. Except from instant replay mode, everything in P3D/FSUIPC works well - as in FSX. Is there any setting in FSUIPC that I have forgotten to activate/define, so that FSUIPC 5 works in P3D instant replay mode ?

I bought my SAITEK trim wheel long time ago - it's an old story and not FSUIPC related: After starting/restarting Windows, one has to turn the wheel until the Windows USB device detection sound comes up. It's a problem in the USB controller of the wheel.