Paul Henty

Let's take the first one as an example: 6485 3 BYTE x 3 LTS_LandingLights_Sw_ON[3] Booleans Left/Right/Nose These are Landing Light Switches. There are 3 of them. One for the lights on the Left, one for Right and one for the lights on the Nose. The length is BYTE so that's what you declare the offset 'Of'. The offset address is 6485. But because there are 3 lights, each 1 BYTE long, this is the address of the first (Left) switch. The Right switch will be 1 byte more = 6486. The Nose switch will be 1 byte more than that = 6487. They are Boolean values so expect values to be either = 0 (OFF) or >0 (ON) Here are the final declarations with colour coding so you can see how it fits together: Dim LTS_LandingLights_Sw_ON_Left As Offset(Of Byte) = New Offset(Of Byte)(&H6485) Dim LTS_LandingLights_Sw_ON_Right As Offset(Of Byte) = New Offset(Of Byte)(&H6486) ' (6485 + 1) Dim LTS_LandingLights_Sw_ON_Nose As Offset(Of Byte) = New Offset(Of Byte)(&H6487) ' (6485 + 2) Paul

Dim MCP_annunCMD_A As Offset(Of Byte) = New Offset(Of Byte)(&H6545) Dim MCP_annunCMD_B As Offset(Of Byte) = New Offset(Of Byte)(&H6547) Dim LTS_TaxiSw As Offset(Of Byte) = New Offset(Of Byte)(&H64FA) Dim LTS_AntiCollisionSw As Offset(Of Byte) = New Offset(Of Byte)(&H6501) Dim LTS_PositionSw As Offset(Of Byte) = New Offset(Of Byte)(&H6500) These lines must not be included in the pmdg737sk() method. As I said in an earlier post, they must go at the top of the module with the other offset declarations. If you leave them here your program will crash after a while. 'FSUIPCConnection.Process() This line is commented out so you'll never get any data back for these offsets. Otherwise, I cannot see any errors. I can't test this because I don't have the PMDG aircraft. Make sure you've added the line EnableDataBroadcast=1 to the 737NGX_Options.ini file. See the file 'Offset Mapping for PMDG 737NGX.pdf' for details. Paul

You should put them with all the other offset declarations at the top of that module. Paul

There are not much different to using normal offsets. Make sure you've changed the '737NGX_Options.ini' file as described in the document 'Offset Mapping for PMDG 737NGX.pdf'. For the information you wanted declare offsets as follows: Dim MCP_annunCMD_A As Offset(Of Byte) = New Offset(Of Byte)(&H6545) Dim MCP_annunCMD_B As Offset(Of Byte) = New Offset(Of Byte)(&H6547) Dim LTS_TaxiSw As Offset(Of Byte) = New Offset(Of Byte)(&H64FA) Dim LTS_AntiCollisionSw As Offset(Of Byte) = New Offset(Of Byte)(&H6501) Dim LTS_PositionSw As Offset(Of Byte) = New Offset(Of Byte)(&H6500) Use the values like this: FSUIPCConnection.Process() Dim autopilot_A As Boolean = MCP_annunCMD_A.Value > 0 Dim autopilot_B As Boolean = MCP_annunCMD_B.Value > 0 Dim taxiLights As Boolean = LTS_TaxiSw.Value > 0 Dim strobeLights As Boolean = LTS_AntiCollisionSw.Value > 0 If LTS_PositionSw.Value = 0 Then ' Steady ElseIf LTS_PositionSw.Value = 1 Then ' Off ElseIf LTS_PositionSw.Value = 2 Then ' Stobe and Steady End If Some of the offsets have values for multiple switches, e.g. LTS_LandingLtFixedSw. I assume there are two switches for landing lights in the 737 cockpit. For these just declare multiple offsets, increasing the offset address. e.g. 64F6 2 BYTE x 2 LTS_LandingLtFixedSw[2] Boolean Dim LTS_LandingLtFixedSw1 As Offset(Of Byte) = New Offset(Of Byte)(&H64F6) Dim LTS_LandingLtFixedSw2 As Offset(Of Byte) = New Offset(Of Byte)(&H64F7) Paul

