skydriver

Hi Pete: Thanks again from all of us for all your great work done with FS over many years! :rolleyes: My question this time is: Is it possible to determine which set of airport data is actually used by FSX from Makerwys.exe output? I'm looking at output from a PC which runs FSX and there are 3 installed sets of data on it for, as an example, EGFF Cardiff Wales. The first listed in the "Runways.txt" file output by Makerwys.exe is the standard Microsoft FSX version. "in file: Scenery\0501\scenery\APX47130.bgl" The second is the add-on from UK2000: "in file: C:\Program Files (x86)\Microsoft Games\Microsoft Flight Simulator X\UK2000 scenery\UK2000 Cardiff Xtreme\scenery\EGFF_AFX_UK2xGEN.BGL" The third and last is the add-on from Just Flight: "in file: JustFlight\Traffic360\AirportFacilities\scenery\AFX_EGFF.BGL" The key point is that on the PC in question it is the 2nd set of data which is actually shown when at that airport. I can see that the 2nd and 3rd sets of data are preceded in the "Runways.txt" file by log statements showing "Deletions check for Airport EGFF:" and this appears to be done as part of the process of the new airport definition that is about to be listed in the "Runways.txt" file. So this is done right before the listing of the UK2000 airport and also right before the listing of the Just Flight airport. I can understand that a previous definition would be deleted before a new one is added - but is it all possible to determine which one the pilot will actually see when at the airport? My point is that on this PC at least it is not "the last one" - not that anyone said it should be! :neutral: I'd love to know what you think and if there is any way to tease this from the information - or indeed from the information in any of the other files output by Makerwys.exe Final note - I also looked at runways.csv and in it there is only one listing for the runways at airport (a total of 2 lines for the 2 runways). Interestingly the data it shows is not that for the UK2000 airport which is shown when actually using FSX. For example one runway is listed as: EGFF,0120,51.401344,-3.358387,220,121,7712,110.70 and this matches, for example, the latitude for the runway in the Microsoft and Just Flight data in the "Runways.txt" file output by Makerwys.exe as shown in *** Runway *** EGFF0120 Lat 51.401344 Long -3.358387 Alt 220 Hdg 121 Len 7712 Wid 151 ILS 110.70, Flags: GS DME BC but it is different from the latitude for the runway in the UK2000 data in the "Runways.txt" file output by Makerwys.exe as shown in *** Runway *** EGFF0120 Lat 51.401314 Long -3.358579 Alt 220 Hdg 114 Len 7726 Wid 180 ILS 110.70, Flags: GS DME And help is much appreciated! Thanks for your time. - Skydriver

I am looking at the data output by v 4.63 right now - fantastic - many, many thanks! :)

Thanks Pete!

Hi Pete: Firstly - thanks for all the great software! I wonder if you can help? I am using FSX SP2 (FSX Deluxe 10.0.61472.0 FSX-SP2.20071210-2023) with the excellent Makerwys.exe (v 4.6.2). I am intrigued as from what I can see, the airport "State" is missing in many cases for the USA, Canada and Australia. Around 50% for USA, 30% for Canada and 12% for Australia. This is in both runways.txt and runways.xml. The system being tested has perhaps a dozen add-on airports and Just Flight Traffic X, but no other terrain or scenery modifications. I've looked up several airports within FSX (using the Select Airport dialog) to make sure it knows the "state" of the airports in question and they all appear to be there. I was thinking that perhaps there is something slightly different about the format of the FSX data for these airports...? I took a quick look at the same output from FS2004 with makerwys.exe 4.6.2 and it exhibited a similar effect. I wondered if you find the same in your own data and if anything can be done - I can imagine that working on Makerwys is not something at the top of your list of things to do. :) Here are some examples from runways.txt: Airport 48MN :N43:46:14.8372 W093:35:20.7905 1210ft Country Name="United States" City Name="Freeborn" Airport Name="Jacobsen" in file: Scenery\0202\scenery\APX23160.bgl Runway N-S /S-N centre: N43:46:21.5752 W093:35:20.1870 1210ft Start N-S : N43:46:10.1400 W093:35:21.2926 1210ft Hdg: 4.0T, Length 2400ft Computed start N-S : Lat 43.769375 Long -93.589261 Start S-N : N43:46:33.0104 W093:35:19.0829 1210ft Hdg: 184.0T, Length 2400ft Computed start S-N : Lat 43.775944 Long -93.588626 Hdg: 4.000 true (MagVar 4.000), Grass, 2400 x 80 ft *** Runway *** 48MN0370 Lat 43.769375 Long -93.589264 Alt 1210 Hdg 0 Len 2400 Wid 80 *** Runway *** 48MN0410 Lat 43.775944 Long -93.588623 Alt 1210 Hdg 180 Len 2400 Wid 80 FSM A/P 48MN, lat=43.770790, long=-93.589111, alt=1210 Airport 85MN :N44:09:30.8709 W092:12:07.6073 1175ft Country Name="United States" City Name="Plainview" Airport Name="Christison" in file: Scenery\0202\scenery\APX23160.bgl Runway N-S /S-N centre: N44:09:30.8709 W092:12:07.6073 1175ft Start N-S : N44:09:19.8892 W092:12:08.1402 1175ft Hdg: 2.0T, Length 2300ft Computed start N-S : Lat 44.155426 Long -92.202264 Start S-N : N44:09:41.8202 W092:12:07.0747 1175ft Hdg: 182.0T, Length 2300ft Computed start S-N : Lat 44.161728 Long -92.201957 Hdg: 2.000 true (MagVar 2.000), Grass, 2300 x 50 ft *** Runway *** 85MN0370 Lat 44.155426 Long -92.202263 Alt 1175 Hdg 0 Len 2300 Wid 50 *** Runway *** 85MN0410 Lat 44.161728 Long -92.201958 Alt 1175 Hdg 180 Len 2300 Wid 50 FSM A/P 85MN, lat=44.158577, long=-92.202110, alt=1175 Many thanks for your time and efforts!

