FlyingAxx

Hi John, I was afraid about that kind of answer. It's obviously an open Beta test we had payed for (I mean MSFS, to be clear) and missing SDK functions and interfaces are apparently nothing that will be voted too high in the hit list what to be fixed next. Probably they are using some kind of ChatGPD in order to sort their priorities.

Well, I even experienced CTDs just after the first wheel touched the runway after a transatlantic flight. Because of the buggy sim this function served as a kind of safety leash for me. Now I'm using only the "save now" function. BTW, would it be possible saving the flight plans for other planes as well? PMDG uses obviously an own procedure (probably almost the same as in FSX). I'm missing this, specifically for FBW's A320 and some other birds.

Hi Antonio, Your observation is correct, PMDG's 737 seems to be the the best example for me. I never had this phenomena in FSX. I think that the amount of data cannot be the reason, specifically as all previous versions where using just one CPU kernel. - Opps, John already said the same. Actually, the case I described could have to do with conflicting autosave functions used by ASOBO. Bush Trips obviously are using something similar at each reached way point, even if you might get in trouble as they are obviously using some kind of standard positioning instead of your real flight situation at a certain time. Unfortunately Autosave is actually the only function of FSUIPC that seems to be useful for me as there are obviously too many SDK gaps. I'm thinking about smoothing between different weather areas and jumping air pressure and wind directions.

