FlyingAxx

Hello Pete, Sorry for answering late. I'd been away for RL reasons - no time for fora at all. :( However, I just downloaded the new version and will check it out during the weekend. My "code translator" is IDE and as it seems it is necessary to construct a test airport containing all possible runway surfaces. This has to be done by using a HEX editor finally in order to be sure about the used code. Again my test airport build in FS9 with AFCAD2. I checked it later against ADE9X and found the different translation. Hmm, a bit early for April Fool's Jokes. Of course you're right regarding h02, I meant h03 I'm afraid, sorry for the confusion. EDIT (picture away - not needed) Well, as it seems I have to test some more codes.... (fortunately the weather is terrible) ------------- EDIT: It's always an advantage to read and to understand what's written :x Pete, I missed to compare the codes which are now changed to the previous ones and against those known by the compiler (or better: SDK). Yes, those changes are all fine to me. No need for further tests from my side :D ------------- EDIT 2: Please forget about this one. I just trusted in a remark of someone else which was apparently not correct. I just made my own tests and both, FS9 and FSX are reacting exactly the same way when being confronted with non-SDK-compliant runway surface codes (allowed to be used by AFCAD2) as "h03", "h05", "h06", "h0A" and "h0B" which are shown as GRASS (first three) and CONCRETE (the last ones).

Hello Pete, First of all I like to say that the new version of Make Runways runs excellent. The main question is now, whether there is any longer the need for remaining compatible to FS editions older than FS9. May I suggest that in future versions the XML file will contain the original runway surfaces instead of a partly reduced mapping to similar ones which are downwardly compatible? :roll: There is just one difference left between FS9 and FSX which might be solved by knowing (and selecting) the target system: It is the handling of the surface code 0002h which is interpreted by FS9 as GRASS and in FSX it seems to be CEMENT. However, I believe that this code is only relevant for AFCAD2 files using UNKNOWN2 in order to describe the surface. I would be highly pleased if you could follow my suggestion.

That's what I would call a mid-size system. :lol: The price of the CPU alone is more expensive than the complete system I have just build last weekend for my wife. It's based on an INTEL Core i5-750 cooled by a NOCTUA NH-U12P SE2 (max. 19.5 dB (A)) and sitting on an ASUS-P7P55D with 2x2 GB CORSAIR memory, futhermore an ATI based GPU MSI R4870-MD1G, a very silent Seagate Baracuda 1T harddisk and everything powered by a bequiet! Dark Power PRO 550W (only!) - the existing ANTEC-P182 case was re-used. I think the system is not too bad - at least sufficient for recent games - but I have severe doubts that it would run FSX without stutters - even when overclocked. However, it is quiet and cool and we like it. As we can expect new processor generations about each 8 months a system being capable to do the job without bringing it to the maximum might be available mid summer 2011. Hey, this will give me the time to finalize my round-the-world-in-smallest-hops-tour with FS9. :) A couple of friends and I started in March 2004 and in the moment we are in Ireland heading North in order to cross the Atlantic via Greenland on our way back to Cape Horn where we started (about). Pete, I don't question your experience at all but I decided for myself that I will wait until PCs are capable running FSX without having the need for a power plant in the garden and a mid-size river for cooling beside the house, too. :) - I'm kidding, of course.

Pete, take better care for your health as it is really not worth worrying about wishes like mine. Your contribution to the community for so many years now is incredible. However, it seems that the days of flight simming with MSFS are numbered anyway. I'm wondering how long it might take until the last of us old guys might give up. I decided not to upgrade to FSX as it seems that even the latest PCs are not able to run this program with all bells and whistles. My (grown-up) kids are astonished that I'm not upgrading my hardware anymore (as I did for many years regularly) but I feel that it's not really worth to do so now. All the best!

Hello Pete, Thanks a lot. After a run I've just made a brief cross check between both corresponding files, runways.txt and runways.xml, and it looks good. :D Hmm, may I quote myself? Ok, I'll do: Translating this it was intended to say, that I would still prefer to see in the XML surfaces like Macadam, Brick, Tarmac, Sand and so on as they are defined within FS9 airports (and in its SDK). If there is a reason to stick on the compatibility with former FS versions I'll take a back seat... unless it would be possible creating a second XML for FS9 without too much effort. Maybe this is a nice wish to be addressed to Santa? ;-) Pete, again: thanks for the excellent tool and your support.