Pete - have you had time to work on the layout? Sounds like a fascinating alternative to a 'digitally' (as in Hornby etc) controlled railway.

Hi there Jim: You just need to copy and paste the registration codes given by Pilot Shop into the 4 fields at the credits screen of the FSIA program. Remove all brackets or commas separating the 4 fields so that a key like this (this is not a real key of course): (25224472) (52647544) (26465255) (0624-4340-C37D-F5C1-9900) is copied and pasted like this: 25224472 52647544 26465255 0624-4340-C37D-F5C1-9900 That's all you need to do. ;)

My friends and I were wondering if MS will at least have 'Flight' able to read FSX * data * such as aircraft and airports, even if it will not provide a means for developers to write add-ons for it which actually read and write realtime data. Glad you enjoy it! Didn't know you were a model railway man. Excellent! Which gauge? Digital locos? Pictures...? :) - Skydriver

Hi Pete: First - many thanks from all of us for all your great work done with FS over many years. My question is simply: do you have plans to support Microsoft Flight with a version of FSUIPC? Or... is there not enough information from MS yet for you to make the decision, or have you had enough of all this hard work?! Very interested to hear your ideas. Thanks for your time. - Skydriver

Pete: Many thanks for the fast reply - this is very useful information. Will look for alternative keys. All the best as always -

Hi Pete - great support - what a product! A question - I am having problems reading keystroke combinations in my software using FSUIPC's key mapping facilities only when the FSX ATC Window is on the screen. No problems reading them just fine when it is not on the screen and no problems at all in FS2004 or FS2002. I wondered if you'd experienced anything like this? Thanks for your time -

Pete: Thanks for the reply - have reported to MS.

Pete: A little puzzle (I am puzzled) with aircraft lights: In FS2004 and FSX, offset 0794 (4) "Strobes available" produces a value of 1 for the standard DC3 supplied with FS. As far as I can tell, there is no switch for strobes in the DC3 supplied, and I cannot see any on the exterior of the aircraft. Erm - not sure if the real DC3 has strobes, but I did find a reference to them as an 'extra' feature on the web. In FS2004 and FSX, offset 0D0C (2) "Lights" will tell you if the strobes are on or off, and the user can toggle this by pressing the 'O' key to toggle the str'O'bes. So... it appears that FS itself is convinced that the DC3 has them, even though they have no effect. Or - something like that... :roll: What are your thoughts?

Thanks as always for the help! :D

Pete: Thanks again! I saw mention of offsets such as: "0328 4 Pressurisation dump switch (1 = open, 0 = closed) " recently on this forum which as far as I can tell are not in FSUIPC4 Offsets Status.pdf - Jan 25 2007 (from FSUIPC4_partial_SDK_407.zip) Are they referenced in a different document or too new to be in such a document yet, or undergoing testing, etc?

Pete: Sorry - I am away from my usual PCs and need the current list of FSUIPC 4 offsets pleeeease... Can't recall where I got them! I recall FSUIPC4 Offsets Status.pdf and FSUIPC for Programmers.doc, but am note sure what the current file is for FSUIPC 4 or where to download it. Could you point me in the right direction? Many thanks for your time.

