Jump to content
The simFlight Network Forums

Is there some sort of button timer I can use?


Recommended Posts

Okay, so I'm fairly certain fsuipc 'sees' the button presses from my hardware.  Although in my opinion it isn't perfect.  Let me explain.  The hardware was an interface software, when I go into fsuipc and either in the button or keys tab and press my hardware, nothing happens in the buttons tab, and it seems to be confused in keys as well; like there's ghosted data... (I'm using shift and control modifiers with F keys generally, but let's say I'm just using letters), If I assign Input 1 as "a" and input 2 as "b" then go to fsuipc, pressing input 1 might give me a, but then pressing input 2 might also give me a... if I press input 2 multiple times over it might give me b and then if I press input 7I might also get a "b".  Often times it stays blank, it's weird.  This is not a major concern however because in the Sim it works wow well, one press of all inputs and they perform their programed function.  In my .ini files you will see the programming for those keypresses in the [Keys] section, so this is ONLY "programmed" in fsuipc; therefore it must be interpreting the hardware panel properly. 

Link to comment
Share on other sites

  • Replies 53
  • Created
  • Last Reply

Top Posters In This Topic

17 hours ago, Iceking007 said:

If I assign Input 1 as "a" and input 2 as "b" then go to fsuipc, pressing input 1 might give me a, but then pressing input 2 might also give me a... if I press input 2 multiple times over it might give me b and then if I press input 7I might also get a "b".  Often times it stays blank, it's weird.  This is not a major concern however because in the Sim it works wow well, one press of all inputs and they perform their programed function.  In my .ini files you will see the programming for those keypresses in the [Keys] section, so this is ONLY "programmed" in fsuipc; therefore it must be interpreting the hardware panel properly. 

I find this strange...if its acting weird in the key assignments tab, it will be acting weird for the actual assignments. However I have no idea what is happening as I still haven't seen a log file produced when you press your "key" buttons. Please show me that log.
If I were you, I would try the HidDemo.lua to see if that recognises those buttons and can convert them to virtual button presses. 

Also, can you please explain exactly what you are trying to achieve using your yoke buttons and other devices "key" buttons - just the functionality you are aiming for when you use these (without mentioning virtual buttons or flags!). I don't understand this:

Quote

 

The five buttons on the hw panel are ideally going to have 4 'soft' controls that will react to whether or not I select 2,4/2,5/2,6/2,7 or press the fifth button on the hw panel.  

 

what do you mean by '2,4/2,5/2,6/2,7'? I uderstand you want to change the control sent when using the soft buttons, but not sure how/what ither buttins you want to use to do this.

Link to comment
Share on other sites

Okay, so here's the short story long...

 

I own one of Ruscool's RNS530 hardware panels, I also purchased Reality XP's GNS530 & 430 software packages; however I cannot get the RXP software to work on my computer... I'm hoping someone will help me sort that out, but so far nothing.  In the meantime I am configuring the panel to function with the default fs GPS 500.

I programed all the keys,.ini, and .cfg files, and integrated it into the Sim.  However as I'm sure you're aware, the GPS500 does not have the same functionality and therefore does not use as many inputs; leaving me with spare inputs to configure for other uses.  That is what I'm trying to attempt.  So my RNS530 panel is completely configured through the fsuipc.ini file and all the functions work well; so the confusing "key reads" I described in fsuipc don't seem to be an issue, except that, for assignments, I cannot assign them with the fsuipc UI; I had to go and manually input them into the .ini file for it to work :: and it does. 

Now keeping with the theme of the GNS530 I thought it would be handy to utilize the COM and NAV features to assist those variables.  I do have radio panels, but that frees a couple displays up for other variables such as ADF, Txp, DME etc... as required (so bumping the stack up).  I also then considered it would be extremely to be able to adjust other variables, such as CRS, HDG, ALT, VS, etc. So that's essentially what I'm attempting to accomplish. 

 

To answer your query, 2,4/2,5/2,6/2,7 are "available" joystick buttons I'm considering allocating to the project.  Joystick 2 button 4 etc.

 

Sorry, I haven't been able to get the log file for you; I will try to do that.  (buttons only as requested)

 

Thank you. 

Link to comment
Share on other sites

