Paul Henty

Hi Pete, There seems to be a problem writing AI traffic in FSUIPC 4 (currently installed version 4.534) using offset 0x1F80. The FSX Status document says it's OK but it's doing some weird stuff. If I run the code on my FS9 setup it's OK. Here's a pic of TrafficLook with my 2 injected planes at the top - Paul1 and Paul2: If switch the wideclient to my FSX machine and run the same code I get this: G-TEXR was one of the AI generated by FSX. After this happens FSUIPC4 also stops responding to any IPC requests. Can you have a look at this please? Thanks, Paul

There's nothing in my DLL that will add any delay or jerkyness to the data. The exchange of data between the DLL and FSUIPC follows exactly the C SDK and is mostly done with unmanaged code. I think Pete is right about the need for interpolation code. Many years ago I did some work on an external panel that I wrote in DirectX. It too was visibly 'stepping' until I added some smoothing code to it. The problem you've got is that the values from FS only come at a fixed interval which is generally not small enough to make a gauge look really smooth. You need to update the gauge state more often than you get the data back. That way you can fill in the gaps between the data points making your gauge look smooth. Paul

Mark posted in this forum a few weeks ago. See the last post of this thread... http://forums.simflight.com/viewtopic.php?f=54&t=77011 You may be able to contact him via the private message (PM) or email button. Paul

Hi Andi, I'm Paul - I wrote the .NET client DLL. There is no 'connected' property you can check. There isn't much to be gained by adding one in either. The only way you can get an 'open connection' is by calling FSUIPCConnection.Open() and your code must make this call. Therefore, you can keep track of if you've opened the connection or not yourself. The same goes for the Close() method. If you're looking for a way to tell if Flight Sim has been shut down after you've called Open() then the correct way to do this by catching the exception thrown from the read. This is how things are done correctly in .NET programming. The only way my DLL could tell if the connection is still established is by doing a 'fake' read and catching the exception, so there's not much to be gained by building this into a 'connected' property. I hope this explains why there isn't anything like a 'connected' property you can check. If you need any more info just ask... Paul

Thanks Pete - it's all working now. Ah, WideClient has logging too. I'd better go read the docs. :oops: Regards, Paul

Hi Pete, I've been trying to use the FSUIPC facilities for 'Reading full AI Traffic identity strings' at 0xD000. This is for FSX, using FSUIPC version 4.520. I can't get this to work. I keep getting back 48 zeros. I'm think I'm doing everything right as described in the documentation, although I note it says this is untested in FSX and requires feedback. Maybe this isn't working? Here is the log of an attempt in case I'm doing something daft: ********* FSUIPC4, Version 4.520 by Pete Dowson ********* User Name="Paul Henty" User Addr="paul.henty@" FSUIPC4 Key is provided WideFS7 Key is provided [Continuation log requested by user] Running inside FSX (using SimConnect Acc/SP2 Oct07) Module base=61000000 Wind smoothing fix is fully installed 536828 System time = 23:24:25, Simulator time = 17:27:56 (16:27Z) 536828 LogOptions changed, now 00000000 0000000D 546891 WRITE0 D004, 4 bytes: 01 00 00 00 .... 546891 READ0 D008, 4 bytes: E9 FB E9 01 .... 546891 WRITE0 D00C, 4 bytes: 0E FE FF FF .... 546891 WRITE0 D000, 4 bytes: 10 10 00 00 .... 546891 READ0 D008, 4 bytes: D6 D9 EA 01 .... 546891 READ0 D010, 48 bytes: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 546891 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 546891 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 702781 Sim stopped: average frame rate for last 166 secs = 18.4 fps 708969 LogOptions changed, now 00000000 00000001 Also, I had to generate this log by running my app on the FS computer. I usually develop on a different machine via WideClient, but the log wouldn't record any IPC reads I made via WideClient. It did log the IPC writes OK though. I'm using WideClient.exe version 6.7.8.0. Thanks for your help, Paul

OK, thanks Pete. Paul

Hi Pete, Your trafficlook program displays the magnetic heading of the AI planes. As FSUIPC only gives the True heading, are you assuming that the AI planes have the same magnetic variation as the player? Or is there something more cunning going on there? thanks, Paul

Hi Corry, You were on the right track with the Byte[]. In a nutshell you need: Read the housekeeping headers to find the number of slots in use and which have changed. For each slot that's changed, work out the offset of the slot in the two large AI data tables. Read the slot data into a byte array. Decode the raw bytes in the byte array into usable .NET variable types. The last stage requires decoding the relevant bytes in the Byte array using the BitConverter class and some ASCII string decoder classes for the string types. It's all pretty complicated to be honest. However... I have an unreleased 1.4 version of the DLL that lets you get access to all the AI in a really easy .NET way. The AI traffic is presented as a collection of AIPlaneInfo classes. You can just access each plane as a class and get its properties. There are also properties that aren't provided by FSUIPC like distance and bearing from the player. You can also filter the traffic tables to ignore planes over a certain distance or altitude etc. The reason it's unreleased is I've not done the documentation yet and no one has tested it (except me). I'll be happy to PM you the 1.4 version with some example code if you want to try it and let me know how it goes. If you prefer to do it yourself I can help you some more, but be warned that the AI code in the DLL runs to nearly 500 lines. ;-) Let me know what you want to do. BTW, if there is anyone else reading this who wants to try the new AI traffic features, just send me a PM. Paul