Right! But it would be perfect if the strict FS9 reference would be used (like in the TXT file). Actually I could live as well with all the "UNKNOWN x" as I could make the translation with my own little tool that I'm using for creating ISG1 airport databases for different kind of aircraft. However, with your translations as above I could use my tool as it is (I would only have to beg my lovely wife on my knees for changing it because I'm still no programmer ;-)).

Ok, I'll try. It's just the translation between some unknown surface codes and their appearance (at least in my FS9 installation). This should not be done in the TXT file (as I personally like the strict reference to the officially defined codes) but in the XML-list which you secondly translated again for the sake of compatibility with previous FS versions. NEW TYPE Appearance (FS9) proposed OLD TYPE (quite unsatisfying for planks and bricks) "CONCRETE", // 0 concrete 2 concrete "GRASS", // 1 grass 4 grass "WATER", // 2 water 10 water "UNKNOWN 3",// 3 grass 0 unknown "ASPHALT", // 4 asphalt 3 asphalt "UNKNOWN 5",// 5 grass 4 grass "UNKNOWN 6",// 6 grass 4 grass "CLAY", // 7 clay 1 dirt "SNOW", // 8 snow 8 snow "ICE", // 9 ice 8 snow "UNKNOWN 10",// 10 concrete 2 concrete "UNKNOWN 11",// 11 concrete 2 concrete "DIRT", // 12 dirt 1 dirt "CORAL", // 13 coral 9 coral "GRAVEL", // 14 gravel 5 gravel "OIL_TREATED",// 15 oil-treated 6 oil-treated "STEEL_MATS",// 16 mats 7 mats "BITUMINOUS",// 17 bitumious 3 asphalt "BRICK", // 18 brick 0 unknown "MACADAM", // 19 macadam 3 asphalt "PLANKS", // 20 planks 0 unknown "SAND", // 21 sand 5 gravel "SHALE", // 22 shale 5 gravel "TARMAC", // 23 ashalt 3 asphalt "UNKNOWN 256", // 256 unknown 0 unknown Just as a reminder the pictures showing the context in FS9: Of course I would prefer throwing the compatibility over board or (maybe even better) having a XML-version just for FS9 that translates the originally not defined codes to the surface which appears in the application. :roll: :mrgreen:

Hello Pete, May I come back to our conversation we had about Make Runways a while ago? We discussed about some differences in translations of runway surface codes. As I have learnt some are caused for the sake of compatibility to versions older than FS9 and others are caused by AFCAD2 obviously allowing UNDEFINED codes to be used that have been named to things like "GRASS 3" or so. However, today there are tons of AFCAD2 BGLs in the wild using surfaces being textured in an originally unintended way (and quite a lot are coming with payware, too). Concluding this you wrote (on Tue Aug 11, 2009 12:27 pm) I would be really thankful if you could bring in the translations - - - this year? After thinking it over there seems to be no need to change the TXT log file. There are other design tools that might do different things and AFCAD2 seems to be like an abandoned child now.