On 2/27/2022 at 9:02 PM, Iceking007 said:

Sorry, I haven't been able to get the log file for you; I will try to do that.  (buttons only as requested)

But I thought your button (conditional) assignments work working, and it was the key assignments that you were having issues with....

On 2/27/2022 at 9:02 PM, Iceking007 said:

so the confusing "key reads" I described in fsuipc don't seem to be an issue, except that, for assignments, I cannot assign them with the fsuipc UI; I had to go and manually input them into the .ini file for it to work :: and it does. 

This is what is worrying me...if there are confusing "key reads" in the assignment panel, I would have thought they would also be confused in the assignments themselves...but logging should show this...

Conditional and compound assignments work the same way on keys as they do on buttons. If they are working for you as expected on buttons but not on the keys, I suspect it is related to these spurious key reads you are getting from the device...

Link to comment
Share on other sites

I had those very same thoughts as well.  So as a test I input into the fsuipc.ini file to use plain old keyboard keys, such as "H" , or "O".  Obviously fsuipc detects these perfectly; however it still did not work with that code. 

 

Yes, my joystick buttons do work without error.

 

As I said, it's very strange, I fail to see the logic in it. 

Link to comment
Share on other sites

28 minutes ago, Iceking007 said:

So as a test I input into the fsuipc.ini file to use plain old keyboard keys, such as "H" , or "O".  Obviously fsuipc detects these perfectly; however it still did not work with that code. 

Ok, then maybe we should try and figure out what is wrong when using standard keys first. If we can get it working with those, then after switch to your devices keys.
So, configure with standard keyboard input, and then show me the your ini and log files (with logging activated for buttons + keys and events), and we can see what is happening, and take it from there.

Link to comment
Share on other sites

Okay, so perhaps a was mistaken... I had a brief few minutes after work today to try and get some full logs. 

 

So what happens is, when I opt to use virtual buttons to activate my controls, the system fails to respond accordingly; regardless if I'm activating those virtual buttons with key strokes or hardware buttons.  However when I use only hardware buttons, the functionality is a expected.  Please note, this is the exact code, the only changes are swapping out of hardware versus virtual buttons. 

ie: instead of using 2,0 for joystick, I change that to 11,11.  All the flags are done on virtual buttons and that works.  But if I change 2,0 to 11,11 and call it with a C1070,2827 (256*11+11) the chain is broken somewhere. 

 

Attached are a variant of the .ini file I used, one log file that worked with joystick buttons and one log file that didn't work (I can't recall all the details, sorry, I was quite rushed to get this out to you; typically I like to be thorough and organized, this is only about 40% I'm afraid).

 

P.S. I have been working substantially on my Lua file.  I'm getting very close with it and although it's probably just going to replace all of this I'd really like to learn/ figure out what's going wrong; this is so simple it should be working, and I don't like to leave simple problems unsolved - not good for the brain. 

I'll be needing some help with integrating the Lua file, but for now we could just stick to this; I can create a posting elsewhere for that and the other difficulties I am having. 

Hopefully those log files help you.  As always, thank you very much. 

P.P.S. The log files were done one at a time.  Configure .ini, load fs, start log, press buttons/keys, stop log quit; repeat.  Please remove one you have them.  ty

 

Link to comment
Share on other sites

If you had checked your ini file you would find that your key assignments to control 1070  are invalid and have been ignored:

Quote

109=121,11,C1070,2827    ;LKP    (65582)/(65585) << ERROR 24! Line ignored >>
110=122,11,C1070,2828    ;LKIL    (65638)/(65642) << ERROR 24! Line ignored >>
111=123,11,C1070,2829    ;LKIR    (65639)/(65643) << ERROR 24! Line ignored >>
112=124,11,C1070,2830    ;LKOL    (65636)/(65640) << ERROR 24! Line ignored >>
113=125,11,C1070,2831    ;LKOR    (65637)/(65641) << ERROR 24! Line ignored >>

The 'C' character is not needed in key assignments. Remove those and try again. Attach your ini and log file (keyboard keys) again if any issues.

John

Link to comment
Share on other sites

Hi John, 

I'll look into that further this weekend, thank you for that. 

 

