[Near simultaneous clicks not recognized]

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 🙂

[Near simultaneous clicks not recognized]

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!

[Near simultaneous clicks not recognized]

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?

[Near simultaneous clicks not recognized]

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 🙂

[Near simultaneous clicks not recognized]

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.

[Near simultaneous clicks not recognized]

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!

[Near simultaneous clicks not recognized]

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.

[Near simultaneous clicks not recognized]

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. 

[Near simultaneous clicks not recognized]

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. 

[Near simultaneous clicks not recognized]

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.

[Near simultaneous clicks not recognized]

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

 

[event.timer function parameter]

36 minutes ago, John Dowson said:

I think it should be elapsed time, but you should easily be able to verify by just logging the value.

Yeah, I'll do that.

While I have you here, I'm doing polling at a rate of 25 per second. Right now it's on 2 devices, but will that be safe to do on 3-4 devices without causing any issues? I have absolutely no issues with delays using the COM library, but as with everything, as you increase the amount of devices... yeah.

I was also considering a faster poll rate to accommodate for a 20ms delay, 10ms repeat on held buttons (that's default in FSUIPC isn't it?).

[event.timer function parameter]

Since I like to do things the hard way around, I have written a "generic" HID device handler for advanced button functionality, using the COM library.

I've got tracking of button presses and releases right now, and events firing based on what button is pressed (B1_Press, B1_Release, etc), and fairly simple handling for this from lua scripts. Next up for me is to implement repeats and double presses.

Right now, I'm polling the devices using an event.timer call on a poll rate of 1000/25 (that should be every 40ms?), and it feels very stable and I never seem to "miss" any events.

However, I'm at a bit of a loss here regarding what event.timer is sending to the poll function. In the documentation it says "The time provided is NOT the same as the one returned by the ipc.elapsedtime function", but it actually doesn't say what time is provided. This information is rather vital for me if I'm to track double clicks or repeats in the script.

Is it elapsed time, or is it time since last time the timer fired?

[Unable to click cockpit buttons after FSUIPC LUA script action]

28 minutes ago, Pete Dowson said:

No, not for the same event type, only for different ones

 

29 minutes ago, Pete Dowson said:

For plug-ins being loaded each time you are really better off with smaller separate ones rather than very large ones proceeing one parameter then unloading.

Understood. I do find using LuaValue a bit faster than Lua for param based scripts, so I'll stick to that in the future. I'll bind a push button to kill and restart the script for testing purposes.

 

[Unable to click cockpit buttons after FSUIPC LUA script action]

On 8/11/2020 at 12:11 PM, Pete Dowson said:

Thank you. And please also try those alternative assignments I provided earlier for the PMDG 777.

Pete

 

It seems that using that method is a little better, I haven't had any issues with focus after trying those.

As for Lua scripts, is it better to call scripts using "Lua ScriptName" and a param, or do you recommend using the param event and passing LuaValue? I imagine events are queued and read one by one, so if two fire rapidly the script will run for the second once it is done with the first?

[Unable to click cockpit buttons after FSUIPC LUA script action]

50 minutes ago, Pete Dowson said:

Thank you. And please also try those alternative assignments I provided earlier for the PMDG 777.

Pete

 

I should mention that I am currently performing a flight in the 747, and have not had it happen at all. Only difference from my previous attempts were that I have installed the binding utility (and, I guess, driver package) for the Honeycomb Yoke. The yoke has more buttons than windows can detect (35) and the utility exposes those to the sim. I don't have anything bound to the last few buttons, but this *might* have been the issue.

I'll test your methods still, and let you know if they work out.

[Unable to click cockpit buttons after FSUIPC LUA script action]

7 hours ago, Pete Dowson said:

So if you can make it happen, without going overboard with scripting, for one or other of the default aircraft, that would make some basic debugging possible. Else we'd need to ascribe it to something the PMDG coding is doing. But the first thing to help would be trying with more direct means than the Lua scripting.

Alright, I will see if I have time to do some tests today on one of the default aircraft 🙂

[Unable to click cockpit buttons after FSUIPC LUA script action]

I am using custom controls like these in those aircraft too, and I wasn't aware I could check offset statuses with direct assignemts - I'll have to give that a try and see if it can work.

The event names are declared and imported usin the default LUA way:

require "pmdg_777_offsets"

I have it for the PMDG birds because of the sheer number of controls, and I like names instead of number, and they work, just sometimes it locks up the clickability for some reason. I have as of yet not managed to find a specific culprit...

I've attached the two lua files I use for the 747, as well as my profile, maybe you can see something in it. Also, i should mention that i have UseProfiles=Files set in FSUIPC6.ini.

As for default aircraft, I haven't seen the need to do any form of LUA scripting for those, since they're so basic I don't really touch them at all.. 

PMDG 747.lua pmdg_747_offsets.lua 747.ini FSUIPC6.ini

[Unable to click cockpit buttons after FSUIPC LUA script action]

Hello,

I am using FSUIPC6 on P3D v4.5, and quite often use LUA scripts to control my buttons - especially for functionality where I want to be able to do stuff like notifications or deal with two way buttons on my controllers.

I'm using the Thrustmaster Hotas Warthog (throttle and stick) and the Honeycomb Alpha Yoke. Those are the only USB game controllers attached to my system.

I'll show you a sample from one of my scripts:

-- I have these in a separate file (pmdg_777_offsets.lua)
THIRD_PARTY_EVENT_ID_MIN = 69632
EVT_OH_ELEC_GRD_PWR_PRIM_SWITCH	= THIRD_PARTY_EVENT_ID_MIN + 8
EVT_OH_ELEC_GRD_PWR_SEC_SWITCH = THIRD_PARTY_EVENT_ID_MIN + 7