If the gauges are for your use only, then you can use the 64 byte 'General Use' block from 66C0. (See SDK documentation). If other people are going to use your gauges (Freeware or Payware) then you should apply to Pete to allocate you the number of offsets you require. He's away until June 30th though. Paul

The email address (and your name) used to register both FSUIPC and WideFS need to be identical. If you bought the licences at SimMarket and used different email addresses, Pete usually advises that you raise a 'problem ticket' with SimMarket and explain what has happened. Paul

Hi Rullysimo Have you tried specifying the server (FS computer) in the WideClient.ini files of your client PCs? Set either Server= or ServerIPAddr=, see the documentation for details. Sometimes the automatic discovery doesn't work. I think when the computers are in different windows workgroup is the main cause of this. I recommend you also look at the wideserver.log in the FS modules folder and the WideClient.log files on the client PCs. These may tell you what's wrong. You could also paste them in this thread - someone might be able to spot the problem. Paul

Pete and I have tried to explain that 570 is the FRACTIONAL part of the altitude - i.e. AFTER the decimal place. I've told you to how to fix this: Dim altitude As Offset(Of Integer) = New FSUIPC.Offset(Of Integer)(&H574) And you've not changed your code. Your code still says 570. All you need to do is change your offset from 570 to 574. Also note that the number you will get is in Metres. If you want Feet you'll need to convert it - (Multiply by 3.2808399). If Pete and I are going to help you please read what we're saying to you and make the changes we suggest. Otherwise we're all wasting our time. Paul

Can you paste your code in here (especially the offset declaration and the bit where you use the altitude). Also please tell me what altitude your plane is at in the sim and what the 'big number' is that you're getting. Thanks, Paul

As Pete explained, 32 bits is the same as 4 bytes which is an Integer in VB.NET. So declare the offset as: Dim altitude As Offset(Of Integer) = New FSUIPC.Offset(Of Integer)(&H574) Paul

You already have an example of the timer. The example VB.NET application I supplied with the DLL has a timer in it. Everything you need is there. Your problem maybe that you've not added the timer component to the form. You need to drag it from the toolbox (where you get buttons and textboxes from) onto your form. Then add the Tick() event code by double clicking it. I know. That's the problem. You have grouped it, but you're never processing that group. As I said in the last message, you need to process the group: FSUIPCConnection.Process("indh") Did you add that line? The best thing for you to do at the moment is remove all the grouping: Just declare the heading like this: Dim Heading As New FSUIPC.Offset(Of Double)(&H2CC) That should give you a value for the heading. If you're really stuck on getting the timer to work then send me the form code (cut and paste) via private message on the forum. It's difficult to help without the code. I'll make the timer work and send it back to you with comments showing what I did. Paul

Hi Topdog, The timer loops for you. It keeps calling the Tick() event at the interval that you set. Make sure that you set Timer1.Enabled = True to turn it on and set Timer1.Interval to the number of milliseconds you want between ticks. e.g to update 10 times per second: Timer1.Interval = 100 Timer1.Enabled = True From looking at your code I can see that the heading is not being updated from FSUIPC. You have defined it to be in a 'group' called "indh", but then you never process that group, only the default group. Somewhere in you code you need: FSUIPCConnection.Process("indh") The grouping feature is explained in the UserGuide.htm. Please read this if you haven't already. Paul

Because FSUIPC gives you a precise value for the heading, that is, values in-between each degree. This is nothing to do with FSUIPC or the DLL, you just use normal programming techniques to format the number to how you want it. In the case of VB.NET you can use one of the overloads of the ToString() method on the Double class: Me.myTextBox.Text = Heading.Value.ToString("000") You need to call Process() again and then get the new values from the offsets and display them on the form again. To do this at regular intervals you need to add a timer to the form and put the update code in the Tick() event. This is clearly demonstrated in the sample application. Paul

Hi Topdog, There is an example VB.NET application supplied with my DLL. It displays various types of data on a form. In summary though, you need to call the FSUIPCConnection.Process() method to read the data from FS. Then you read the values from the .Value property on the offsets. e.g. Me.txtMyTextBox.Text = AirSpeed.Value.ToString() Please have a look at the sample application as it explains everything in detail and also shows you how to setup a timer loop to keep everything updating on a regular basis. If you still need help, feel free to post more questions. Paul

