Near simultaneous clicks not recognized

[Henrik Bergvin]

I've picked up the Honeycomb Bravo throttle, which is a really amazing piece of software. Not before having had something that can do reversers properly, I set about programming it.

I have a LUA script with an event.param listening for LuaValue (ipcParam) changes. I then have a function as described below to handle the reverser states (for further logic that is not relevant for this support question).

-- this is in pmdg_b777_functions.lua
B777 = {
    engines = {
        [1] = {
            name = "left",
            rev = false,
            rev_fraction_offset = 0x207C,
            control = 65820
        },
        [2] = {
            name = "right",
            rev = false,
            rev_fraction_offset = 0x217C,
            control = 65821
        },

function B777.Reverser(engine, mode)
    if mode == "off" then               -- reversers to off
        ipc.control(B777.engines[engine].control, 0)
    elseif mode == "activate" then      -- reversers from off to idle
        ipc.control(B777.engines[engine].control, -1)
    end
end

return B777
    
-- The following is in the main script
B777 = require('pmdg_b777_functions')
    
param_table = {
   	[406]		= function() B777.Reverser(1, "activate") end,
	[407]		= function() B777.Reverser(1, "off") end,
  	[409]		= function() B777.Reverser(2, "activate") end,
	[410]		= function() B777.Reverser(2, "off") end,
}
    
function b777_param(param)
	ipc.log("Param: " .. param)
	if param_table[param] ~= nil then 
		param_table[param]()
		return
	end
end
    
event.param("b777_param")

Now, individually each reverser lever works exactly as they should. I set it to reverse, it sets the axis to -1 (which is basically reverser idle), and when I release the button it sets it to idle (axis to 0).

Now to my issue - when landing you tend to flip the reverse levers more or less simultaneously. This does not always seem to trigger both of them. If I flip both left and right engine reverser levers at the same time, I tend to get param 406, but not 409. Sometimes it is the other way around and I get 409, but not 406.

Note - I'm using a table for parameter lookup here, but it isn't exclusive to this script. I'm also using the hidAlphaButtons and hidBravoButtons scripts (from here https://forum.simflight.com/topic/91599-lua-scripts-for-honeycomb-bravo-quadrant-and-alpha-flight-controls-buttons-32/)

Is there a good way to catch multiple button presses that are nigh on simultaneous? This goes for both press and releases in this case..

 

[Masterius]

Not sure if this will work, but look in your FSUIPC(x).ini file for the following:

[Buttons]
PollInterval=25

See if decreasing the poll Interval helps.

 

From the Advanced User Guide:

PollInterval=25: This parameter tells FSUIPC how often to read (“poll”) the joystick buttons. The time is in
milliseconds, and the default, as shown, is 25 (40 times a second).
A polling rate of 0 will stop FSUIPC looking at buttons altogether, and in fact this will remove the Buttons & Switches
tab from the FSUIPC options. This may come in useful for checking whether a rogue joystick driver is causing
problems.
A polling rate of 40 per second is more than adequate for all normal button programming. It is only when you come to
the more advanced uses that you may want to change this. Rotary switches, for instance, may give pulses so fast that
some are missed at such a rate.
Any value from 1 millisecond upwards can be specified, but those from 50 upwards result in a specific number of
“ticks” (55 mSecs) being used. i.e. 40–82 actually result in 55 (1 tick), 83–138 in 2 ticks, and so on. Ticks are also
approximate, in that they depend on the other activities and loading upon FS.
Values 1–59 milliseconds are actually handled by a separate thread in FSUIPC and give more accurate results, but note
that polling the joysticks too frequently may damage FS’s performance, and may even make its response to joystick
controls more precarious. No truly adverse effects have been noticed during testing, but it is as well to be warned. If you
think you need faster button polling, try values in the range 10–25, and make sure that FS is still performing well each
time.
Note that the PFCcom64 and PFChid64 “emulated” joysticks (those with numbers 16 upwards) are polled four times
more frequently in any case—this is done because there is no overhead in doing so—there are no calls to Windows but
merely some data inspections.

[Henrik Bergvin]

Just now, Masterius said:

Not sure if this will work, but look in your FSUIPC(x).ini file for the following:

[Buttons]
PollInterval=25

See if decreasing the poll Interval helps.

I'll give that a shot, see if a 15ms interval helps. I've dabbled a bit with hid reading through the com library, and in that I could always capture all the buttons changed even with 40ms polling.. It's not as simple though for the bravo, since it seems to be sending some "ghost" presses now and then that I can't just filter - therefore I went for the standard binding and passing params via LuaValue.

[aua668]

Hi,

One question, which might be stupid, as I am not aware about the hardware you are using: Why are you not using four simple button assignments triggering the controls with the desired parameter?

Rgds
Reinhard

 

[Henrik Bergvin]

5 hours ago, aua668 said:

Hi,

One question, which might be stupid, as I am not aware about the hardware you are using: Why are you not using four simple button assignments triggering the controls with the desired parameter?

Rgds
Reinhard

 

Honeycomb Bravo for the reversers, so each reverse lever is a button push/release. 
 

While it would work setting the controls directly (throttle set to -1 to activate rev, throttle cut or set to 0 to cancel reverse), I have other logic I want to run (such as moving the thrust levers I to their bottom detent to command max reverse, but only if I have already flipped reverse levers...)

What I have found in today’s testing is that the LuaValue and LuaToggle functionality isn’t being processed fast enough. Button presses and binds work fine but the lua script isn’t receiving and processing the events fast enough on near simultaneous presses. 

[Henrik Bergvin]

19 hours ago, Masterius said:

Not sure if this will work, but look in your FSUIPC(x).ini file for the following:

[Buttons]
PollInterval=25

See if decreasing the poll Interval helps.

 

From the Advanced User Guide:

PollInterval=25: This parameter tells FSUIPC how often to read (“poll”) the joystick buttons. The time is in
milliseconds, and the default, as shown, is 25 (40 times a second).
A polling rate of 0 will stop FSUIPC looking at buttons altogether, and in fact this will remove the Buttons & Switches
tab from the FSUIPC options. This may come in useful for checking whether a rogue joystick driver is causing
problems.
A polling rate of 40 per second is more than adequate for all normal button programming. It is only when you come to
the more advanced uses that you may want to change this. Rotary switches, for instance, may give pulses so fast that
some are missed at such a rate.
Any value from 1 millisecond upwards can be specified, but those from 50 upwards result in a specific number of
“ticks” (55 mSecs) being used. i.e. 40–82 actually result in 55 (1 tick), 83–138 in 2 ticks, and so on. Ticks are also
approximate, in that they depend on the other activities and loading upon FS.
Values 1–59 milliseconds are actually handled by a separate thread in FSUIPC and give more accurate results, but note
that polling the joysticks too frequently may damage FS’s performance, and may even make its response to joystick
controls more precarious. No truly adverse effects have been noticed during testing, but it is as well to be warned. If you
think you need faster button polling, try values in the range 10–25, and make sure that FS is still performing well each
time.
Note that the PFCcom64 and PFChid64 “emulated” joysticks (those with numbers 16 upwards) are polled four times
more frequently in any case—this is done because there is no overhead in doing so—there are no calls to Windows but
merely some data inspections.

 

so, I changed to a poll rate of 10, and it still wouldn’t update the lua script enough. However, I can do normal controls and standard Fs actions at near simultaneous trigger. So it lies in the communication with the Lua script. I’ll keep digging. Maybe event.button might be a thing here. 

[Henrik Bergvin]

Maybe @Pete Dowson can shed some light on this:

 32283172 Button changed: bRef=0, Joy=4 (E), Btn=9, Pressed
 32283172 [Buttons.PMDG 777F Arctic Air] 104=PE,9,C65820,-1
 32283172 FS Control Sent: Ctrl=65820, Param=-1 THROTTLE1_SET
 32283172 Button changed: bRef=0, Joy=4 (E), Btn=10, Pressed
 32283172 [Buttons.PMDG 777F Arctic Air] 108=PE,10,C65821,-1
 32283172 FS Control Sent: Ctrl=65821, Param=-1 THROTTLE2_SET
 32283172 Button changed: bRef=0, Joy=4 (E), Btn=9, Pressed
 32283172 Button changed: bRef=0, Joy=4 (E), Btn=10, Pressed


 32486672 Button changed: bRef=0, Joy=4 (E), Btn=9, Pressed
 32486672 [Buttons.PMDG 777F Arctic Air] 104=PE,9,CL41:V,406
 32486672 Button changed: bRef=0, Joy=4 (E), Btn=10, Pressed
 32486672 [Buttons.PMDG 777F Arctic Air] 108=PE,10,CL41:V,409
 32486672 Button changed: bRef=0, Joy=4 (E), Btn=9, Pressed
 32486672 Button changed: bRef=0, Joy=4 (E), Btn=10, Pressed
 32486672 LUA.3: Param: 409

Above are two log excerpts - one where I am sending FS Controls, and one where I'm sending a LuaValue change. As you can see, only param 409 comes through on the LuaValue example... Can Lua capture changes faster somehow? The buttons are definitely caught.

[John Dowson]

What version of FSUIPC are you using? There was a fix in FSUIPC6 v6.10.12 relating to the timings for repeat button presses (both real and virtual).
This update has now been applied to FSUIPC5. If you are using that, I could apply it there to see if that helps.

[Henrik Bergvin]

7 minutes ago, John Dowson said:

What version of FSUIPC are you using? There was a fix in FSUIPC6 v6.10.12 relating to the timings for repeat button presses (both real and virtual).
This update has now been applied to FSUIPC5. If you are using that, I could apply it there to see if that helps.

I was on 6.0.9, I'm now updating to 6.0.12 to give it a try. I'll report back!

[Henrik Bergvin]

2 hours ago, John Dowson said:

What version of FSUIPC are you using? There was a fix in FSUIPC6 v6.10.12 relating to the timings for repeat button presses (both real and virtual).
This update has now been applied to FSUIPC5. If you are using that, I could apply it there to see if that helps.

I tried on .12, but didn't get any particular better LuaValue/event.param triggers. I did, however, get a lot better result using event.button, those would trigger almost at the same time and the script would capture them even faster than event.param.

[John Dowson]

12 minutes ago, Henrik Bergvin said:

I tried on .12, but didn't get any particular better LuaValue/event.param triggers.

Yes...is the speed an issue, or is the problem with the parameter being lost for the first call here:

Quote

 32486672 Button changed: bRef=0, Joy=4 (E), Btn=9, Pressed
 32486672 [Buttons.PMDG 777F Arctic Air] 104=PE,9,CL41:V,406
 32486672 Button changed: bRef=0, Joy=4 (E), Btn=10, Pressed
 32486672 [Buttons.PMDG 777F Arctic Air] 108=PE,10,CL41:V,409
 32486672 Button changed: bRef=0, Joy=4 (E), Btn=9, Pressed
 32486672 Button changed: bRef=0, Joy=4 (E), Btn=10, Pressed
 32486672 LUA.3: Param: 409

You are sending two different parameters to the same script at the same time, so it looks like the second is overwriting the first before it is processed (they are global parameters/variables). I'm not sure if I can do anything about this but I'll take a look (may take a few days to get around to this).

[Henrik Bergvin]

Just now, John Dowson said:

Yes...is the speed an issue, or is the problem with the parameter being lost for the first call here:

You are sending two different parameters to the same script at the same time, so it looks like the second is overwriting the first before it is processed (they are global parameters/variables). I'm not sure if I can do anything about this but I'll take a look (may take a few days to get around to this).

Correct, the problem is that there are two LuaValue params sent to the same script at the same time, and only one is captured. By using event.param, it's simply not able to capture both if they are immediate/simultaneous. Unless you have a better suggestion, I'll use event.button, since it seems fast enough to capture the buttons rapidly.

Speed isn't the issue here at all 🙂

[John Dowson]

Ok, understood. Use event.button for now. I'll make a note to look into the LuaValue param issue when I get a chance.

[Henrik Bergvin]

Just now, John Dowson said:

Ok, understood. Use event.button for now. I'll make a note to look into the LuaValue param issue when I get a chance.

Cheers! Are there any drawbacks for using event.button? I quite like having as much as possible in lua files (since I can work on them without the sim running and do logic based on which buttons are held etc), and it wouldn't be a big matter for me to make some form of system where I define button presses like this:

left_reverser_activate = { 
	button = { 4, 9, 1 }, -- button 4,9 is pressed
  	action = { "B777.ReverserLever", "left", "activate" }, -- B777.ReverserLever("left", "activate")
},
left_reverser_off = { 
	button = { 4, 9, 0 }, -- button 4,9 is released
  	action = { "B777.ReverserLever", "left", "off" }, -- B777.ReverserLever("left", "off")
}

Using the above, I could just loop through all the actions and register events for the presses.

I know the binding facility built into FSUIPC is nice and all, but once you start doing something more complex (like, tracking several variables), Lua is really the way to go.

 

Oh! If a lua script is running something and a button press happens, will event.button be queued and run when the script is "awake" again?

[John Dowson]

5 minutes ago, Henrik Bergvin said:

Are there any drawbacks for using event.button?

No, shouldn't be an issue.

8 minutes ago, Henrik Bergvin said:

Oh! If a lua script is running something and a button press happens, will event.button be queued and run when the script is "awake" again?

No - the event.button just registers the callback function. The rest of the script will process and the thread keeps running once the end of the script is reached. When the button is pressed, this is picked up (by the still running lua thread) and you callback function called.

 

[Henrik Bergvin]

3 minutes ago, John Dowson said:

No, shouldn't be an issue.

No - the event.button just registers the callback function. The rest of the script will process and the thread keeps running once the end of the script is reached. When the button is pressed, this is picked up (by the still running lua thread) and you callback function called.

 

Perfect, so event.button shouldn't miss any presses even if the script is busy. Thank you for your help!

[Pete Dowson]

2 hours ago, Henrik Bergvin said:

Correct, the problem is that there are two LuaValue params sent to the same script at the same time, and only one is captured. By using event.param, it's simply not able to capture both if they are immediate/simultaneous.

It is simple to understand. The second overwrites the first. It is a simple parameter value, stored in the global reserved as IPCparam. Were you expecting multiple values to be queued up? For how long? I really don't think it is reasonable to operate such queues. 

How are you managing to send two successive LuaValue controls in the same millisecond? That sounds rather crazy! Are your fingers and keyboard or button device really so fast?

There is a separate ipcPARAM value for each plug-in. Perhaps having separate plugs would solve your problem, however you managed to create it?

Pete

 

[Henrik Bergvin]

10 minutes ago, Pete Dowson said:

It is simple to understand. The second overwrites the first. It is a simple parameter value, stored in the global reserved as IPCparam. Were you expecting multiple values to be queued up? For how long? I really don't think it is reasonable to operate such queues. 

This I fully get behind, there's no reason to operate a queue for an IPCparam since it's not really supposed to handle rapid presses.

11 minutes ago, Pete Dowson said:

How are you managing to send two successive LuaValue controls in the same millisecond? That sounds rather crazy! Are your fingers and keyboard or button device really so fast?

On the reverser levers on my Honeycomb Bravo, I just place my hands behind and pull them both simultaneously. It is most probably not simultaneous by millisecond, but their status is most probably handled by the same poll of the hid device, and as such it will appear as if they were triggered simultaneously.

12 minutes ago, Pete Dowson said:

Perhaps having separate plugs would solve your problem, however you managed to create it?

That could work, but that would mean two identical files with different names, doing the same thing... I'll stick to event.button, it seems robust 🙂

[Pete Dowson]

16 hours ago, Henrik Bergvin said:

I'll stick to event.button, it seems robust 🙂

Well, yes -- they would be two separate buttons so both are seen as different entities. And for button events the use of event.button is more appropriate.

Pete