Hello Pete, Sometimes it takes a bit longer... However, meanwhile I made some more research an found out that PMDG obviously is using the TCAS gauge (of Lee Hetherington that can principally two different interfaces, one to FSUIPC and as an alternative to TrafficInfo of MS. Yesterday I was able to verify, that the latter is working, indeed and I have no idea why it didn't in my tests before when switching the multilplayer mode to FS2004 in the PMDG options. Anyway, thank you very much since you gave me the push for searching the right keywords. :D Regards, Axel

Hello Pete, Obviously there is no way tracking the traffic via FSUIPC as it doesn't show up in TrafficLook --> no TCAS display in PMDG aircraft. :( Does AIBridge "inject" remote traffic in a way that makes it visible for FSUIPC? Today I had no chance bringing AIBridge to connect as I'm running FS normally with restricted user rights and AIBridge failed passing the Windows Firewall. Well, I did not want to make my buddies waiting any longer so I have to prepare this one a bit better next time. Anyway, thanks for the hints. Regards, Axel

Thanks for the hint. I'll try it out latest on Sunday and will report the results. Yes I know. I thought about a sort of "misguided communication". Thanks Pete. Regards, Axel

Hi all, Maybe here somebody can give me a hint regarding a problem that I posted in the PMDG forum at the end of July without getting any response up to now. For quite a long time now some of my buddies and I are flying connected via FSHOST and Teamspeak around the world (zigzagging with a couple hundred legs now). I have no problem watching them in any TCAS system (freeware or payware) except in those of my PMDG B737-800/900 and as well the of my B747-400 (both in CD version with all updates available). I tried the settings in either mode (FS2004 and FSUIP, the latter I found recommended in PMDG OPS) in the PMDG options menu but without any success. Off-line all the AI traffic is visible as it should. I'm not using VATSIM & Co so I cannot judge how it works with those networks. Question: is there anything in the interface which might work different when using FSHost compared to other online networks? BTW, I'm using a registered FSUIPC and mostly a recent version. It's nothing that really hurts as we are using FSNAV as well where the traffic is shown (BTW, could this be the reason, as FSNav opens a second communication channel from inside FS2004? I can try this next Sunday), just a question whether it should work or not. Regards, Axel

That's the question, indeed! Maybe because they are offered by AFCAD. I worked on a some airports by using AFCAD myself and at least GRASS2 and GRASS3 somehow suggested that it might look a bit different to the "standard" GRASS (it doesn't). Obviously even designers of payware (I'm thinking e.g. on "MyTraffic") used the GRASS2 surface in their MyWorldAirports collection. Meanwhile (due to the fact that I have more time on my hands as usual ) I edited the respective files and the only UNKNOWN's left are those of the type "254" which have good reasons for their existence. However, your XML file is an excellent starting point (as it is, I think I wrote it already) and I thank you very much for your efforts. Regards, Axel

Hello Pete, Maybe a "tranlator" for AFCAD once in the header of the "Runway.txt" might be sufficient and could contain as well a remark regarding "UNKNOWN 254". :idea: It would be even satisfying if all this stuff would be in the right context part of the ReadMe. Regards, Axel

Hello Pete, Sorry for being too brief - I've had a bike accident a couple of days ago and broke my left clavicle. Now I have only one hand left for treating mouse and keyboard. :( I first created a new airport in AFCAD and defined a couple of runways ("insert runway") each with a rotation of 10 degrees around its centre. Then I defined the first two of them with common surfaces (Rwy 36 -> Concrete, Rwy 01 -> Grass). Then I defined the next (all from AFCAD's pull-down menu) with all the "doubtful/uncommon" surfaces: Rwy 02 -> Unknown, Rwy 03 -> Grass2, Rwy 04 -> Grass3, Rwy 05 -> Unknown2, Rwy 06 -> Unknown3. I did not add any other stuff like taxiways, aprons or starting points. Then I looked after the results and that might answer your next question: As I wanted to see the way it was decoded I looked into the resulting BGL with a HEX-editor (what I never did before) and found what is documented in the following picture(s). Well, it's barely recognisable I guess. The HEX-figures are well corresponding with the "UNKNOWN nn" in your "Runway.txt". The only thing I did not find was anything that corresponds to "UNKNOWN 254". However, I opened such an airport with AFCAD (all are stock, as far as I saw it), an example is VA1S in India (contained in AP967230.BGL) having a 3610 x 75 runway, I found the runway surface blank (nothing filled in) which AFAIK cannot be achieved when creating something with AFCAD. The corresponding Hex-string is "FE 00 0E", bingo! The result is shown in the next picture, an existing but invisible strip: What I did not was testing with any other sim besides FS2004. However, hopefully this was filling the gaps in common understanding, though. Regards, Axel

