Jump to content
The simFlight Network Forums


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About FlyingAxx

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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
  2. 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
  3. 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
  4. Hi Pete, As I wrote in my first post, I'm up to date. It's version MakeRwys 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
  5. 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
  6. 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 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
  7. 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.
  8. 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.
  9. 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.
  10. 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!
  11. 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.
  12. 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)
  13. Thank you very much! I think I owe you at least a beer if you ever would visit Berlin - best in later Spring... ;-)
  14. 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:
  15. 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).
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.