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!