-- My main script, called by button presses
-- External power
if ipcPARAM == 305 then
	-- Check if the ground power is off for each control, since button is a one-shot.
	if ipc.readSB(0x644C) == 1 then ipc.control(EVT_OH_ELEC_GRD_PWR_PRIM_SWITCH,1) end
	if ipc.readSB(0x644B) == 1 then ipc.control(EVT_OH_ELEC_GRD_PWR_SEC_SWITCH,1) end
end

if ipcPARAM == 306 then
  -- Check if the ground power is on for each control, since button is a one-shot.
	if ipc.readSB(0x644A) == 1 then ipc.control(EVT_OH_ELEC_GRD_PWR_PRIM_SWITCH,1) end
	if ipc.readSB(0x6449) == 1 then ipc.control(EVT_OH_ELEC_GRD_PWR_SEC_SWITCH,1) end
end

-- Button assignments on the Honeycomb Yoke
39=PD,16,CL41:R,305 	-{Lua PMDG 777}-
40=PD,17,CL41:R,306 	-{Lua PMDG 777}-

Quite often when I am running scripts like this, I lose "focus" in the simulator where I have to click outside the sim and back again for anything to register, sometimes multiple times. This is not exclusive to PMDG aircraft, I use it on the RealAir Turbine Duke and the Milviz King Air 350i, and have the same issue.

If I alt tab to a program and press escape, it is as if P3D has focus still, and escape brings up the "end scenario" screen, but no switches or in simulator buttons are working.

Any idea why this might be?

[Majestic Q400 V-speed calculator and setter]

19 hours ago, Christos Ch said:

Chris and Henrik thank you for your efforts on these great little tools!!! Since I am trying to write a lua script to automate the procedure to Cold and Dark state based on your scripts, I would like to ask for your help in how to locate the numbers of the corresponding levers, switches etc. (e.g. Control Lock, Parking Brake, Main Bus Tie and so on) as you probably have done in the following (from the VSpeeds.lua):

    SetQ400Value(180709, 0)
    ipc.sleep(100)
    SetQ400Value(93613, 0)
    ipc.sleep(100)

I tried the Log option of the FSUIPC but I can only find the Control Lock. I would appreciate any help!

Hello,

The after landing flow was not something I made myself, but was already there from the original script. However, to find these values, you'll have to look up the corresponding function. There is an excel document containing these, if you look in Prepare3D\SimObjects\Airplanes\mjc8q400\doc\ExtInterfaces\. In addition, in the XML folder is the tool you need to get the CRC value to call. The value passed in the SetQ400Value and GetQ400Value methods is the resulting CRC from the tool.

So for instance, if I want to set the domelight switch, I'd put in electricsData_->control.domelight_sw in the tool to get 68081 as the result, and as such I'd use that in the SetQ400Value method.

Hope this helps you out :)

[Track the origin of a called event?]

18 hours ago, Pete Dowson said:

No way I know of.  SimConnect allows me to intercept them, for logging, but there's no sender information at all. I agree, it would be very useful at times. I usually resort to a process of elimination, but for rare events that can take too long.

Pete

 

Ok, thank you so much for the answer. I'll keep on testing to see if I can figure out whether or not there's a hardware event that triggers it. It has happened to me on two different (Carenado) aircraft, and on two similar flight plans.

[Track the origin of a called event?]

Is it at all possible to track the origin of an event? Today, I was happily flying along in my Citation CJ2 (Carenado) when my engines cut out. I quickly scrambled to restart the engines, and got the plane flying again. After landing, I checked the FSUIPC log which was set to capture events, and I found these two lines as the engines shut down:

  4719188 *** EVENT: Cntrl= 66495 (0x000103bf), Param= 0 (0x00000000) TOGGLE_FUEL_VALVE_ENG2
  4719672 *** EVENT: Cntrl= 66494 (0x000103be), Param= 0 (0x00000000) TOGGLE_FUEL_VALVE_ENG1

Unfortunately, I was not logging button presses, so I am unable to track down if i have some faulty hardware trying to send the events. So this brought me to wonder if it is possible at all to find out the origin of that event, so I can track and possibly catch it? I'd rather not toggle my fuel valves :D

[Majestic Q400 V-speed calculator and setter]

23 hours ago, peter_h said:

Thanks again Henrik ;-)  Do you use any other scripts for the Q400?

I'm going to try to learn how to make my own and seeing examples is a big help.  I'm thinking about building a button/switch box that will act as the Q400 autopilot panel and hope to be able to write the scripts for this.

I mostly fly the Q400 with FS2Crew, so I tend to not use the scripts so often - though the vspeed one is definitely one I use repeatedly - too much twisting of knobs :P

[Majestic Q400 V-speed calculator and setter]

On 11/20/2017 at 11:42 PM, peter_h said:

Hi Henrik

I saw your Lua script to move the condition levers and have set it up for my Q400!  Thank you!

I've also linked this page in a related topic on this forum - http://majesticsoftware.com/forums/discussion/2625/using-fsuipc4-offsets-to-move-condition-levers#Item_12

I hope you don't mind!

Peter

Not at all, thank you :) The scripts are there to be used! If there's anything else you need, let me know and I'll take a look at it :)

[Majestic Q400 V-speed calculator and setter]

This is a 3 year and some necro of an old post, but first I would like to say thank you very much to Chris Warner for this script. Secondly, I did a few changes to make it work a little bit better.

Updated version (and other script as I make them) can be found here:

https://www.dropbox.com/sh/nof8k0k3m8juqzs/AAC5pulYtgMzdl5HyndcQhV4a?dl=0

 

/Henrik Bergvin