Problem writing AI Traffic in FSUIPC4

[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

[Pete Dowson]

G-TEXR was one of the AI generated by FSX.

After this happens FSUIPC4 also stops responding to any IPC requests.

I'm not surprised. It looks like it got into a never-ending loop.

Can you have a look at this please?

Yes of course. So I don't waste time trying to emulate what you are doing the wrong way, and not getting a result, could you turn on FSUIPC IPC write logging, and just run that test again for me. I need to see the exact writing sequence so I can do the same here.

I'm afraid I might not get to this till Monday now. Tied up today with some other big changes and I'm busy with other things over the weekend, but if I can repro it quick i'll fix it quickly too.

Regards

Pete

[Paul Henty]

Hi Pete,

Here's the WideClient log with the 2 AI Plane writes to 0x1f80:

********* WideClient Log [version 6.78] Class=FS98MAIN *********
Date (dmy): 18/09/09, Time 13:02:01.746: Client name is PJHLAPTOP
      109 Timing Thread Started
      141 SendReq Thread Started
      468 Trying TCP/IP host "FSVisuals" port 8002 ...
      468Okay, IP Address = 192.168.0.1
    61839 Trying TCP/IP host "FSVisuals" port 8002 ...
    61839Okay, IP Address = 192.168.0.1
   123600 Trying TCP/IP host "FSVisuals" port 8002 ...
   123600Okay, IP Address = 192.168.0.1
   184861 Trying TCP/IP host "FSVisuals" port 8002 ...
   184861Okay, IP Address = 192.168.0.1
   206140 Sending computer name and requesting base data ...
   206140 Button Thread Started
   282393 New Client Application: "TestApp" (Id=4492)
   282393    0 ReadLocal: Offset=3304, Size=0004
            00 00 34 45 
   282393    0 ReadLocal: Offset=3308, Size=0004
            08 00 DE FA 
   287666      Write: Offset=1F80, Size=0028
            01 00 00 00 90 B1 44 42 38 AF EE BF CD 50 FA 45 
            7C 49 64 00 03 00 50 41 55 4C 31 00 00 00 00 00 
            00 00 00 00 00 8C 45 23 
   287666      Write: Offset=1F80, Size=0028
            02 00 00 00 A1 C2 44 42 16 8D EC BF 66 86 7C 44 
            E4 4A 65 00 03 00 50 41 55 4C 32 00 00 00 00 00 
            00 00 00 00 00 8C 45 24 
   299054 Timing Thread Terminated
   299054 Button Thread Terminated
   299054 SendReq Thread Terminated

   299054 ****** End of session performance summary ******
   299054 Total time connected = 93 seconds
   299054 Reception maximum:  31 frames/sec, 846 bytes/sec
   299054 Reception average whilst connected:  24 frames/sec, 621 bytes/sec
   299054 Transmission maximum:  1 frames/sec, 79 bytes/sec
   299054 Transmission average whilst connected:  0 frames/sec, 22 bytes/sec
   299054 Max receive buffer = 595, Max send depth = 1, Send frames lost = 0

   299054 **************** Individual client application activity ****************
   299054 Client 4492 requests: 2 (Ave 0/sec), Data: 144 bytes (1/sec), Average 72 bytes/Process

   299054 ********* Log file closed (Buffers: MaxUsed 2, Alloc 2244 Freed 2244 Refused 0) *********

There's no hurry on my part - I'm just adding a feature into my .NET client dll to make it easier for .net programmers to read/write AI traffic.

Thanks,

Paul

[Pete Dowson]

There's no hurry on my part - I'm just adding a feature into my .NET client dll to make it easier for .net programmers to read/write AI traffic.

Fixed in 4.535, now available in the Updates Announcement. As often the case with these conversions over from the FS9 code, it was a typo. It was actually using offset F000 not 1F80 internally! Duh! The strange corruption you saw in TrafficLook was the result of the corrupted details in the 40 bytes at F000, and these then affected further attempts. FSUIPC wasn't hung or in a loop as it first looked.

The fact that it's taken 3 years to discover this seems to indicate that the facility isn't used much in FSX, if at all! ;-)

Best Regards

Pete

[Paul Henty]

Hi Pete,

Thanks for that, just tested 4.535 and it looks fine.

There is just a small difference: The injected AI planes aren't being cleared after a few seconds of no updates. In FSUIPC3 they get deleted from the tables if you don't supply FSUIPC with regular updates. In FSUIPC4 they are still being reported by TrafficLook long after my test app closed down.

Regards,

Paul

[Pete Dowson]

The injected AI planes aren't being cleared after a few seconds of no updates. In FSUIPC3 they get deleted from the tables if you don't supply FSUIPC with regular updates. In FSUIPC4 they are still being reported by TrafficLook long after my test app closed down.

Okay. I'll look at that.

Thanks,

Pete

[Pete Dowson]

The injected AI planes aren't being cleared after a few seconds of no updates. In FSUIPC3 they get deleted from the tables if you don't supply FSUIPC with regular updates. In FSUIPC4 they are still being reported by TrafficLook long after my test app closed down.

Okay, fixed in 4.536 now available in the Updates Announcement. I had a complete chunk of code missing in the FSUIPC4 version!

Thanks & Regards

Pete

[Paul Henty]

This all looks fine now.

Thanks again,

Paul