Jump to content
The simFlight Network Forums

how to send remote key press commands using fsuipc offsets


Recommended Posts

Hi Peter,

In my hardware based cockpit, I dislike the fact that i still need the keyboard to respond to ATC. Instead, I want to write my own speech recognition program to send voice responses to ATC.

My general plan is..

Step 1) my SR program will run on a remote machine, recognize my voice responses, generates appropriate fsuipc offset command and sends it to the fsuipc module installed under FS9 through wideFS.

Step 2) On the other end, fsuipc translates incoming offset command to an equivalent ATC key press command (i.e., press key 0 or 1 or 2 etc.,)

I know the step 1 above can be done and how to do it.

But I don't understand how to accomplish step #2. I am hoping there would some kind of configuration/mapping file that would instruct fsuipc to generate the necessary key press command for a given incoming offset. Wondering is this possible?

Reason I find this solution attractive is..this allows me to run the processor hungry speech recognition software to run on a remote machine.

thanks in advance

srini

Link to comment
Share on other sites

Is this what I think is the answer?

ATC 65564

ATC_MENU_0 66181

ATC_MENU_1 66172

ATC_MENU_2 66173

ATC_MENU_3 66174

ATC_MENU_4 66175

ATC_MENU_5 66176

ATC_MENU_6 66177

ATC_MENU_7 66178

ATC_MENU_8 66179

ATC_MENU_9 66180

If yes, then this may work for the default ATC.

But still wondering, in general is there a way to translate free offsets into general keyboard keypress commands?

thanks

srini

Link to comment
Share on other sites

I used the offset at 0x3110 to send in FS Controls such as Pan_Right or Pan_Left.

I disabled the joystick in FS and with my program can capture joystick hat switch movements and send in something like this:

bReturn = f.FSUIPC_Write(0x3110, PAN_RIGHT,ref token, ref result);

This makes FS pan right even though the joystick is disabled. PAN_RIGHT is equal to the value in the fs control list.

You should be able to do the same sort of thing with your vr software if you have the correct FS Controls

Link to comment
Share on other sites

Thanks

I used the offset at 0x3110 to send in FS Controls such as Pan_Right or Pan_Left.

That's right and I figured the same as mentioned in second post. However, this works for all well known command oofsets such as the ones you mentioned. Hence this will possibly work with the default ATC.

However, if I want to control a 3rd party ATC program like RadarContact or something else, I am not sure they will use the same ATC offsets as the default ATC to read in the key presses, but for sure I know they expect number keys from the keyboard as the input to respond. So, question is..is there any generic way of translating a given offset into number key (or any keyboard presses) inputs? I know FSUIPC translates and maps keyboard keys to FS9 offset command(s). What I am looking for is kind of opposite to that., i.e., translate incoming offset setting to a keyboard key press and send it to FS9. Peter?

For the default ATC, I think I have the soultion though. I am going to try that first.

thanks

sri

Link to comment
Share on other sites

This is what I did to send some keypresses to fs. Its a very dirty approach but I finally got it to work. What it does is send Ctrl+2 to make active camera to change a preset view.

if (fsStartedIdle)
 {	
   counter += 1;
   keybd_event(0x11,0,0,0);
   SendKeys.Send("2");				
   if (counter > 25)
     {
       fsStartedIdle = false;
       counter = 0;
       keybd_event(0x11,0,2,0);
      }
}

the keybd_event function is in the user32.dll and SendKeys is part of .Net Framework. Note that the program has to have focus for these to work. This code will hold down Ctrl and spam 2 key. After a certain amount of time it releases the Ctrl and exits the loop. Code is kinda ugly too =]

Link to comment
Share on other sites