A couple quick questions if you don't mind re- Lua.  Is it safe to assume that when fs&fsuipc first starts/ loads a flight all values are 0'ed; eg flags, toggle etc... also would a 0 be the same as nil?  (mostly I'm using ~=0 but it's good to know.)

 

Also, if you're tracking a panel toggle, say p2 (radio panel) or p3 (gps), If they start visible would their toggle still be 0 or is that going to report as 1?

Link to comment
Share on other sites

5 hours ago, Iceking007 said:

Is it safe to assume that when fs&fsuipc first starts/ loads a flight all values are 0'ed; eg flags, toggle etc

That depends on what values you are talking about...If you mean lua variables, I am not sure how they are initialised - check the lua documentation.
For FSUIPC flags/offsets, they are initially 0 but will be populated as data is received, or button presses, etc.

5 hours ago, Iceking007 said:

also would a 0 be the same as nil?

Not necessarily. nil in lua means 'no object' or an uninitialised object reference. See https://findanyanswer.com/what-is-a-nil-value-in-lua.

5 hours ago, Iceking007 said:

Also, if you're tracking a panel toggle, say p2 (radio panel) or p3 (gps), If they start visible would their toggle still be 0 or is that going to report as 1?

Toggle controls toggle the value as known by the FS, so if they start visible and you toggle the visibility then they become hidden - the value is irrelevant.
If you are talking about FSUIPC toggle controls (e.g. offset toggle controls), they will toggle the value found in the offset.
Anyway, why don't you just try it....

Link to comment
Share on other sites

Hi John,

 

Okay what a headache this is... hopefully this helps you.  I have two new log files, (1) is for keyboard keys, (2) is for my Lua file.  Neither worked.  Hopefully you find the problems; I think there should be a good log of the hardware panel because I had the logging enabled and used the buttons that did work and they functioned well... it's the customizing that isn't going well. 

 

I'm not sure I integrated my Lua file properly; none of the code seemed to run... I added the [Auto] entry into my .ini file as you will see.

 

Thank you. 

 

I'm about to give up on this while project.  This stupid thing!

 

Link to comment
Share on other sites

9 hours ago, Iceking007 said:

(2) is for my Lua file.

What lua file? You haven't mentioned lua before, and I have not seen any lua files from you. Can we please stick to one problem at a time.
I am not going to look at those, as I have no idea what you are doing with lua...

9 hours ago, Iceking007 said:

I added the [Auto] entry into my .ini file as you will see.

