Disallow Pause Offset 0x0262

[CXA001]

Our Acars program does not allow pilots to slew, use time acceleration or pause their flight simulator.

I am having an issue where I am using offset 0X0262 to send a value of 0 to the simulator if a pause is detected.

I have declared my offsets as follows:

Offset<short> FSUIPCUnPause = new Offset<short>("FSUIPCUnPause", 0x0262, false); //Prevents flight simulator from being paused.
Offset<short> FSUIPCNoAcceleraton = new Offset<short>("FSUIPCNoAcceleration", 0x0C1A, false); //Prevents flight simulator from increasing or decreasing sim rate.
Offset<short> FSUIPCNoSlew = new Offset<short>("FSUIPCNoSlew", 0x05DC, false); //Prevents flight simulator from slewing.

All three offsets are executed at the same time:

FSUIPCConnection.Process(new string[] { "FSUIPCUnPause", "FSUIPCNoSlew", "FSUIPCNoAcceleration" });
FSUIPCUnPause.Value = 0;
FSUIPCNoSlew.Value = 0;
FSUIPCNoAcceleraton.Value = 256;

If I look at the FSUIPC.log the values are be sent for NoSlew & NoAcceleration but not for UnPause:

657547 WRITEex 0C1A,   2 bytes: 00 01
664563 WRITEex 05DC,   2 bytes: 00 00
671157 ### Mode: PAUSE on

This did work in the past, but it does not seem to work anymore.

Any assistance would be appreciated.

Thanks in advance,

Marc

[Paul Henty]

Hi Marc,

You've declared these an standard read/write offsets (WriteOnly set to false). They will only send values if the value you sent is different from the current value (at last process()).

If you want to send these values even if the current values are the same, you need to make them WriteOnly (set last boolean parameter to true). That way the offsets will write the value on every process. You won't be able to monitor the values with these offsets however.

If you do want to monitor them and only send the values only when you detect a pause or different sim rate then leave them as read/write, but note that the DLL won't bother to write the values that haven't changed. e.g. if the user pauses, it won't send the simrate or slew mode.

Earlier versions of the DLL did behave slightly differently in this regard, but it didn't really work properly so I had to fix it. I suspect you wrote this feature using one of those earlier versions and you're now seeing a different behaviour.

Paul  

[CXA001]

Thanks for the quick response.

Your suspicions that this was written a long time ago is correct. I think it was about 5 years ago

Setting the last boolean parameter to true resolved the issue.

Thanks for you help.

Marc