As far as I know there's no offset to tell you at which airport the plane is. You need to test the plane's Lon and Lat position with that of the airport you're interested in. I'm away at the moment but if you want help with this I'm back next week and I can show you what you need to do. Paul

I've changed your posted code to use a Byte type instead of a BitArray: ' Declare our interest in offset 310A, which is a byte in length (and write only) Dim RudderDisable As Offset(Of Byte) = New FSUIPC.Offset(Of Byte)(&H310A, True) Private Sub Rudder_CheckedChanged(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Rudder.CheckedChanged ' If the checkbox is checked we write 4 to this offset to set bit 2, else we write 0 to clear bit 2. Me.RudderDisable.Value = IIf(Me.Rudder.Checked, 4, 0) End Sub You do need to write to this offset regularly or it will 'time out' after 10 seconds. I suggest you move the line in the checkbox change event to your normal process loop, or setup another timer to handle this every 5 seconds or so. If you want to do it properly I suggest putting this offset in it's own group, the you can process this group independently of the other offsets. Here is the code to do this with another Timer called Timer2 (you'll need to adjust the interval on Timer2): ' Declare our interest in offset 310A, which is a byte in length (and write only) ' and put it in it's own group so we can deal with it seperately. Dim RudderDisable As Offset(Of Byte) = New FSUIPC.Offset(Of Byte)("Rudder", &H310A, True) Private Sub Timer2_Tick(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Timer2.Tick ' If the checkbox is checked we write 4 to this offset to set bit 2, else we write 0 to clear bit 2. Me.RudderDisable.Value = IIf(Me.Rudder.Checked, 4, 0) ' Now process the group with the Rudder control in FSUIPCConnection.Process("Rudder") End Sub If you need any more help just ask... Paul

Hi, I think you've run into a problem with the way my DLL handles BitArrays. The write only happens when the data in the BitArray is changed from the last value written or read. I'll investigate this in more detail using your example and I'll come up with a way of making the DLL work properly with these type of offsets. (Those where you have to keep writing the same value and you are using a 'reference' data type like a BitArray). For now, if you declare this offset as a 'Byte' instead of a BitArray, make it readonly (very important), and just assign 4 (or whatever other values you need) then it should work as you expect. ('Value' types like Byte won't have the same problem because they write when assigned to (even if you assign the same value)). Let me know if you still cannot make it work using Byte. Paul

The longitude is signed. -tve longitudes are West. So you should declare the offset as a Long, not ULong. You'll then get -116 which means 116 degrees west. Paul

Hi Pat, I've never tested it in a 64bit environment. At the moment the project is set compile to a duel 64/32 bit binary. On your 64bit system it will be running as a 64bit DLL. This could be causing a problem. Are there any specific errors you can give me? I could just try compiling the DLL to force it to run on the 32bit compatibility layer. That might solve the problem but I'm not too sure what the problem is at the moment. Paul

Hi cyberconin There is only one 'pool' of offsets stored in the DLL. If you try and create an offset more than once (in the same group) then you'll get this error. Each time you're creating a new instance of class 'c' you're trying to create the same offsets again. I could modify the DLL to accept these 'duplicates' and return a reference to the offset that's already there. There's an extra complication where I would have to check that all the attributes are the same. For example if one class wanted an int from 0x1234 and another wanted a short from 0x1234 then this would have to still throw an error. When I wrote the DLL I decided against this approach because I could lead to confusion if the programmer didn't realise he/she was getting a reference to the existing offset instance rather than a new instance of that offset. With the current 1.3 version you can share offsets between classes (or instances of the same class) by creating another class that just handles your offsets. This could be a static class or a proper class that you only create one instance of. You would then need to pass a reference to this single instance into all the instances of other classes that need the data (probably in the constructor). So it goes something like this (Not real code or offset values!) Class FSUIPCData { public Offset airspeed = new offset(0x1234); public Offset altitude = new offset(0x5678); } Class c { private FSUIPCData data; public c (FSUIPCData Data) { data = Data; } private void doSomething() { int currentAirspeed = data.airspeed; } } In your main program you'd do something like this: FSUIPCData data = new FSUIPCData(); c c1 = new c(data); c c2 = new c(data); c c3 = new c(data); c c4 = new c(data); You'll need to manage the Process() calls in your main program loop or timer. You don't want all your instances of class c calling Process() for example. With this method it's very clear that each instance of class 'c' is referencing the same instance of the offset. That is, not each instance of class 'c' has it's own instance of the offset. I prefer this approach for it's clarity but I could be persuaded to go the other route where it's handled the in DLL as described at the top. Which method would you prefer? I'm intending to release 1.4 in the next month or so, so I could squeeze this change in. Let me know if you need any more explanation... Paul