It's in a application seperate from FS9. My code, though, probably wouldn't work on a remote machine. Because the functions that send keystrokes will send to apps running on the local machine only (as far as I know they can't do it on local machines). Maybe sending Windows Messages with WM_KEYUP and WM_KEYDOWN might work over ethernet. I wouldn't know because I've never done anything like that. Sorry I can't help any further. Now it's time for someone else to chime in with their two cents. :D

Link to comment
Share on other sites

However, if I want to control a 3rd party ATC program like RadarContact or something else, I am not sure they will use the same ATC offsets as the default ATC to read in the key presses, but for sure I know they expect number keys from the keyboard as the input to respond.

Radar Contact uses FSUIPC's Hot Key facilities to capture keypresses. It does default to using the numerics on the main keyboard, but I always reconfigure it to use Control+Shift+n combinations to avoid clashes with normal FS use -- in particular, the use of the 1-4 keys to select Engines, Exits and to control pushback direction.

There are two ways to program KeyPresses into FS from an application. The original one is quite difficult but is of long-standing, and is described in offsets 3200-320B. It actually involves control of the Windows keyboard messages which FSUIPC will send for you.

A much easier way was added in Version 3.60 (i.e. in April). A set of three FSUIPC controls were added to Press, Release or Press and Release keys with given shift key combinations. These are numbered 1071, 1072 and 1070 respectively, and they are listed with all the other added FSUIPC controls in the Advanced User's document.

Any of the added FSUIPC controls can be actioned through offset 3110, just like FS controls, with the exception of the Offset controls -- there's no need for those as you can access offsets in any case. ;-)

Regards,

Pete

Link to comment
Share on other sites

Thanks. I know you certianly will have more than one solution :D

Radar Contact uses FSUIPC's Hot Key facilities to capture keypresses.

Kind of lost me there even though I follow the rest of what you said.

So, if i know what those hot keys are for RC, is it possible for my remote program to send them directly to fsuipc via widefs? Not sure I am thinking correctly..

thanks

sri

Link to comment
Share on other sites

Radar Contact uses FSUIPC's Hot Key facilities to capture keypresses.

Kind of lost me there even though I follow the rest of what you said.

Sorry, what was the problem? I'll try to spell it out.

Radar Contact does NOT read keypresses. It asks FSUIPC to do it via the FSUIPC Hot Keys facilities (see offset 3210). This allows it to capture keys on the FS PC no matter which PC it is running on.

The keys it so traps are configurable in its own dialogues -- there's one where you can say what key does what.

Isn't that clear?

So, if i know what those hot keys are for RC

You do. You can view them in RC's table and change them as you want.

is it possible for my remote program to send them directly to fsuipc via widefs?

Of course. I told you two ways! The hard way and the easy! I even gave you the offsets to look up. Didn't you bother? :-(

Not sure I am thinking correctly..

Well, sorry, but I don't think you could have read much of what I wrote! :-(

There are TWO separate things going on here:

1. Radar Contact reads keys on the FS PC (no matter where it runs).

2. There's an FSUIPC control which will press keys on the FS PC, and you can use that contorl via Offset 3110.

The first was simply clarification for you about what Radar Contact does (you weren't sure), and the second is telling you that you can make FSUIPC press keys via offset 3110.

Okay? I seem to be repeating myself a lot. :-(

Please just go and read about the things I mentioned. I'm not going to repeat all the documentation here. Go look up some of the offsets -- you've obviously missed a lot. And look at the list of FSUIPC controls in the Advanced Users guide.

Regards,

Pete

Link to comment
Share on other sites

Peter,

I am sorry that my short post gave you the impression that I did not read the stuff you directed me towards originally. And sorry that it made you feel necessary to repeat yourself one more time in detail. Sorry for the trouble and thanks for your time.

Just to let you know, the very first time..

A) I did care and read the relevant sections in docs before posting B) except for RC and hotkey reference, I understood it all exactly as you repeated the next time.

AND..I don't have a copy of RC and I am not a RC user (yet)!! which you seem to assume that I am..

But anyway, thanks to you.. I have the prototype already running in two hours and I am able to bring up the defualt ATC and command it through very basic test voice commands from a remote machine. I guess not bad for someone who looked so dumb and not listening!! :D

thanks

sri

Link to comment
Share on other sites

AND..I don't have a copy of RC and I am not a RC user (yet)!! which you seem to assume that I am..

Ah, okay. Sorry. I got the impression you were, hence the question about it.

I guess not bad for someone who looked so dumb and not listening!! :D

Right! Well donesorry if I got the wrong impression!

Regards,

Pete

Link to comment
Share on other sites

No..sincerely, thanks to you for all your time and efforts.

Now that basic stuff is working..I am getting ambitious and wondering is it possible to:

1) display (or redirect) the defult ATC window output on to the remote machine, instead of on the FS9 computer?

2) is it possible to read the menu choices (text) presented in the ATC window programatically (through offsets)? This allows me to build and understand intelligent voice commands. For example instead of saying "select 1" (which currently sends the keypress "1") I could say "contact ground" irrespective of the current menu position of 'contact ground' in the ATC menu.

3) By reading from forums briefly, I got the impression..for RC you are now handling and displaying the menu output (which earlier used to be displayed in AdvDisp window) in the fsuipc window (or the ATC window). If this is true, then any of the above two questions possible for RC?

thanks

srini

Link to comment
Share on other sites

Now that basic stuff is working..I am getting ambitious and wondering is it possible to:

1) display (or redirect) the defult ATC window output on to the remote machine, instead of on the FS9 computer?

No, I never managed to find any way to hook that. I would have liked to extract the text itself to help automate responses.

2) is it possible to read the menu choices (text) presented in the ATC window programatically (through offsets)?

No, see above -- you are wanting to do what I wanted to do, but I couldn't find my way through the mass of C++ OOP class structures and Direc3D links.

3) By reading from forums briefly, I got the impression..for RC you are now handling and displaying the menu output (which earlier used to be displayed in AdvDisp window) in the fsuipc window (or the ATC window). If this is true, then any of the above two questions possible for RC?

Yes, but they were before I added the new Window facility. All RC's menus come through offset 3380 -- programs like AdvDisplay (in FS) and ShowText (on any WideFS client) pick them up from there. You can do the same. It's just text.

Regards,

Pete

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • 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.