That looks ok (except it should be 'Lua' not 'lua', but that shouldn't matter, but change just in case). I presume you didn't insert the [LuaFiles] entry, and this was created by FSUIPC, no? If so, then I don't know why your lua isn't running - there are no lua scripts being started according to your log. 

As for your 'keyboard keys' log, what exactly am I looking for? Why have you attached such a large log? Have you looked at this yourself to try and work out what is happening? I am certainly not going to go through a log file containing over 4000 lines with no indication from you what the problem is (i.e. what key press do you think is not performing as expected?) You can see the key presses registered, and the actions taken on that key press. What is incorrect?

Why don't you try keeping the log open and see what messages are logged when you press your buttons or keys. This should tell you what is happening, and if it is not as expected, then show me (i.e. a concrete example of an individual key press that is not behaving as you expect).

 

Link to comment
Share on other sites

So I'm learning a little bit about logging.  I have some new data; does this help us at all?

 

I started fs and turned on my battery and avionics; that's all, and then I pressed one button.  Here is what I can tell is the last line from the avionics master switch, and then everything else the log wrote from only the one button press. 

110641 *** EVENT: Cntrl= 66293 (0x000102f5), Param= 0 (0x00000000) TOGGLE_AVIONICS_MASTER
   130703 FSUIPC Control Action: Ctrl=1125, Param=0
   130703 FSUIPC Control Action: Ctrl=1070, Param=2937
   130703 SendKeyToFS(00060079=[ctl+shft+F10], KEYDOWN) ctr=0 
   130703 Sending WM_KEYDOWN, Key=16 (Shift) (Scan code 42), Ctr=3
   130703 Sending WM_KEYDOWN, Key=17 (Control) (Scan code 29), Ctr=3
   130703 KEYDOWN: VK=16, Waiting=0, Repeat=N, Shifts=1
   130703 .. Key not programmed -- passed on to FS
   130703 KEYDOWN: VK=17, Waiting=0, Repeat=N, Shifts=3
   130703 .. Key not programmed -- passed on to FS
   130750 Sending WM_KEYDOWN, Key=121 (Scan code 68), Ctr=1
   130750 KEYDOWN: VK=121, Waiting=0, Repeat=N, Shifts=3
   130750 FSUIPC Control Action: Ctrl=1070, Param=2827
   130750 SendKeyToFS(00060079=[ctl+shft+F10], KEYUP) ctr=0 
   130750 SendKeyToFS(0006000B=[ctl+shft+(null)], KEYDOWN) ctr=3 
   130750 .. This key is programmed in FSUIPC 'Keys' options
   130781 Sending WM_KEYUP, Key=121 (Scan code 68), Ctr=6
   130781 KEYUP: VK=121, Waiting=0
   130813 Sending WM_KEYUP, Key=17 (Control) (Scan code 29), Ctr=5
   130813 Sending WM_KEYUP, Key=16 (Shift) (Scan code 42), Ctr=5
   130813 Sending WM_KEYDOWN, Key=16 (Shift) (Scan code 42), Ctr=5
   130813 Sending WM_KEYDOWN, Key=17 (Control) (Scan code 29), Ctr=5
   130813 KEYUP: VK=17, Waiting=0
   130813 KEYUP: VK=16, Waiting=0
   130813 KEYDOWN: VK=16, Waiting=0, Repeat=N, Shifts=1
   130813 .. Key not programmed -- passed on to FS
   130813 KEYDOWN: VK=17, Waiting=0, Repeat=N, Shifts=3
   130813 .. Key not programmed -- passed on to FS
   130844 Sending WM_KEYDOWN, Key=11 (Scan code 0), Ctr=1
   130844 KEYDOWN: VK=11, Waiting=0, Repeat=N, Shifts=3
   130844 .. Key not programmed -- passed on to FS
   130875 SendKeyToFS(0006000B=[ctl+shft+(null)], KEYUP) ctr=0 
   130875 Sending WM_KEYUP, Key=11 (Scan code 0), Ctr=1
   130875 KEYUP: VK=11, Waiting=0
   130906 Sending WM_KEYUP, Key=17 (Control) (Scan code 29), Ctr=2
   130906 Sending WM_KEYUP, Key=16 (Shift) (Scan code 42), Ctr=2
   130906 KEYUP: VK=17, Waiting=0
   130906 KEYUP: VK=16, Waiting=0

 

This button (I presume - imo) did not do anything useful...

Now to compare that log with the next code; which after I pressed that button, looked at the log file, saved the log file externally, then I only pressed one more button; the hardware 'sister' button to that one; this is the log script from that one to this one:

 

391281 FSUIPC Control Action: Ctrl=1125, Param=2937
   391281 FSUIPC Control Action: Ctrl=1070, Param=2422
   391281 SendKeyToFS(00040076=[shft+F7], KEYDOWN) ctr=0 
   391281 Sending WM_KEYDOWN, Key=16 (Shift) (Scan code 42), Ctr=2
   391281 KEYDOWN: VK=16, Waiting=0, Repeat=N, Shifts=1
   391281 .. Key not programmed -- passed on to FS
   391313 Sending WM_KEYDOWN, Key=118 (Scan code 65), Ctr=1
   391313 KEYDOWN: VK=118, Waiting=0, Repeat=N, Shifts=1
   391313 FS Control Sent: Ctrl=66624, Param=0
   391313 .. This key is programmed in FSUIPC 'Keys' options
   391313 *** EVENT: Cntrl= 66624 (0x00010440), Param= 0 (0x00000000) GPS_CURSOR_BUTTON
   391422 SendKeyToFS(00040076=[shft+F7], KEYUP) ctr=0 
   391422 Sending WM_KEYUP, Key=118 (Scan code 65), Ctr=1
   391422 KEYUP: VK=118, Waiting=0
   391453 Sending WM_KEYUP, Key=16 (Shift) (Scan code 42), Ctr=1
   391453 KEYUP: VK=16, Waiting=0

 

Does that help us in determining what is happening and what isn't happening?

I thought maybe the Ctrl is the problem, so I briefly changed the command in fsuipc to another function and it worked.  So it's not the hardware, the button, or the assignment.  FSUIPC appears to be registering and processing it.  There seems to be some sort of disconnect between the "keys" activating virtual buttons.  I even changed my fsuipc code to remove the conditional formatting for the buttons (ie no modes, just plainly activate the command - fixed- ) no luck there either.  So to me, it definitely seems to be a broken link between keys and virtual buttons. 

Link to comment
Share on other sites

Can you attach your ini file again please so that I can understand hoe log extracts? I always need to see the ini that produces a log file.
Also strange that there are no button presses registered in these log extracts, or did you omit them? Best to include them...

6 hours ago, Iceking007 said:

There seems to be some sort of disconnect between the "keys" activating virtual buttons.  I even changed my fsuipc code to remove the conditional formatting for the buttons (ie no modes, just plainly activate the command - fixed- ) no luck there either.  So to me, it definitely seems to be a broken link between keys and virtual buttons. 

But there is no link between keys and virtual buttons, unless you are using one if the button flag controls (1003, 1004, 1005). The last time I looked at your log, you seemed to be sending further key presses on your key assignments, using control 1070, which seemed strange to me (why send key presses on key presses....!).  Anyway, this should be easy to check. But I need to see your ini.

 

Link to comment
Share on other sites

19 minutes ago, Iceking007 said:

"1070 Key Press and Release (param is Keycode + 256*Shift code, or JsBk)" - JsBk?

So this is not possible then??

No -JsBk is jut an alternative way to define the key - J<shift code>B<keycode>. That’s what the ‘s’ and ‘k’ represent. It is not JjBb! The J and B construction was a form already interpreted for controls 1003, 1004, 1005. Sorry if that is confusing. It is controls 1003, 1004 and 1005 you need to use to set/clear/toggle button flags from keys, not 1070 which is for sending key presses only.

Thats why you are seeing all of those key presses in the logs - the assignments to those keys are triggering further key presses...

John

Link to comment
Share on other sites

Just now, Iceking007 said:

I don't know why you would need to have a button activate a key;

Needed to send a key press on a button press - is useful to assign buttons to the default keys assigned in the FS.

2 minutes ago, Iceking007 said:

I need a key to activate a button. 

You cannot activate a button press from a key. You can change a button flag on a key press, using controls 1003, 1004 and 1005.
But why do you need to do this? If you want to trigger a button action on a key press, just assign that key press to the button action (rather than triggering the button). If you also want to toggle a button flag on that key press, overload your assignments and also assign to change the button flag.

5 minutes ago, Iceking007 said:

So, I guess I can only use Lua?

I am sure you don't need to use lua for this...

John

Link to comment
Share on other sites

7 minutes ago, Iceking007 said:

But if you need a button to activate a key you just do that in the .ini file: n=p#,#,C#

Yes, you can do it that way. But 1070 is just an additional control that sends key presses, such as via offset 0x3110, for use by external programs, for example.

8 minutes ago, Iceking007 said:

I need to convert a key into a conditionally formatted command. 

You can apply conditionally formatted commands to key presses. As well as setting/clearing/checking the virtual (button) flags. So what is the problem?

Link to comment
Share on other sites

1 minute ago, Iceking007 said:

How do you do conditional formatting on keys?  If you can then that is a possible solution. 

The same as for buttons. As the documentation for the format of key conditions (at least in FSUIPC4 and later):

Quote

There are two reasons you may want to edit the details in the INI file. The first is to make a single button press operate
more than one control. You can specify such actions here, merely by adding the appropriate parameter lines. The
controls will be sent in the order of the parameter entries (i.e. the ‘n’ in “n= …”). You can view all these, and delete
them, in the Keys page on-line, but you cannot edit any other than the first such assignment for that key press.

 

The second reason is to add FSUIPC offset conditions. The facilities for making Button presses conditional upon
assorted FS internals all apply to Key programming too, and the format and other details are the same as for Buttons.
Please refer to the section above entitled “adding Offset Conditions”.

John

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.