I've tested it here and it works fine. Usually when Dictonary<> throws this kind of error it's a threading problem. Is the call to RefreshTrafficInformation() on a background thread? I see it originates from some kind of timer. If you can post the relevant code from your program it might help me see the problem or recreate it here. Thanks, Paul

Nice work Richard. It's amazing what you can do in Excel if you know how. Paul

The 2.4 release is only 32bit (x86) as far as I remember. I've attached the latest V3 Release Candidate I have which is a duel 32/64bit binary so it can run as either depending on the OS. This one target the 4.0 framework.If you need a different version let me know. FSUIPCClient3.0_RC1_NET4.zip

Attached. Paul FSUIPCClient3.0_RC1_NET4.zip

In 2012 a forum member called gr8guitar claimed to have the FSUIPC programming interface working in VBA inside Excel. I assume he ported the VB6 interface. Here's a link to the post were he says he got it to work... http://forum.simflight.com/topic/12740-fsuipc-vb6-users-need-help/?do=findComment&comment=441067 You may be able to contact him through the forum if you're interested in going that route. (Click on his name and send him a message). Paul

Hi Ruediger, I've tested the Disconnect() method here and it's working as expected. After you disconnect the offset, please check the IsConnected() method. I've attached the latest DLL in case the one you have has a bug. (It's built against the 4.5 framework. If you need a different framework version just let me know.) If you still have a problem check that the offset is only being created once during the lifetime of your application. Paul FSUIPCClient3.0_RC1.zip

The Example project that comes with the DLL has code to check if the player is on 27L at Heathrow. The DLL includes helper libraries to do all the geometry calculations for this. You'll need a database of runway locations, headings, widths and lengths etc. You could get this information from one of the many files produced by Pete's MakeRunways program. There is a class called FSLatLonQuadrateral which has a method to construct a rectangle from the runway information: FsLatLonQuadrilateral myRunway = FsLatLonQuadrilateral.ForRunway(thresholdCentre, trueHeading, rwyWidth, rwyLength); You can then check if the player is inside that rectangle with: myRunway.ContainsPoint(currentPosition) Where 'currentPosition' is an instance of FsLatLonPoint set to the current plane coordinates. For more details about these classes please see the Example Project (C# or VB.NET) and the UserGuide.pdf. Paul

This should be: labelCurrentHandle.Text = BitConverter.ToString(FSUIPCHandle.Value, 0); You are getting 2 bytes back from 0x0BFC (not sure why), but you only need the first one so that would be index 0. 1 is the second byte 0x0BFD. It would be easier to just declare the offset as a byte then there's no need to do any bit conversion. Offset<byte> FSUIPCHandle = new Offset<byte>("FSUIPCHandle", 0x0BFC); //Flaps handle for FSX, P3D. Paul

This line might be your problem: intAircraftDetente = intDetentes - (16383 / FSUIPCAircraftDetente.Value); You are doing a division with all integers so any decimal places are going to be lost. Trying doing the maths as doubles likes this to get a more accurate answer: intAircraftDetente = (int)((double)intDetentes - (16383d / (double)FSUIPCAircraftDetente.Value)); Paul

The year starts at offset 0x2040 which is 5 bytes in from 0x023B. So this line should be: short GMTYear = BitConverter.ToInt16(FSUIPCGMTDateTime.Value, 5); The day number is 3 bytes in: short GMTDayNo = BitConverter.ToInt16(FSUIPCGMTDateTime.Value, 3); Looks like you were counting the first 3 time offsets in that block as 2 bytes each. Paul

The dll only sends requests to FSUIPC. If FSUIPC cannot create AI Traffic then my client DLL cannot do this either. There is nothing I can do. I don't think Pete will ever add AI Traffic creation to FSUIPC. The main purpose of the FSUIPC4 data interface is to provide a way of running applications designed to work with FS9 and earlier to run with FSX and P3D. It is not a complete alternative to SimConnect. Many people still use FSUIPC because it's easier than SimConnect and they may also want their application to run with FS9. But if you chose FSUIPC, you cannot use some of the 'new' FSX/P3D SimConnect features like AI Traffic, and some of the camera controls for example. Sorry, no, for the same reason as above: FSUIPC cannot do this, so neither can my client dll. Paul

FSUIPC does not have any way of creating AI Traffic. Therefore, it cannot be done with the .NET Client dll. You have to use SimConnect to do this. Paul

Hi Ryan, If the MalAir installer has messed up your system you need to speak to their support. This forum is for .NET programming for FSUIPC. Paul

It looks like you're already doing the right thing in that regard. Whenever you call Process() you need to catch any FSUIPCExceptions that arise. The FSUIPCError.FSUIPC_ERR_SENDMSG error means the connection was lost because the flight sim closed or has crashed. When this happens you should also stop that particular timer ticking so you don't keep trying to process() on the bad connection. Once your app is 'paused' you can either provide the user with a way to reconnect manually, or if you want it more automatic, have another timer (maybe every 2-5 seconds) that keeps trying to open the connection again. When it's successful (i.e. Open() didn't throw an Exception) you can stop that timer and start the main one again. Paul