I'll post elsewhere, but thought I might as well mention it here too, seeing as we've been discussing it... The modification was made to the .xml file inside the .cab file in the panel folder for the aircraft, that is: C:\Program Files\Microsoft Games\Microsoft Flight Simulator X\SimObjects\Airplanes\B737_800\panel\B737_800.cab Edited: overhead_popup.xml Just take the sections for "Left Landing Lights" and "Right Landing Lights" and replace them with the code shown below. Be sure NOT to change the "Left Landing Lights - Retract" or the "Right Landing Lights - Retract" code. The .cab file can be rebuilt with the likes of cabdir.exe, etc. Easy...! :( 94.000,431.000 0.000 1.000 0.000 True 1.000 True 124.000,444.000 0.000 1.000 0.000 True 1.000 True

Well - ya got me goin' Pete... I've just now fixed it on my system - would be happy to share it, but feel a bit funny about sending edited Microsoft files around the world - I am sure they'd take a dim view of that... :( I guess I could tell MS how to fix it! :D

Yes - the visual switches as shown in the VC and 2D views.

Pete: I just wanted to mention something which other simmers may have encountered, which may be related to a query I made a few weeks ago on this forum. I've done extensive work with with FSUIPC in FSX and was concerned about reports of incorrect readings regarding aircraft lights. In the course of my investigation I have found that the FSX Boeing 737-800 appears to have a bug. The left and right inboard landing light switches appear to be reversed from what they should be doing. The landing lights are on when the switches are off, and vice versa. Pressing L toggles all lights, but the left and right inboard landing light switches go off when the others go on and vice versa. I have found this effect to be consistent on several PCs. I wonder if others have also witnessed this? The main point I wanted to make is that this is unrelated to FSUIPC - the FSX plane is simply not working correctly. Thanks for your time.

Pete: Many thanks for the fast reply - am working on getting more data from my users and will then update this thread. Thanks! Skydriver

Pete: Thanks as always for the great work on a fine product. I wondered if you'd come across anything that might help resolve the following puzzle... I'm working on detecting landing, taxi, beacon and strobe lights, being on or off, and have this working fine in 2004 and FSX, but have received some reports of my logic not working with regard to strobe lights, in both 2004 and FSX, with the standard Cessna 172. As yet I have no information on whether this issue occurs with other aircraft. I am using the 2 byte value at offset 0D0C. The reports I have received state that my logic is saying that the strobes are off even though the users have them on. I cannot replicate the problem - always works for me running 2004 on XP and FSX on XP, regardless of which combination of landing, taxi, beacon and strobe lights I flip on and off. I have asked the good people who generated these reports to turn on the FSUIPC logging display so they can report to me the values in the offsets which apply to the lights. I note that the c172 has a single switch for "BCN/STROBE", but as I say, regardless of this, this all works fine when I test it myself. I have no reason to doubt the accuracy of the reports I have received, especially as they were blind tests, in which the users had no reason to draw attention to incorrectly reported strobe lights... So - this post does not contain all the information I would have liked to include in such a query, but I just wondered if you'd come across any similar problems? Thanks for your time - Skydriver

Pete, I'm using the following values over 2000: CONST VOR1Identity = 0x3000 CONST VOR1Name = 0x3006 CONST TRAILING_EDGE_LEFT_FLAP = 0x30F0 CONST TRAILING_EDGE_RIGHT_FLAP = 0x30F4 CONST FS_COM2_FREQUENCY = 0x3118 CONST AGL = 0x31E4 CONST SURFACE_TYPE = 0x31E8 CONST ATCFlightNumber = 0x3130 CONST ATCTailID = 0x313C CONST ATCAirlineName = 0x3148 CONST ATCAircraftType = 0x3160 CONST HOTKEY_READ_DATA = 0x320C CONST AltimeterReading = 0x3324 CONST READY_TO_FLY = 0x3364 CONST IN_MENU_OR_DIALOG = 0x3365 CONST ZERO_FUEL_WEIGHT = 0x3BFC CONST CURRENT_AIRCRAFT_PATH = 0x3C00 CONST CURRENT_AIRCRAFT = 0x3D00 I understand why you're trying to cut down on the messages from FSX in order to speed up FSUIPC, but this completely breaks backwards compatibility! One of the huge advantages FSUIPC provides for developers is that it acts as middleware, shielding us from any changes MS makes in new versions of FS 8) Good luck!

Ah. As part of the changes I've been making to speed up FSX when FSUIPC4 is installed, I tell SimConnect not to send changes of less than some specified significance. The Flap angles at 30F0 and following are in degrees x 256, but I don't currently get notified of changes of less than a degree. I can change that, but it seems excessive to be notified of every change of 1/256th of a degree. I'll change these to be more accurate, but can you tell me what you need these for, exactly, and why a value of 17 (representing about a sixteenth of a degree) is a problem? There may be many other variables like this, but I have no idea who uses what and how. The more traditional (since FS98) flap indications down at 0BE0 etc are working okay. Regards Pete Pete: Thanks for the information - the project I am working on looks for a reading of zero to indicate: "The flaps are up". From this - the application takes various actions based on the aircraft "Having its flaps up". A non-zero value throws this off as you can imagine. At other flap settings, similar actions are taken, based on the flap setting in degrees. The settings in degrees are handy as it is not necessary to perform any other calculations to determine this from a proportion of the overall flap range. This all works great with 2004. Thanks for your help!

Pete, It's working in v4.063 - Thanks! However, I seem to be having a problem with the flaps (0x30F0) compared to FS2004. They don't seem to return to 0 (instead they go to approx 17). Has anyone else experienced this? :?

Pete, I've just found the same problem! Should have checked the forum 1st :shock: Will you be able to fix the value in 0x0842 before your next release? All of my FS2004 code is using 0x0842 and I would like to continue using it in FSX :D