Hello Pete, Just to bring it to the big final, only if you or anybody else is interested: I made some trials in the middle of nowhere by using AFCAD2 to create a fictive airport just having two known runway surfaces, concrete and grass and those which are not in the official list you quoted above. Then I checked with a Hex-Editor the file and the results are shown above in red. The last listed officially, SURFACE_UNKNOWN --> 0x00FE seems to be used for airports without a visible runway strip. There is a (flattened) area and sometimes just a windsock (I'm not sure any more). Winfried Orthmann's de-compiler leaves the output just blank, and "SceneGenX Scenery Generator for FS2004" translates 0x0003, 0x0005 and 0x0006 to "GRASS" , 0x000A to "CEMENT" (all are appropriate I think) but 0x000B to "FOREST" :? which is wired (maybe FSX?). However, I can only conclude that I can live with the given mapping for my purposes and I like to thank you again for your efforts (and patience). Regards, Axel

Hello Pete, In the name of compatibility your choices are all right for me. I didn't realise those possible differences even knowing that we all are dealing with a Microsoft product line. :wink: I'm feel now somehow sheepish that I posted my stuff under an error headline, sorry for that. However, your remarks had been helpful and instructive, thanks. [LATER] Do you use public available BGL-analysers in order to handle the old file formats as well as the new ones? As far as I looked for such they all seem to have some limitations. Can you give me a hint? Regards, Axel

Hi Pete, Thanks foe your response. My little world is now in a better shape again :D I should have seen it myself. :oops: Oh my, I need holidays... Regards, Axel

Peter, There was no, absolutely no offence intended and it seems to me that you got that impression. I'm no native English Speaker and some what I have written might have led to misunderstandings. Without your tool I would have been lost and I'm happy if I could explain what I want to do after commenting some of your remarks (a few only): That's clearly stated and I did nothing else. Oops, I did not use my own converter but the results of your tool: first the XML output and then the TXT (reference) from the same run of MakeRunways. The differences between both of them where obvious. My intention is, to use the surface information as a filter for a tool (under development for my own use) that is able to create a database for at least one payware FMS with lacks many of the existing airports now. I wanted to get rid not only of "Water" but of some other types which a jet engine propelled aircraft should avoid in normal operation (e.g. "Sand"?). The FMC itself does not require this information and it will be not in the data as well. My understanding of "Macadam" is a that of of an unbound surface which could be quite dusty an where some material could be moved by prop wash or jet blast. "Tarmac" I understand as basically the same but bound by tar. BTW, I used Wiki as source as well. In most cases the seen differences would cause no harm to my intended filter, except the Macadam one. Peter, again: I used your XML as basis and I'm even no programmer at all, thus I'm not able to write my own routines for reading out the BGL's. However, thanks for giving further explanations. In my opinion your translations are correct for the (for reference use only) text file but not the same in the XML output. Example from "runway.txt": Airport GOSS N16:02:58.9822 W016:27:39.9993 10ft City Name="St Louis" Airport Name="St Louis" in file: Scenery\Afri\scenery\AP943260.BGL Runway 18 /36 centre: N16:03:00.9259 W016:27:40.0587 10ft Start 18 : N16:03:29.7245 W016:27:43.9661 10ft Hdg: 172.6 true Computed start 18 : Lat 16.058720 Long -16.462277 Start 36 : N16:02:32.0949 W016:27:36.1529 10ft Hdg: 352.6 true Computed start 36 : Lat 16.041794 Long -16.459980 Hdg: 172.570 true (MagVar -10.000), MACADAM, 6223 x 148 ft {snip} same from "runways.xml": St Louis St Louis -16.461111 16.049723 10 -10.000 6223 182.570 Asphalt 16.058720 -16.462276 {snip} This is an example from the "runway.txt" Airport VA1S N24:25:52.2931 E074:52:05.0010 1600ft City Name="Nimach" Airport Name="Nimach" in file: Scenery\asia\scenery\AP967230.BGL Runway 14 /32 centre: N24:25:52.3255 E074:52:05.0478 1600ft Start 14 : N24:26:04.7001 E074:51:53.6311 1600ft Hdg: 140.0 true Computed start 14 : Lat 24.434996 Long 74.864577 Start 32 : N24:25:39.9185 E074:52:16.4644 1600ft Hdg: 320.0 true Computed start 32 : Lat 24.427408 Long 74.871568 Hdg: 140.004 true (MagVar 0.000), UNKNOWN 254, 3610 x 75 ft ;here the comma is missing, following the syntax of all other materials {snip} Peter, it seems that I did not make a friend with my posting. Please take it as a minor remark and forget about it if you like. Again, your tool is great for the intended use and I started using it for FS Meteo and for Radar Contact. It can be used even for my intended purposes. I only hope that my examples above might have clarified my original intentions. Regards, Axel P.S. You might contact me via email for further details.

Peter, There was no, absolutely no offence intended and it seems to me that you got that impression. I'm no native English Speaker and some what I have written might have led to misunderstandings. Without your tool I would have been lost and I'm happy if I could explain what I want to do after commenting some of your remarks (a few only): That's clearly stated and I did nothing else. Oops, I did not use my own converter but the results of your tool: first the XML output and then the TXT (reference) from the same run of MakeRunways. The differences between both of them where obvious. My intention is, to use the surface information as a filter for a tool (under development for my own use) that is able to create a database for at least one payware FMS with lacks many of the existing airports now. I wanted to get rid not only of "Water" but of some other types which a jet engine propelled aircraft should avoid in normal operation (e.g. "Sand"?). The FMC itself does not require this information and it will be not in the data as well. My understanding of "Macadam" is a that of of an unbound surface which could be quite dusty an where some material could be moved by prop wash or jet blast. "Tarmac" I understand as basically the same but bound by tar. BTW, I used Wiki as source as well. In most cases the seen differences would cause no harm to my intended filter, except the Macadam one. Peter, again: I used your XML as basis and I'm even no programmer at all, thus I'm not able to write my own routines for reading out the BGL's. However, thanks for giving further explanations. In my opinion your translations are correct for the (for reference use only) text file but not the same in the XML output. Example from "runway.txt": Airport GOSS N16:02:58.9822 W016:27:39.9993 10ft City Name="St Louis" Airport Name="St Louis" in file: Scenery\Afri\scenery\AP943260.BGL Runway 18 /36 centre: N16:03:00.9259 W016:27:40.0587 10ft Start 18 : N16:03:29.7245 W016:27:43.9661 10ft Hdg: 172.6 true Computed start 18 : Lat 16.058720 Long -16.462277 Start 36 : N16:02:32.0949 W016:27:36.1529 10ft Hdg: 352.6 true Computed start 36 : Lat 16.041794 Long -16.459980 Hdg: 172.570 true (MagVar -10.000), MACADAM, 6223 x 148 ft {snip} same from "runways.xml": St Louis St Louis -16.461111 16.049723 10 -10.000 6223 182.570 Asphalt 16.058720 -16.462276 {snip} This is an example from the RUNWAY.TXT Airport VA1S N24:25:52.2931 E074:52:05.0010 1600ft City Name="Nimach" Airport Name="Nimach" in file: Scenery\asia\scenery\AP967230.BGL Runway 14 /32 centre: N24:25:52.3255 E074:52:05.0478 1600ft Start 14 : N24:26:04.7001 E074:51:53.6311 1600ft Hdg: 140.0 true Computed start 14 : Lat 24.434996 Long 74.864577 Start 32 : N24:25:39.9185 E074:52:16.4644 1600ft Hdg: 320.0 true Computed start 32 : Lat 24.427408 Long 74.871568 Hdg: 140.004 true (MagVar 0.000), UNKNOWN 254, 3610 x 75 ft {snip} Peter, it seems that I did not make a friend with my posting. Please take it as a minor remark and forget about it if you like. Again, your tool is great for the intended use and I started using it for FS Meteo and for Radar Contact. Regards, Axel

Hello Pete, Being a satisfied user of some of your products for many years now, I recently searched the WWW for a tool listing all the airport and runway details being installed in my FS2004, in order to generate a database for some of my payware aircraft (mainly I'm missing quite lot of airports in ISG1). It was just bothering me flying around without being able to generate proper flightplans in my FMS. Not really surprisingly I tumbled over your MakeRunways (latest edition) and it worked like a charm (even if it took a while but, 125 MB for a resulting TXT-file is something, isn't it?). However, today I detected some minor differences between the content of the "Runways.txt" and the corresponding "runways.xml". I only found them because I wanted to filter the results by Rwy length and by opting out some runway surfaces (like water). Some examples: Runways.txt --> runways.xml (ICAO) SHALE --> GRAVEL (SWPB, SWMU) BRICK --> UNKNOWN (FTTU) BITOUMIOUS --> ASPHALT (GQPP, GQPA) SAND --> GRAVEL (GQPA) PLANKS --> UNKNOWN (VVDB); remark: after UNKNOWN in Runway.txt always a comma (",") is missing STEEL_MATS --> MATS (KNJM); not really wrong, however the MS BGLCOMP SDK says STEELMATS. BTW, same with OIL_TREATED --> OIL-TREATED, the SDK says OILTREATED ICE --> SNOW (NZPG) TARMAC --> ASPHALT (GOOY) MACADAM --> ASPHALT (GOSS); this could be (virtually) deadly for bigger a/c - and for anybody standing behind :shock: I would be happy if you could find out how to solve these issues. Kind Regards, Axel