Hi John, Thanks for responding so quickly. Actually, I lived with this phenomena for quite while and never had the idea that FSUIPC could be the cause (it's still the case). I'm running MSFS now for roughly one year and never had the feeling that the sim could be close leaving the early Beta-phase. I only wanted you guys to know that there is something going wrong while using your product - and I was hoping that you might have an idea where to look at. I never saw you as causing party, but rather as knowledge carrier regarding bugs and limitations of the involved interfaces. Fact is, that everything runs smoothly having Autosave disabled. All right, you say that Asobo's FlightSave could be the reason. It must be a very special bug nonetheless, as there is one single combination needed. That is: The flight is a Bush Trip AND the a/c uses WorkingTitle's Garmin1000NXI (now default for quite some planes) AND FSUIPC's Autosave is activated Flying a WT Garmin1000NXI equipped plane in a "normal" environment (no Bush Trip) doesn't cause any trouble with Autosave. The same is true with any other gauges on board, even on a Bush Trip. So I think I have to wait until Asobo (or who ever) fixes it. Axel

Hi, First I have to thank for receiving the 1 Year Member Batch! I'm only wondering as I registered my first FSUIPC in Nov. 2003 and did it since then when a new version required it (well I used FSX till I decided switching to MSFS 2020) ! :-o Now the observations: It took a while before nailing the source (that also might be on ASOBO's or on "Working Titles side). However, when trying Bush Trips using e.g. the default Cessna C172 with WT G1000nxi I got in trouble now for several weeks until I took the time tracking it down. I never happened before with the simple G1000. What happened: After the plane is prepared to start for any leg, after a few minutes the VFR map and the MFD screen begins to show strange routing (like a spider on LSD or so - please see the attached sceenshots). When opening the flight plan it is possible to watch randomly changing active legs. The same time the frame rates are dropping rapidly nearly down to 1.6 to 2.4 fps and sometimes the only possibility to get out was to kill MSFS. All normal flights are working as expected, except probably PMDG's B737-700, that is on hold while FSUIPC is saving and that takes about 2 to 3 seconds (hey, it's a fast SSD!). Well the latter is an other story. The attached pics are taken while testing a flight by using the AP, however hand flying doesn't make any difference. When switching the Avionic Bus 2 OFF before the trouble begins, it might work - I'm not really sure at the moment. What I did: I checked for any Windows 10 Pro events and there was nothing (well, it worked with ~2 fps) I started MSFS in Save Mode (after killing the process before) - no avail I made a reset for all MSFS settings - no avail. I reinstalled all "main files", that took hours (even with a fast connection) - no avail I disabled everything that might have to do with configuration - and thought success (for about a week) All "check flights" now worked without problems (e.g. the Sicily tour), till today. Two day ago I crashed a plane (FBW's A320 Experimental) after a long online flight in heavy weather (I forgot the wheels), wanted to set up a saved flight and there was none. I tried to check FSUIPC via hot key and there was no reaction. Actually, I thought I saw the logo during booting the sim. So I reinstalled the actual FSUPC and everything looked okay at the first glance. Today I decided to continue a Bush Trip (the Balkan one) and while standing still on ground the old trouble started again. As FSUIPC reinstalling was the very last and single action I pressed [ALT]+[F] and checked the settings. It was set to save each 6 Minutes as it should an nothing looked unusual. Even the saved files of previous "normal" flights where there. My next attempt ended like the previous one, first the the visual evidence, then stutters an dropping frame rates. I pressed [ESC], called FSUIPC, and disabled all Autosave settings. EDIT: Back to the flight: It recovered and worked well for the next few hours after returning from the Main Menu. Today, almost a day later, I flew without problems. While on ground I switched on FSUIPC's "Autosave", waited some minutes and the mess started again. BTW, all other Bush trips with planes equipped with Garmin's other devices (inclusive Working Title's Mods) are working without problems. My conclusion: It is likely a clash between my registered FSUIPC 7 and WT's Garmin G1000nxi (now default) - probably it might be as well their interface.

Sorry guys that I didn't report the outcome. I only had the chance accessing the concerned computer two weeks later. However, Marcel's fix worked for me. Regards, Axel

Actually, this hint can be a game saver. FSUIPC (latest version) worked without any problem till last Monday. Then I obviously made a big mistake as I updated my W10/64 to 1809. Today my attempt starting FSXA ended with a silent crash. Unfortunately I only can check the registry change next Monday. However, there is just an observation making me uncertain. It only happened when running FSX in a user environment without elevated privileges. Regards, Axel

Good idea, however it should work under CMD as well. While your answer popped up I've made a screenshot: Here you can find the command line as well as the results in runways.xml. r5.csv doesn't show any sign of FSSR. Actually I didn't put it in quotes and above I wrote it just for better identifying the strings. 😵 Well, strange enough, your hint worked! For me a bit surprisingly, as I ever thought that this command line would act equal to a direct shell input. It's another Windows secret for me (probably someone can try to clarify the difference...). However, I can now do what I wanted, thanks Pete. Regards, Axel

Hi Pete, As I wrote in my first post, I'm up to date. It's version MakeRwys 4.8.6.3. I'm using as OS Win10 Pro (latest version and patched), no external anti-virus (just the Defender) and I'm logged in with admin rightsin order to fly. My FS10 is installed on drive d:. I have no clue where to look at. BTW, I found out something other beg´havin strange. When starting MakeRwys from a batch file (with @echo on) the shell windows comes with a string looking like this: "MakeRwys.exe / 1 > 1200" even if the batch calls "MakeRwys.exe />1200". However, all my tests are done by using the shell only. Furthermore I'd just been able reproducing the behaviour on a different FS-PC. Regards, Axel

Hi Pete, Your example MT62 (unmodified) does not appear in my R5.csv , even after running "MakeRwys.exe />100". It seems that I could write what I want after the slash ("/>"). I always get the same total amount of runways, despite what I'm writing behind "/>" (a <space> does it as well) - except when using the other allowed parameters "/Water" or "/WaterOnly". There is even only an error message when using the slash alone. Your conclusion, that the AFCAD has an error might be wrong. I only produced it to fit to a corrected island contour. That's why the runway is shorter than the default one. There are other things going on obviously. The sample file(s) are included. If you want I could make screenies of the batch runs and the related results. Regards, Axel FSSR_AB.zip

Hi Pete, Today I've tried including some short runways (e.g. FSSR having a bit less than 1500 ft) into the findings of MakeRwys 4.8.6.3 by using the "/>n" parameter (MakeRwys.exe />1400) but failed as I didn't get any related output (of course the airport appeared in runways.txt). I've tried as well "/1400", "/>0", and "/0" instead. The respective airport is listed, but without runways. I'm still on FSXA, the airport has been tweaked a bit with ADE - as a couple of hundreds before) and has everything needed (e.g. Start positions). Unfortunately I have no comparison as I never tried out this parameter before. What can I do? Regards, Axel