This is puzzling. The last successful group that was process()ed before the crash was "~SystemOffsets~". This group is only used internally in the DLL during the Open() connection process - i.e. calling FSUIPCConnection.Open(). I would not have expected to see this after 10 mins of operation because normally you just Open() at the start of the application and Close() at the end. I see from the stack trace you are opening this form from another form. Has any other form previously opened the FSUIPC connection? If so you don't need to open it again on this form. Once it's open it's open everywhere as it's a static class. At the moment I suspect there's some problem involving opening the connection too many times or maybe another thread is trying to open it at the same time as this form is trying to Process(). I'll be happy to take a look at your code if you don't mind sending me the whole project. It might be easier if I can debug it and my DLL here. Just attach it in a private message or send me a link. Otherwise, try and find out where the Opens are being called, or maybe paste some code snippets of the FSUIPC Open()s, and the code that opens the various forms. Paul

Thanks for the call stack, I can see where the problem is now. I can't figure out why though. The DLL is trying to write to the FSUIPC shared memory file but it's being refused. It's the same memory area every time so I can't see why it's going wrong after 20 mins. My only guess at the moment is that the file is overflowing somehow. Can you get some more info for me... when this exception is thrown and it drops into debug mode, can you paste the following into the Immediate window and press return. Then show me the resulting lines. FSUIPCConnection.Statistics.processLast Thanks, Paul

Your code looks fine. Please can you try again with the attached DLL. I've included the debug file (.pdb) which should also be extracted and placed in the same folder as the DLL. When you get the exception again, this should now give at least the line number and file name from the DLL source code in the exception details. Ideally I'm looking for a full call stack that contains all the internal calls in the dll. Can you paste the exception info here with the call stack. I'm not really sure where in the Process() method this could be happening at the moment. Thanks, Paul FSUIPCClient3.0_RC1.zip

Hi Andrew, What version of the DLL are you using? (You can check the properties of the DLL in the windows explorer). Also can you confirm you are declaring the Offset variables at the Form (class) level and not in updateInfoTimerTick(). Paul

Thanks for the comments. I've decided that my DLL should really be getting global weather using 'GLOB' from the CC00 area. Even if C400 worked it would probably be the wrong thing as this is just the last weather written, not the current weather. Since CC00 is returning the correct values my user is happy now. Paul

