Jump to content
The simFlight Network Forums

FSUIPC and keystroke from a remote program


Recommended Posts

Hi all,

Well, after a full day making white hairs, I think I need your help with FSUIPC and keystrokes sent from a program.
At this time I am trying to understand why ProsimUtils has issues to control GSX : commands are sent from the CDU to ProsimUtils, and then to P3D through FSUIPC/WideClient. Sometimes, the command CTRL+SHIFT+F12 opens the usual FSX window, but it's rare, and the command following the first one (1 or 2 to select an option) does nothing ... After that, if I want to open GSX window again, it simply doesn't work. All commands are registered in FSUIPC log, so they are well received but no event. It's pretty much the same issue than the one reported by Ramon here : https://forum.simflight.com/topic/91365-prosimutils-181-simconnect-window/

I coded a small python script to send keystrokes to Prepar3D through FSUIPC and WideClient. And I noticed something really strange. I would be glad if someone can comment or point me to the right direction.
The keystroke used is simple : it's S to change the view. If I execute the script, the keystroke is registered by FSUIPC and I can see it in the log, but nothing happens. If I execute the script two times, and with around 0.5-1s between each execution, the keystroke is registered two times by FSUIPC, but this time (and unfortunately not each time), the view is changed (and only 1 time, which is fine in fact).

I can't see what's wrong with my script. Here it is :

import pyuipc

pyuipc.open(pyuipc.SIM_P3D64)
pyuipc.write([(0x3110, 'u', 1070), (0x3114, 'u', 2131)])
pyuipc.close()

Pretty simple, isn't it ^^ ?

And the logging messages :

351906 WRITEex 330A,   2 bytes: D2 07                                            ..
352062 WRITEex 3110,   4 bytes: 2E 04 00 00                                      .... # first run
352062 WRITEex 3114,   4 bytes: 53 08 00 00                                      S...
352531 WRITEex 3110,   4 bytes: 2E 04 00 00                                      .... # second run after 0.5s-1s
352531 WRITEex 3114,   4 bytes: 53 08 00 00                                      S...
353718 *** EVENT: Cntrl= 65567 (0x0001001f), Param= 0 (0x00000000) VIEW_MODE

I use Prepar3D v5.1 HF1, with different sceneries and add-ons (UTLive2 beta, ASP3D, Prosim737, FSUIPC6.11). Python 3.7 is used with pyuipc installed from FSUIPC/SDK folder. I am experienced with Python, but not with FSUIPC SDK, so I probably do something wrong and can't see what it is ...

Thanks for your help !!

Olivier

 

 

Link to comment
Share on other sites

6 minutes ago, Buffort said:

At this time I am trying to understand why ProsimUtils has issues to control GSX : commands are sent from the CDU to ProsimUtils, and then to P3D through FSUIPC/WideClient.

What does it use to send the keystroke?

8 minutes ago, Buffort said:

I can't see what's wrong with my script. Here it is :


import pyuipc

pyuipc.open(pyuipc.SIM_P3D64)
pyuipc.write([(0x3110, 'u', 1070), (0x3114, 'u', 2131)])
pyuipc.close()

Pretty simple, isn't it ^^ ?

I don't know Python. What's the 'u'? Is that supposed to represent the keystroke for s?

Is it writing to 3110 first, then 3114? If so then the first write to 3110 will send whatever rubbish is in 3114. 

10 minutes ago, Buffort said:

And the logging messages :

You should write to 3114 first, or write all 8 bytes together. 

And you need to enable button & key logging not just IPC writes so we can see the timing of the key press and key release operations. 

Pete

 

 

Link to comment
Share on other sites

Was just looking at this but Pete beat me to it...

9 minutes ago, Pete Dowson said:

I don't know Python. What's the 'u'? Is that supposed to represent the keystroke for s?

No, that's the type of the value being written:

Quote

'data' should be a list of tuples of two items. The first item of
  each tuple should be an offset to read or write. The second item
  denotes the type of the value to be read from or written into the
  offset. it should be either a string or an integer. If it is a
  string, it denotes a type of a fixed size:

  - b: a 1-byte unsigned value, to be converted into a Python int
  - 😄 a 1-byte signed value, to be converted into a Python int
  - h: a 2-byte signed value, to be converted into a Python int
  - H: a 2-byte unsigned value, to be converted into a Python int
  - d: a 4-byte signed value, to be converted into a Python int
  - u: a 4-byte unsigned value, to be converted into a Python long
  - l: an 8-byte signed value, to be converted into a Python long
  - L: an 8-byte unsigned value, to be converted into a Python long
  - f: an 8-byte floating point value, to be converted into a Python double
  - F: a 4-byte floating point value, to be converted into a Python double
 

 

Link to comment
Share on other sites

Thanks for your answers, Pete and John !

47 minutes ago, Pete Dowson said:

What does it use to send the keystroke?

Unfortunately, I don't know ... All I can say is that ProsimUtils makes use of WideClient and then FSUIPC to interact with GSX menu. Apart from that, I don't know the library and the computer language used by Humberto.

50 minutes ago, Pete Dowson said:

I don't know Python. What's the 'u'? Is that supposed to represent the keystroke for s?

John is right ^^ !

52 minutes ago, Pete Dowson said:

Is it writing to 3110 first, then 3114? If so then the first write to 3110 will send whatever rubbish is in 3114. 

You should write to 3114 first, or write all 8 bytes together. 

