Airline and Title not updating...

[IanAbel]

Paul,

  Having found a problem with getting a reliable return for offsets 3148 (Airline name) and 3D00 (aircraft title), I used your your FSUIPCExampleCode_VB (extremely helpful BTW!!), and in the grouping section simply replaced the first two offsets to those I'm interested in above. Running P3Dv4, it is very inconsistent in updating, often retaining the last data read even through several changes of a/c.

Is this a problem with P3D? It almost seems as if the change is not registering somehow even though other values report correctly. I'd like to obtain this data, but it doesn't seem to work.

Any help/suggestions greatly appreciated.

EDIT: Offset 313C acts the same way...whereas 3500 (model) seems more consistent.

Edited August 20, 2018 by IanAbel
Additional info...

[Paul Henty]

Hi Ian,

I've tried it here with FSX:SE and it works fine. After switching aircraft the offsets return the correct information instantly, first time.

I don't have P3D so I can't check if it's a problem with that (or FSUIPC5).

Have you tried using the Logging tab in FSUIPC to log these offsets to the screen? example:

If the values are wrong when logged to the screen by FSUIPC then you need to ask Pete about it the main support forum.

Also, please try with the latest beta version of my DLL and see if that makes any difference. (V3.1.6-Beta). Tick [include prerelease] in the Nuget Manager to get the beta version to show up.

Paul

[IanAbel]

Paul,

 Loaded the latest DLL first...

In both FSX (local not Steam) and P3D, the logged variables appear just fine, UNTIL I try and interrogate them, at that point, whilst somewhat inconsistent, the Reg -313C and Airline 3148 seem to be being overwritten by the prior values! It seems to occur most consistently if the aircraft selected is another variant in the same aircraft.cfg.

If the reg# is populated and I select an a/c without a reg., when I run the

update request the next time the logged variables change to show the "last values" in the app, hope that makes sense. It seems like the FSUIPCConnection.Process call is updating those two offsets. Any ideas?

Below is the code I wrote to test it, not sure if it helps or if Pete should be the one to contact?

 

Imports FSUIPC

Public Class Form1
    Private RegID As New Offset(Of String)("AircraftInfo", &H313C, 12)
    Private airline As New Offset(Of String)("AircraftInfo", &H3148, 24)
    Private aircraftType As New Offset(Of String)("AircraftInfo", &H3160, 24)
    Private aircraftModel As New Offset(Of String)("AircraftInfo", &H3500, 24)
    Private nameTitle As New Offset(Of String)("AircraftInfo", &H3D00, 96)

    Private Sub Form1_Load(sender As Object, e As EventArgs) Handles MyBase.Load
        FSUIPCConnection.Open()

    End Sub

    Private Sub ButtonUpdate_Click(sender As Object, e As EventArgs) Handles ButtonUpdate.Click

        FSUIPCConnection.Process("AircraftInfo")

        ' Now display the data on the form
        DataRegID.Text = RegID.Value
        DataAirline.Text = airline.Value
        DataACType.Text = aircraftType.Value
        DataModel.Text = aircraftModel.Value
        DataName.Text = nameTitle.Value

    End Sub
End Class

[Paul Henty]

I've run your code and I did have the same problem but only twice in about 20 mins of trying.

The problem is caused by the DLL writing rather than reading. So it changes the RegNo (for example) to the one that's currently in the value - which is from the previous aircraft. I can see the write in the FSUIPC Log.

I can't get this to happen in a reliable, repeatable way so it's going to be difficult to track down.

But it looks like a problem with the DLL writing when it shouldn't. Leave it with me and I'll see if I can fix it in the next few days.

If you have a reliable way to recreate the problem then please let me know the steps. - it will let me fix it much faster.

Paul

[IanAbel]

Understand... thanks. I wish there was a reliable way to reproduce it, I've tried quite a few variations to see if I can come up with something consistent but no luck I'm afraid.

If I go back and forth between several liveries of the same a/c and a second a/c variant, I can usually get it to happen every fourth or fifth time, but never consistent.

Not sure what a/c you have for FSX but seems like the feelthere E170/E190 make it occurs, maybe because they vary between having a reg. in several of the a/c and none in others!

That's about the best I've got for now. If I can get some more time to test it I'll let you know if I find something concrete...

[Paul Henty]

I've found the problem. The strings coming from FSUIPC sometimes have junk after the zero terminator (from previous values). The DLL is cleaning up these strings internally, but this means that when the cleaned string is compared to the original raw string it thinks the value has been changed and does a write.

I'll hopefully get a fix up by the end of the day. This area is foundational to the DLL so I need to make sure the fix isn't going to break something else.

Paul

[IanAbel]

Good News Paul... let me know if there's any way I can help. Again, new to this stuff but been a developer (almost everything known to man!!) for 40+ years ;)

[Paul Henty]

Version 3.1.7-beta is now available on NuGet.

I've given it a good test here and everything looks okay - your strings should read 100% of the time now.

Paul

[IanAbel]

Will go get it and start using, thanks again...

 

UPDATE: BRILLIANT, works like a charm, cycled through a couple of dozen a/c and all reported correctly immediately - thanks so much Paul!!