Jump to content
The simFlight Network Forums
Jason Fayre

FSUIPC not properly trapping keys on lua key event

Recommended Posts

Hello,

I'm trying to define some key events in a lua script.

The keys are working, but the keypresses are also being passed on to the sim. This is fsuipc 6.0.8 and p3d v4.5.

My event line looks like:

event.key(7124"heat_dec")
This fires when I press Tab+g, but the landing gear control in the sim also triggers. I thought fSUIPC was supposed to trap these keys?
Am I doing something wrong?
Thanks!
 

 

Share this post


Link to post
Share on other sites
29 minutes ago, Jason Fayre said:

This fires when I press Tab+g, but the landing gear control in the sim also triggers. I thought fSUIPC was supposed to trap these keys?

I'd have to check. It isn't documented like that, and I think perhaps that the key press Event may not always be wanted in a Lua plug-in to change its assignment, but simply to know when it occurs for other purposes. Though I suppose the solution then should be to send it on before exit as intended for control or axis interception.

Certainly Keys assigned in FSUIPC take precedence over those assigned in the sim. 

It also occurs to me that TAB+G shouldn't cause the GEAR Toggle conttrol to fire in any case -- is the Sim ignoring the TAB button?

I wonder if the use of TAB as a shift (not a standard type of shift as recognised by the sim like Shift, Ctrl and Alt)  is confusing the issue. Could you see what just G does? Let me know. i won't be able to check properly till, probably, Monday.

Also see if TAB + G operates the Gear even if assigned to something else in FSUIPC. That would prove conclusively that the G goes through with TAB as the "shift".

I assume, of course, that you hold the TAB down before pressing the G? Else the G would certsinly go through first.

Pete

 

 

Share this post


Link to post
Share on other sites

Hi Pete,

Thanks for looking at this. I'm trying to use the lua events to assign keys in my software so I don't need to ask users to make a bunch of modifications to their fsuipc ini files, adding macros, etc.

Here is what I found:

1. Adding g without any shift as a lua key event does trigger the landing gear.

2. Adding Tab+g as a FSUIPC hotkey triggers the fsuipc key action, but the gear doesn't activate.

So, the way lua and regular FSUIPC hotkeys are behaving is definitely different.

If this isn't going to work through LUA for assigning keys, do you have any suggestions on the best way to make my hotkeys, lua scripts, and macros portable? If I go that route, people will need to manually add all the correct profile entrys to their fsuipc ini files. I was trying to avoid that.

Thanks!

 

 

 

 

Share this post


Link to post
Share on other sites
56 minutes ago, Jason Fayre said:

Here is what I found:

1. Adding g without any shift as a lua key event does trigger the landing gear.

2. Adding Tab+g as a FSUIPC hotkey triggers the fsuipc key action, but the gear doesn't activate.

So, the way lua and regular FSUIPC hotkeys are behaving is definitely different.

FSUIPC "hotkeys"? In the Hotkeys tab?

What about keys assigned in the normal Keys assignments tab?

Why did you choose Tab+g for the comparison in "Hotkeys" not "G". Wouldn't that have been a proper comparison?

56 minutes ago, Jason Fayre said:

If this isn't going to work through LUA for assigning keys, do you have any suggestions on the best way to make my hotkeys, lua scripts, and macros portable?

I don't know at present, before looking at it. It may be an oversight. I'll check the code, see what was intended. It's possible that P3D4/5 defeats the FSUIPC code by accessing the keyboard more directly than FSX and P3D1-3 and no one else has noticed the change. FSUIPC only works by using WM_KEYDOWN and WM_KEYUP messages. There are other ways of reading the keyboard, but I don't know if they can be made exclusive.

I probably won't get to this till Monday though.

Pete

 

Share this post


Link to post
Share on other sites

Hi Pete,

Yes, if I assign Tab+g in the FSUIPC hotkeys dialog, the key works and doesn't get passed on to the sim. If I assign the same key via a LUA key event, the event triggers, but also activate the landing gear. 

I'll try just assigning G in the FSUIPC hotkeys dialog, but I'm fairly sure I'll see the same thing where FSUIPC traps the key as expected.

Assigning g as a hotkey via lua passes the key through as well as triggering my event.

Thanks!

 

 

 

Share this post


Link to post
Share on other sites
11 hours ago, Jason Fayre said:

Yes, if I assign Tab+g in the FSUIPC hotkeys dialog, the key works and doesn't get passed on to the sim. If I assign the same key via a LUA key event, the event triggers, but also activate the landing gear. 

I'll try just assigning G in the FSUIPC hotkeys dialog,

The HotKeys dialog is not the one you should be compaing it with. That's just for special actions. They general Keys assignment tab is the one you should have used, as I said. The FSIOPC HotKeys are trated completely differently.

Anyway, I've had a quick look and the Lua key event has always worked at just detecting the key presses not trapping them. So that's many years with no problem. I'll discuss it with John (who has taken over onward development from me), but my personal opinion is that it should stay as it is, as it was designed to be. If it were to be changed I think it would have to be an option, enabled by a special [General] parameter in the INI file. And it would only apply to current versions of FSUIPC (6 and maybe 5).