And you need to enable button & key logging not just IPC writes so we can see the timing of the key press and key release operations.

In my opinion, as I put the tuple with 3110 first in the list, it should be the first one to be written, then the 3114. With your explanation, I must say that now I understand a bit more how it works ^^. I will try by writing to 3114 first (with the button & key logging option). I am not sure I can write both at the same time ... the Python module (pyuipc) is pretty limited in that way.

Olivier

Link to comment
Share on other sites

12 hours ago, Buffort said:

Unfortunately, I don't know ... All I can say is that ProsimUtils makes use of WideClient and then FSUIPC to interact with GSX menu. Apart from that, I don't know the library and the computer language used by Humberto

No, but you could use FSUIPC logging to see what arrives, as you are doing with your Python program. That's why I thought you might know.

12 hours ago, Buffort said:

I am not sure I can write both at the same time ... the Python module (pyuipc) is pretty limited in that way.

Well, you could use this from the list John posted:

L: an 8-byte unsigned value, to be converted into a Python long

If you could also use hexadecimal in Python that would make it easier.

For your test send something which doesn't take any time for the sim to obey, like P for Pause or Q for quiet. S to change the display could be taking longer than the time you allow (though the control should really show twice). However, a log with Keypress logging would show the timing.

Are you using ProsimV3 with the updated PSU? I'm rather surprised it supports sending keypresses over WideFS. You'd think it would send tham via its own links, to ProSim or the ProSim module running within P3D.

Anyway, logging what FSUIPC sees will show us what is going on. 

Pete
 

Link to comment
Share on other sites

Dear Pete,

I just tested my script following your suggestion. And ... indeed, writing first the offset 3114 and then the offset 3110 is definitely better ! By using Q, I could switch the sound on and off as I wished, several times. I included the log in my post for reference.

To answer your question about ProsimUtils, I am sure it uses WideClient/FSUIPC. It works if I don't run Prosim, and it simply doesn't work if WideClient is not running.

Olivier

Link to comment
Share on other sites

Ok, it works, I can control GSX with Python and a scrip.
 

import pyuipc
import time
pyuipc.open(pyuipc.SIM_P3D64)

pyuipc.write([(0x3114, 'u', 2939), (0x3110, 'u', 1070)])
time.sleep(2)
pyuipc.write([(0x3114, 'u', 2098), (0x3110, 'u', 1070)])
time.sleep(2)
pyuipc.write([(0x3114, 'u', 2097), (0x3110, 'u', 1070)])

pyuipc.close()

With this script, and the aircraft positioned at the threshold of 04R (LFMN), I open GSX window, select the option 2 (Runway 04R) and select option 1 (ask for Follow me car). I included pauses in the script (time.sleep()) to let FSUIPC and P3D handle the different commands before sending the next one.

I have now materials to discuss with Humberto about ProsimUtils. In the mean time I can code a small program to handle keystrokes sent to FSUIPC from the CDU, I just have to understand how to add a small HTTP server in my script ...

Link to comment
Share on other sites

2 minutes ago, Buffort said:

I have now materials to discuss with Humberto about ProsimUtils.

Okay.

I use PSU, but only for the plan and performance data. It supports my thermal printer in the centre console as well. Very useful.

I used to also use its checklist facilities, with display on the EICAS, but gave up because the wasted (black space) part of the fuel gauge window reduced the number of actual items displayed to about 5.5!  Any more were hidden by the wasted black area which is part of the fuel gauge window.

I asked Humberto to reduce that window size to just fit the image. I've not had time yet (with Prosimv3 ) to check if that was changed.

Pete

 

Link to comment
Share on other sites

4 hours ago, Buffort said:

I have now materials to discuss with Humberto about ProsimUtils.

It looks like the problem is down to a change in the DLL Humberto is using for his FSUIPC interface. There's a thread about it I started on Paul Henty's DLL subforum above. I've notified Humberto.

Pete

 

Link to comment
Share on other sites

On 12/15/2020 at 7:00 PM, Pete Dowson said:

Okay.

I use PSU, but only for the plan and performance data. It supports my thermal printer in the centre console as well. Very useful.

I used to also use its checklist facilities, with display on the EICAS, but gave up because the wasted (black space) part of the fuel gauge window reduced the number of actual items displayed to about 5.5!  Any more were hidden by the wasted black area which is part of the fuel gauge window.

I asked Humberto to reduce that window size to just fit the image. I've not had time yet (with Prosimv3 ) to check if that was changed.

Pete

 

Oh ! I just discovered those checklists for the first time ! I didn't imagine that it could be integrated by Humberto.

I noticed an xml file in ProsimUtils/checklists folder ... I don't know if we can use it to tweak a bit those checklists, like reducing the number of items to be displayed ...

Olivier

Link to comment
Share on other sites

23 minutes ago, Buffort said:

I noticed an xml file in ProsimUtils/checklists folder ... I don't know if we can use it to tweak a bit those checklists, like reducing the number of items to be displayed ...

Yes, you set the number there, somewhere. Sorry, my system is off at present so I can't take a look. I want more items than appears cto be allowed, and even the number allowed won't show correctly because the fuel quantity gauge window covers it up -- albeit only with wasted black space. I keep asking Humberto to adjust that so more can fit without obliteration.

I like quite detailed check lists. So some, with only room for 5 or 6 per display, take several 'pages' to get through!

Pete

 

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.