Hi Pete, Here are the lines from the log with the weather logging turned on. This is my set global weather request with the three wind layers. 362953 WX Received in (0 mSecs), WX request type 1, ICAO=GLOB 363422 NW_GLOBAL command, setting weather to global mode 363687 NW_SET weather command received, ICAO=GLOB 363687 >NewSet: **** New Weather being set: ICAO=GLOB (Dyn=0) 363687 >NewSet: Pressure=1013.0, Drift=2.0 363687 >NewSet: Visibility[0]: range=62.1sm (100005m), from=-1460ft, to=8530ft 363687 >NewSet: Temperature[0]: alt=0ft, Day=14 C, NightVar=3 C, DewPt=4 C 363687 >NewSet: Surface wind: to alt=3280ft AMSL, dir=0T, vel=10.00, gust=0.0, turb=0, shear=0, var=0.0 363687 >NewSet: Wind layer 1: to alt=6560ft AMSL, dir=270T, vel=20.0, gust=0.0, turb=0, shear=0, var=0.0 363687 >NewSet: Wind layer 2: to alt=9840ft AMSL, dir=0T, vel=30.0, gust=0.0, turb=0, shear=0, var=0.0 363687 >NewSet: Cloud[0]: type=9, from 5700ft to 15700ft (+/- 400ft), cover=2, turb=2, topshape=0 363687 >NewSet: Precip=0, base=0ft, rate=0, icing=0 363687 >NewSet: Cloud[1]: type=1, from 39300ft to 40940ft (+/- 20ft), cover=6, turb=0, topshape=0 363687 >NewSet: Precip=0, base=0ft, rate=0, icing=0 363687 >NewSet: **** End of New Weather details for ICAO=GLOB 363687 Setting Weather: "GLOB 051136Z 00010KT&D1000NG 27020KT&A1000NG 00030KT&A2000NG 100KM&B-448&D3048 2CU057&CU100FMVN000N 6CI393&CI016FNVN000N 14/04&A0 Q1013 " 364094 >Change: Wind layer 1: to alt=6560ft, dir=270T, vel=20.0, gust=0.0, turb=0, shear=0, var=0.0 364094 >Change: Wind layer 2: to alt=9560ft, dir=0T, vel=30.0, gust=0.0, turb=0, shear=0, var=0.0 364094 Results: FS98 Wind1: 3280ft to 6560ft AMSL, dir=270T, vel 20, gust 0, turb 0 364094 Results: FS98 Wind2: 6560ft to 9560ft AMSL, dir=0T, vel 30, gust 0, turb 0 After that I get these two blocks repeating in the log until it's closed: (The plane is parked at EGJJ). 364094 Weather Received (type 5 request, Nearest): "EGJJ&A84 051134Z 00010KT&D1000NG 27030KT&A1916NG 00020KT&A2833NG 100KM&B-532&D3048 2CU054&CU004FMVN000N 6CI390&CI000FNVN000N 14/04 Q1013 @@@ 66 14 270 30 | 96 14 0 20 | " 364094 WX Received in (0 mSecs), WX request type 5, Lat=49.2070, Lon=-2.2066, Alt=0.0m 365109 Weather Read request (Global set) to area 1: ICAO="GLOB", Req=0 365109 Weather Received (type 1 request, (null)): "GLOB&A0 051136Z 00010KT&D1000NG 27020KT&A1000NG 00030KT&A2000NG 100KM&B-448&D3048 2CU057&CU010FMVN000N 6CI393&CI001FNVN000N 14/04 Q1013 @@@ 33 14 270 20 | 66 14 0 30 | " 365109 WX Received in (0 mSecs), WX request type 1, ICAO=GLOB For completeness, here are the results of the IPC Reads from the two weather areas: (Just up to the wind layers where you can see the problem in the second one from C400) 281641 0 ReadLocal: Offset=C000, Size=0400 00 00 00 00 00 00 00 00 47 4C 4F 42 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 51 00 C9 07 50 3F 00 00 28 0A 40 FE 46 18 00 00 01 00 00 00 00 00 0E 00 00 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 00 00 00 E8 03 0A 00 <- Layer 0 00 00 00 00 00 00 00 00 00 00 00 00 D0 07 14 00 <- Layer 1 00 00 00 C0 00 00 00 00 00 00 00 00 62 0B 1E 00 < - Layer 2 263937 0 ReadLocal: Offset=C400, Size=0400 00 00 00 00 00 00 00 00 47 4C 4F 42 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2C BD C8 07 50 3F 20 00 28 0A 40 FE 46 18 00 00 01 00 00 00 00 00 0E 00 03 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 00 00 00 E8 03 0A 00 <- Layer 0 - OK 00 00 00 00 00 00 00 00 00 00 00 00 E8 03 14 00 <- Layer 1 - Duplicate E8 03 00 00 00 C0 00 00 00 00 00 00 00 00 D0 07 1E 00 <- Layer 2 - Altitude from Layer 1 not 2 Paul

Reading the docs again I saw that you can get global weather from 0xCC00 using "GLOB" as the ICAO. This works fine. I could change my DLL to use this method for getting the global weather rather than 0xC400. Is the difference that C400 is what was last written and CC00 is the current state of the global weather which could be different because of dynamic weather? If that's the case I'm probably wrong to be using C400 in any case. Paul