Jump to content
The simFlight Network Forums

Recommended Posts

Posted

Hi Paul,

I wonder if you can clarify something regarding your module please?

If a program does this (for example):

FSControlParam.Value = VK (this is the key code variable)
FSControlNum.Value = 1070

FSUIPCConnection.Process("FSControls")
 
would both offsets always be written, even if their content is the same as now being written?
 
I ask this because a program ("ProsimUtils") is using this sequence to set offsets 3114+3110 in order to send keystrokes via FSUIPC to P3D. The first attempt succeeds, but, from logging supplied, it seems the second attempt only writes the 3114 (the VK value) -- so the keystroke is never triggered.
 
They all say this use to work. I've checked John's FSUIPC6 code for 3110 actions and I can't find any change there.  PorSimUtils has been revised recently to deal with ProsimV3, and may be using a new version of your esteemed DLL. I wonder therefore whether that has changed.
 
Just trying to track this down.  I've asked both parties to try setting 3110 to 0 between attempts, to see if it being unchanged is the problem.
 
Thanks Paul.
 
Pete
 
Posted
1 hour ago, Pete Dowson said:

would both offsets always be written, even if their content is the same as now being written?

 I've asked both parties to try setting 3110 to 0 between attempts, to see if it being unchanged is the problem.
 

Hi Pete,

From what I have read in Paul's docs the former is false, and the latter is what I have always done using Paul's DLL and it works here. Now I simply use his method for sending control numbers instead, which I realize doesn't apply here.

Just my 2c

James

Posted

 Hi Pete,

Quote

would both offsets always be written, even if their content is the same as now being written?

Only if both offsets are declared as WriteOnly. Offsets which are not explicitly declared as WriteOnly only get written when the value changes. WriteOnly offsets always get written during the Process() call (even if the value has not changed).

This is how those offsets should be declared in VB.NET. (The last parameter is the WriteOnly flag).

    Dim FSControlParam As Offset(Of Integer) = New Offset(Of Integer)("FSControls", &H3114, True)
    Dim FSControlNum As Offset(Of Integer) = New Offset(Of Integer)("FSControls", &H3110, True)

Note also that the order of declaration is important as it determines the order in the FSUIPC file, so 3110 must be declared after 3114.

The method used by the DLL to detect the need for writing did change in the early days of Version 3:

In version 2 it would be enough to assign a value, so this would be enough to trigger a write, even if the current value was 1070 :

FSControlNum.Value = 1070

From version 3 you need to write a different value to trigger a write for a read/write offset. Therefore, these types of offsets need to be used in write-only mode.

From what you describe it sounds like ProsimUtils isn't using Write-Only mode.

Paul 

  • Like 1
Posted
40 minutes ago, Paul Henty said:

Only if both offsets are declared as WriteOnly. Offsets which are not explicitly declared as WriteOnly only get written when the value changes. WriteOnly offsets always get written during the Process() call (even if the value has not changed).

Aha! That is what is happening with PSU. He did send me a little bit more code that what I posted earlier:

Definition:
    Private FSControlParam As Offset(Of Integer) = New FSUIPC.Offset(Of Integer)("FSControls", &H3114)
    
Private FSControlNum As Offset(Of Integer) = New FSUIPC.Offset(Of Integer)("FSControls", &H3110)

so no "Write-Only" flag.

Thanks!

Pete

 

Posted
19 hours ago, Paul Henty said:

Only if both offsets are declared as WriteOnly. Offsets which are not explicitly declared as WriteOnly only get written when the value changes. WriteOnly offsets always get written during the Process() call (even if the value has not changed).

Ahhh! Very good information! Thank you!

James

Posted

For writing I'm using

offset.WriteOnly = true;
offset.ActionAtNextProcess = OffsetAction.Write;

If I remember correctly WriteOnly alone was not enough when the value I set to the offset object was 0. Probably that was not registered as a change from the default value and to force it being sent to FSUIPC I set the ActionAtNextProcess.

Posted
Quote

If I remember correctly WriteOnly alone was not enough when the value I set to the offset object was 0.

Yes, this was certainly one of the previous bugs that lead to the changes in the read/write system.

Setting ActionAtNextProcess is no longer necessary with the latest versions of the DLL, but it won't do any harm either.

Paul

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.