Jump to content
The simFlight Network Forums

Strange behaviour when updating from 3.1.5 to 3.1.10

Recommended Posts


First off, thank you for this amazing .net library and that it's not easily accessible through a NuGet package.

I'm always trying to stay up-to-date on my NuGet packages, which applies to the FSUIPC client as well.

I did a regular update from 3.1.5 to 3.1.10 yesterday, but that came with some change in behavior.

The only thing I did was to upgrade the client, no changes to the code itself for these behaviors to happen.


The scenario I've found so far is that Offsets I have defined, but not yet interacted with, changes without anything in the code changing them.

In my case I discovered this cause as soon as my application loads, the aircraft starts pushing back using the pushback feature in P3D.


I've defined the pushback control offset like this:

private readonly Offset<Int32> fsuipcPushbackControl = new Offset<int>("Aircraft", 0x31F4, true);


If I downgrade back to 3.1.5, the normal behavior is back.


I'm guessing this is related to the change in BETA 3.1.6:

Version 3.1.6 BETA
  • The code to determine if an offset is going to read or write has been revised. There were a few minor bugs which made it a bit unpredictable. It now works as intended:
    • Normal Read/Write offsets (i.e. not marked as Write-Only) will write on next process() if the value is changed by your code. Otherwise they will read.
    • Write-Only offsets will write on every process() regardless of if the value is changed or not. I strongly advise that write-only offsets are put in their own group so you can control when they get processed (written).
  • Read/Write Offsets no longer need to be read before they can be written.


Have I done something wrong in defining my offset for this to happen?

I can fix this by moving this offset to its own Group and only calling it when changing the value, but shouldn't WriteOnly offsets still be able to share a group with read+write-offsets? There is no code that sets the pushback value before it's processed, and even so, it's set to 3 when initializing the application.


I just need to understand this in order to not get hard to troubleshoot effects at a later stage when using write-only offsets.



Link to comment
Share on other sites

Hi Frazer,

Yes the change in behaviour is because of the code revision in 3.1.6 Beta.

Write-only offsets now write every time, regardless of whether they have been changed or not. So it's not ideal to put them in a group with read/write offsets.

I had to change this because for some offsets you need to set the same value as before. The DLL didn't see this as a change in value so the offset didn't get written the second time. There were also problems if you wanted to write a 0 as the first value. Because the initial value is 0 you couldn't write a 0 as the first value.



it's set to 3 when initializing the application

If the pushback is starting then there must be a process() before the value is set to 3. It's writing the initial 0 value now. With 3.1.5 it wouldn't do that.

There are two things you can do:

1. Make sure that group is not processed before the value 3 is set.

2. Put the pushback control in its own group and only process() it when you want pushback to start/stop.

I recommend 2. With option 1 it will work but you're always going to be writing the pushback control value. While FSUIPC will probably be okay with that (it probably ignores the value if it's the same as the current pushback status) it's just a waste of a write.


Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.