Surely it would be better to just use keys not assigned in the Sim by default. Ctrl+G, Shift+G, Shift+Ctrl+G are okay.  The "TAB" in "TAB+G" isn't counted as a shift by the Sim, so it will treat it as a TAB press and a G press.

Pete

 

 

Share this post


Link to post
Share on other sites

Hi Pete,

Sorry for the confusion. The general key assignments tab is the one I was talking about.

 Ok. I'll re-think my hotkey strategy. I'm adding keys for several events that don't normally have keys, so I was trying to come up with a scheme that wouldn't require my users to remap keys in the sim. I'll probably just switch back to using keys defined in FSUIPC. It just means people will need to add a block of info to there ini file when I install my software.

Could it also be an option to use the offsets at 3210 to define keys? In reading the documentation, I'm not totally clear on how to use those. Do you have an example of how to check for a hotkey from a lua script?

I assume those keys are trapped?

Thanks for all your help!

 

 

 

Share this post


Link to post
Share on other sites
57 minutes ago, Jason Fayre said:

I'm adding keys for several events that don't normally have keys, so I was trying to come up with a scheme that wouldn't require my users to remap keys in the sim.

Assuming users haven't made their own assignments or changes in the Sim's key assignments, there are plenty of combinations of Ctrl + Shift + another which aren't defaulted in the Sim. The only problem with the choice of TAB + G was that TAB isn't used as a shift key in the Sim.

I don't remember details of the 3210 method, but they are documented and i can look them up. But it would be better for you to ask specific questions about things you don't understand than for me to basically write the code for you.

Pete

 

Share this post


Link to post
Share on other sites

Hi Pete,

I guess what I'm looking for is a way to scan for available hotkey slots in the 3210 block in a lua script.

Then I need to figure out how best to detect them using events. I think I know how to do the event part using event.offset on one of the bytes, but maybe there's a better way.

Sorry for the newbie questions. Lua isn't my strong point yet.

 

 

 

 

 

Share this post


Link to post
Share on other sites

I'm trying to figure out how to write a dword into offset 3210 for a test key using a lua script.

If I wanted tab+b, would I write it into the offset as ipc.writeUD(0x3210, 0x00000842)

08 being the hex representation of the bit 4 set in byte 1 and 42 being the hex representation of key code 66 in byte 0. If so, it isn't working.

I've got an event set to fire when offset 0x3213 changes to indicate the key has been pressed, but it isn't triggering.

I could have this all backwards. I'm not at all familiar with manipulating things like this.

 

 

 

Share this post


Link to post
Share on other sites
2 hours ago, Jason Fayre said:

I'm trying to figure out how to write a dword into offset 3210 for a test key using a lua script.

You should really read the offsets list as I just did. For 3210 it says:

 

56 DWORDs containing zero (when free for use), or a Hot Key specification.

Notice that zero (when free for use)? There are 56 DWORDs starting at 3210. You must scan them to find a zero one which you can use. Other applications or plug-ins may be using others.

THEN, you can write the specification of the key you want detected.

2 hours ago, Jason Fayre said:

08 being the hex representation of the bit 4 set in byte 1 and 42 being the hex representation of key code 66 in byte 0. If so, it isn't working.

Well, 0x42 is 'B', but how do you work out that 0x08 is bit 4? 

Bit 4 = 2^4 = 16 = 0x10. If you do not understand hexadecimal and bits please see this thread in the FAQ subforum:
About bits, numbers and hexadecimal
 

2 hours ago, Jason Fayre said:

I've got an event set to fire when offset 0x3213 changes to indicate the key has been pressed, but it isn't triggering.


Probably because of your error above. But don't forget the offset address will be whatever slot you found empty and so used + 3, not necessarily 0x3213. Best to keep a note of it. Also after detecting it remember to write zero to that byte offset so it can be triggered again.

Pete

 

 

Share this post


Link to post
Share on other sites

Thanks Pete!

Your absolutely right, I was counting the bits wrong.

It's working now. One more question. Do these offsets get cleared when the aircraft changes? I have a different set of keys depending on the particular aircraft the user has running.

 

Share this post


Link to post
Share on other sites
43 minutes ago, Jason Fayre said:

One more question. Do these offsets get cleared when the aircraft changes? I have a different set of keys depending on the particular aircraft the user has running.

No. Those offsets are solely under control of the application -- FSUIPC only scans them to flag keypress occurrences.

Pete

 

Share this post


Link to post
Share on other sites

@Jason Fayre I have added an additional ini parameter LuaTrapKeyEvent which you can add to the [General] section of your ini  to prevent lua key events being passed on to P3D:
        LuaTrapKeyEvent=Yes

If possible, could you try the following dll please (v6.0.9a): FSUIPC6.dll

Thanks,

John

Share this post


Link to post
Share on other sites

Hi John!

I will give this a shot. I have since modified my lua scripts to use the key offsets at 0x3210, but this would simplify my code a lot.

Thanks so much for adding this!

 

Share this post


Link to post
Share on other sites

No problem. I checked it here and seems to work fine, but I always like to get the user to check requested additions.

I'll probably release this officially within the next few days or so, together with a few other updates.

Cheers,

John

Share this post


Link to post
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...

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