Okay, I was wrong. I didn't run the latest version (but 4.697). However, a performed memory test - it took some hours - didn't report any error and after downloading the latest version of MakeRunways I cannot reproduce the problem again (and I'm somewhat happy about it). I didn't change the setup, no scenery was added nor removed, and the previous runs showed such results more than once. Sorry Pete for bothering you with an obviously individual glitch.

Pete, the scenery update is a matter for each single user. If you don't do it it might happen that the installed default airport is even miles away from the real one and sometimes it doesn't even exist in FSX/P3D. Summarising the answers (I didn't get) from their Forum and when asking for support, the interest of the users to do anything in order to improve the datasets is limited and PMDG doesn't really care about the correctness of the content being delivered from Third Parties like Navigraph or Aerosoft. I started to analyse and to extend the data just for my own purpose. I'm not really keen to have all the time and each couple of weeks the latest AIRAC conform data. I rather want to have the stuff more or less conform with the installed virtual sim-reality. When finding remarkable discrepancies I tend to fire up ADE in order to correct such airports (a couple of hundred times up to now). In some cases there is the need to add data for missing runways and/or airports to my PMDG navigation data and I'm doing it since FS9 and their old B737 and B747. Regarding your suspicion I can't judge. The topic is pretty new and PMDG is using the same data and file structure now for several years (probably from the beginning?), at least since FS9 and only for their latest FSX/P3D product, the B777, they took care for the automated runway announcements to be in line with the FS installation when approaching a runway and that's why they are using RAAS Professional in order to get those. In fact there are now two new files appearing. One seems to be the R4.CSV and the other one is dynamically build when booting the airplane. Coming back to my original question: I think that I used the latest version of MakeRunways, but I will check it before repeating the run again. Of course I know that one and the same runway has the same width from both ends and even my log-version (runway.txt) sings that song even if some of the following entries are obviously wrong. However, I don't have any trouble with my hardware, no wired crashes, data losses or so, but I will run a memory test which will take some time for 16GByte. Obviously it has something to do with my own installation and I will go after it. I'll report when knowing more.

No, I didn't say that PMDG uses MakeRunways. However, for their B777 they are delivering a file called R4.CSV containing obviously data of the default airports in the same format as it is produced by your program. They have a build in function producing a file comparing the build-in airport data of FSX with those AIRAC related ones coming from Navigraph, Aerosoft, or probably other sources. I think a reason could be to avoid automated landings somewhere in the wild in cases where MS implemented wrong locations. PMDG's documentation refers to probably wrong calls of the runway numbers by RAAS (an integrated Third Party tool) and asks the users to download and run MakeRunways if it happens in order to update the file runways.csv. Even if the last message is correct, RAAS asks for R4.CSV if it is shifted to a different place as I usually did after each run of MakeRunways and it doesn't care for any other missing file. I'm just wondering... :???: However, the file ARP_RWY.dat will be rebuild in cases where new or changed data are detected, it uses a subset of about 13000 airports and its structure looks like that: AP;LOWI;INNSBRUCK ;47.260278;11.343889;1906 RW;08;47.258944;11.332261;1906;10970;067;079;6562 RW;26;47.261619;11.357017;1894;11110;255;259;6562 FS;08;47.258797;11.330925;1900;10970;080;080;6551 FS;26;47.261620;11.357075;1900;11110;260;260;6551 Here a a few examples, all are default airports except ZGSD, a missing one I have build with Jon Masterson's ADE. In order to make the data better comparable I added spaces to archive for each row an equal width. Furthermore I added the correct runway dimensions (regarding ZGSD it matches the charts). VVV Runway dimensions in Feet (rounded, according to ADE) ZGHA,0180,28.198427,113.220970,217,180.000, 8553,110.30, 48,-3.000,28.186712,113.221664,0 8553 x 148 ZGHA,0360,28.174997,113.222359,217,360.000, 8553,109.90, 48,-3.000,28.186712,113.221664,0 8553 x 148 ZGKL,0010,25.204077,110.038788,571, 6.980, 9214,110.10,148,-2.000,25.216665,110.040001,0 9214 x 148 - okay ZGKL,0190,25.229254,110.041214,571,186.980, 9214,108.50, 48,-2.000,25.216665,110.040001,0 9214 x 148 ZGNN,0050,22.606976,108.173378,420, 45.880, 8871,110.90, 0, 0.000,22.615446,108.182838,0 8871 x 148 ZGNN,0230,22.623917,108.192299,420,225.880, 8871, 0,148, 0.000,22.615446,108.182838,0 8871 x 148 - okay ZGSD,0050,21.994093,113.362526, 23, 46.700,13123,110.10, 0,-1.900,22.006865,113.376205,0 13123 x 148 ZGSD,0230,22.019636,113.389885, 23,226.700,13123,108.30, 48,-1.900,22.006865,113.376205,0 13123 x 148 I didn't realise before that obviously something is going wrong with lots of other airports, too (I just watched out for Zeros). Your question regarding Runways.txt: Yes the it first detects the correct width and concludes with wrong data. Below are two examples: Airport ZGHA :N28:11:11.9700 E113:13:17.9998 217ft Country Name="China" State Name="" City Name="Changsha" Airport Name="Huanghua" in file: Scenery\0902\scenery\APX78210.bgl Runway 18 /36 centre: N28:11:12.1643 E113:13:17.9998 217ft Start 18 : N28:11:52.9488 E113:13:15.5795 217ft Hdg: 177.0T, Length 8553ft Computed start 18 : Lat 28.198427 Long 113.220968 Start 36 : N28:10:31.3799 E113:13:20.4205 217ft Hdg: 357.0T, Length 8553ft Computed start 36 : Lat 28.174997 Long 113.222361 Hdg: 177.000 true (MagVar -3.000), Concrete, 8553 x 148 ft Primary ILS ID = IWW Primary ILS: IWW 110.30 Hdg: 177.0 , Flags: GS BC "ILS 18" Secondary ILS ID = ISV Secondary ILS: ISV 109.90 Hdg: 357.0 , Flags: GS BC "ILS 36" *** Runway *** ZGHA0180 Lat 28.198427 Long 113.220970 Alt 217 Hdg 180 Len 8553 Wid 48 ILS 110.30, Flags: GS BC *** Runway *** ZGHA0360 Lat 28.174997 Long 113.222359 Alt 217 Hdg 360 Len 8553 Wid 48 ILS 109.90, Flags: GS BC ============================================================================= Airport ZGNN :N22:36:59.9763 E108:10:59.9998 420ft Country Name="China" State Name="" City Name="Nanning" Airport Name="Wuxu" in file: Scenery\0902\scenery\APX76230.bgl Runway 5 /23 centre: N22:36:55.6030 E108:10:58.2198 420ft Start 5 : N22:36:26.1242 E108:10:25.3350 420ft Hdg: 45.9T, Length 8871ft Computed start 5 : Lat 22.606976 Long 108.173377 Start 23 : N22:37:25.1143 E108:11:31.1047 420ft Hdg: 225.9T, Length 8871ft Computed start 23 : Lat 22.623917 Long 108.192300 Hdg: 45.880 true (MagVar 0.000), Concrete, 8871 x 148 ft Primary ILS ID = IUY Primary ILS: IUY 110.90 Hdg: 45.9 , Flags: GS DME BC "ILS/DME 05" *** Runway *** ZGNN0050 Lat 22.606976 Long 108.173378 Alt 420 Hdg 46 Len 8871 Wid 0 ILS 110.90, Flags: GS DME BC *** Runway *** ZGNN0230 Lat 22.623917 Long 108.192299 Alt 420 Hdg 226 Len 8871 Wid 148 Actually, I never used this specific datum and just tumbled over the inconsistency by chance because I tried to analyse what PMDG is doing there and therefore I looked closer into the file they reported to be missing. I'm running a little tool building most of the PMDG airport related files in alphabetic order just to add airports being able to carry at least their Jetstream 4100 but being missed in the data provided by Navigraph. Hope it was useful.

Hi, I'd build an additional airport (missed at FSXA) with Jon Masterson's Airport Design Editor years ago and now looked closer into the file R4.CSV produced by MakeRunways, due to PMDG's T7 making use of it obviously. It seems to compare the AIRAC Nav-Data with those within the simulator. The result can be seen in the file ARPT_RWY.dat (for those been interested) For the same runway 05/23 of this airport one entry for it's width is '0' (Zero) and the second filled correctly with 43M. However, I found several cases with the same issue and not resticted to add-ons or other self-produced airports. I'm quite sure that it is a bug in MakeRunways and it even might have no influence, neither to RC4 nor to PMDG's bird. At least the latter didn't produce any trouble when I tested it with this specific airport (the other required files had been amended properly, of course). This posting isn't a complain, just a head up and I'm not even sure whether it's worth doing something about it. MakeRunways is a great tool as it is!

Thanks Andy, :oops: it's obvious that I didn't think about comparing the files. I would have seen that the structure (not necessarily all of the content) is identical. That means I just saved the latest version away in order to take the original (but outdated) one from PMDG/RAAS. Well, this means that those guys are using three different and overlapping datasets now - interesting.

Hi Pete, Recently I installed PMDG's Boeing 777 and, by chance, I wanted to update diverse files by using MakeRunways because of a couple of new airports being installed. However, as far as I know your application needs to be installed in the FS main directory and writes its results therein, too. However, after shifting the files to a different folder, I got an error message when firing up FSX from "RAAS Professional" claiming to miss the file "r4.csv" (I had im mind that such a file belongs to Radar Contact). After searching for this specific file inside the FS there was no result, but I found this one after repairing the T7 after that. For me it's clear that PMDG is to blame for such an error (okay, they obviously used a third party package), its also evident that those guys usually are taking ages before fixing such errors (if ever). As I know that you are one of the most responsive developers in the FS scene (really!) I like to ask you whether it is possible to add a dialogue into you app asking for the location where to store the resulting files. Of course it is possible to rename this particular file before running MakeRunways, I'm only not sure whether I can bear that in mind... At least it could help other users of RC4 shifting the files to the right place. (Well, while posting I thought about writing a script doing that, however I would prefer the other solution)

Thank you very much! I think I owe you at least a beer if you ever would visit Berlin - best in later Spring... ;-)

Hi Pete, That's a fair point as I requested myself the one or other addition. Probably I made the wrong decision by using the runways.xml that appeared to be a nice database instead of counting commas in different csv files in order to filter out the data. I have to admit that I even never dreamt about 'exotic' cases like closed runways when looking for the file structures. However, an indicator for a closed runway would be a good thing for the xml database as well. It would be good to distinguish between landing and take-off closures, too. I wouldn't mind if completely closed runways would not be listed as well (as it is today) and airports having no usable runway at all (which should include those very short strips also). For example, MN79 (1470ft, grass) is filtered out in the RC files but appears without any runway data in runways.xml - and there are many others like MO08, too. Okay, if is was an explicite wish to have those data available but stripped (same for water) then I can accept this, of course. However, for those runways being longer than the threshold I would like to know about the closure - pleeeeze. :oops:

All right Pete, in principle I tend to agree regarding water runways, very short ones and pure heliports, too. However, obviously those are nonetheless listed in the airports.xml, at least partly (let's say 'about' 1995 airports). Some examples are showing closed airports/runways listed as well. For instance a completely worthless airport having just one (with reasons!) closed 5000ft concrete runway like Sombor (Z27V) which was bombed as being visible in Google is listed the same way as for example EKVA in Denmark, closed but in a much better shape. BTW, why Microsoft included them will probably remain their secret. In fact, they are not omitted and there is no way to filter those different types out purely based on the runway.xml. I could better get rid of all of those airports in this file rather then having listed them without knowing their 'features'. By the way, as I found out a water runway could be listed as long as there is at least one (valid?) land based runway. A good example for me is EDCY. In reality EDCY has no water strip as both of them are belonging to "Welzow - Sedlitzer See" (EDUY) which does not exist in FSX. However, it's not a big problem anyway as I'm filtering for runway lengths and surfaces ('water' is a hot candidate) in my own application being used to fill gaps in some text based aircrafts' and multi-purpose FMC data sets (PMDG, F1 ATR72-500 and ISG1).

Hi Pete, By chance I found out that there are a couple (even possibly quite a lot) of runway information that did not find their way to "runway.xml" even if the airport itself is listed. In order to analyse the data, I imported the file into Excel and filtered them by a missing surface definition. I checked then in "Runways.txt" and found the missing information. Example (just one) Airport 00B :N38:54:52.9773 W076:30:17.0001 0ft Country Name="United States" City Name="Edgewater" Airport Name="South River" in file: Scenery\0302\scenery\APX27180.bgl Runway 16W/34W centre: N38:54:54.0463 W076:30:14.8999 0ft Hdg: 150.000 true (MagVar -10.000), Water, 5000 x 150 ft FSM A/P 00B, lat=38.914722, long=-76.504723, alt=0 [/CODE] What I did not find is the 'translation' starting in this case with "[font=courier new,courier,monospace] *** Runway *** 00B160...<snip>[/font]", I suppose. The related XML entry: [CODE] <ICAO id="00B"> <ICAOName>South River</ICAOName> <Country>United States</Country> <State></State> <City>Edgewater</City> <Longitude>-76.504723</Longitude> <Latitude>38.914722</Latitude> <Altitude>0</Altitude> <MagVar>-10.000</MagVar> </ICAO> [/CODE] Probably there is a reason but I did not find a scheme as there are not only water surfaces (e.g. CJX7). Excel told me that there are 1995 runways having no definition which might be true for a couple of them (e.g. if the so called airport is just a patch of grass where a direction is not defined). However, if this is a bug and not intentionally I would be interested if you could iron it out one day. Hope you enjoyed your leave!!!

Hi Pete, I was afraid about this kind of answer. The difference seems to be indeed, that the related call in FSX really stops the flight. My own theory is that it might be a timing issue as there are obviously quite some data to be processed in order to complete such a complex panel state (they use 3 files to do so). I'm not sure if Autosave is able to hold all related data in a separate process thread in order to store all of them.

Hello Pete, After updating to PMDG's release SP1c I got in trouble when trying to use AutoSave stored flights. When reloading the flight I do not get a complete and working panel state and when trying to reload the saved PMDG panel state it finally leads to a freeze of my FSX. Is there anything you can do about this? PMDG's answer to my related ticked reads like this: I have to explain, that it worked with previous NGX releases in most cases in the past - but not always.

Wow, that's quick - thanks a lot Pete! :-D Regarding your question: There are no files missing but the list of airports provided by PMDG is not really complete. In some cases Microsoft obviously missed the airport data used by PMDG by several miles (who ever is right). I'm (up to now) no on-line pilot having the need to use up-to-date data and thus I like to use the virtual reality of my existent FS installations, including rwy headings and other data as they are. However, in FSX I'm using PMDG's Queen and I'm still on FS9 because of their 737 and some other planes like Aeroworx' B200 which I do not expect anymore to be rewritten by Flight 1 for FSX. EDIT: I just tried it and it works fine, thanks again.

Hello Pete, At the moment I'm fiddling with a little program that reads the runways.xml data and builds the files being necessary for PMDG'S 737, 747 (FS9) and 747 (FSX). Unfortunately the ILS Hdg information is not available which could lead to a disaster if you are approaching e.g. LOWI by using the Rwy Hdg instead. As I found the related information being part of the runway.txt I hope that the efforts are not too high to add this extra info to the XML. May I put it on the wishlist? :-P