"Button pressed" state

[kaha]

How can I achieve that a button, if I hold it down,, is immediately and continuously visible as pressed in the sim?

The BlackBird T-6A has a trim system that needs a button to be pressedcontinuously and in the tablet it can be adjusted how fast the trim will develop. I want this only for the buttons that are bound to the trims, so using "ButtonRepeat" probably is not appropriate.

 

Karl

[John Dowson]

1 hour ago, kaha said:

How can I achieve that a button, if I hold it down,, is immediately and continuously visible as pressed in the sim?

What has this got to do with FSUIPC? You can control how FSUIPC sees/reacts to button presses/holds/releases, but FSUIPC cannot do anything with what any other application, including the FS, receives/reacts to these button events. FSUIPC only sees and reacts to button press/releases, it does not send them on to other applications (that is windows' job!).

1 hour ago, kaha said:

The BlackBird T-6A has a trim system that needs a button to be pressedcontinuously and in the tablet it can be adjusted how fast the trim will develop. I want this only for the buttons that are bound to the trims, so using "ButtonRepeat" probably is not appropriate.

The ButtonRepeat ini parameter controls how FSUIPC reacts to a held button press, and specifies the time between the button press and the first repeat,  and the time for subsequent repeats, AS SEEN by FSUIPC. Changing this effects the button handling in FSUIPC only, not how other applications see/react to the button press.

Note that FSUIPC does have a 'hold' action on button presses:

Quote

<Action> is a single letter denoting the action being defined:

P	Pulse the key press or control: i.e. do not hold the keys down whilst the button is held down. This is always the case for controls, and should always be the case for any key presses involving ALT key usage, because once the FS Menu is entered FSUIPC cannot supply further changes like key releases.

H	Hold the specified keys down until the button is released. (This doesn’t apply to Controls and will be treated like P in their case). Do not use this with key presses involving ALT, for the reason just given.

R	Repeat the key press or control whilst the button is kept held down. The repeat rate is approximately 6 per second and is not adjustable. Do not use this with key presses involving ALT, for the reason already given

U     Pulse the key press or control when the button is released.

However, I am not exactly sure what this does - looks like it is used when assigning a button to send a key press and will then hold the assigned keypress until the button is released.
So if  that is what you are looking for, you could try that.

Normally you would just use repeat (R), i.e. the assigned control is continually sent while the button is held down, and set by checking the 'Control to repeat while held' checkbox in the assignments panel.

John

[kaha]

40 minutes ago, John Dowson said:

...

Normally you would just use repeat (R), i.e. the assigned control is continually sent while the button is held down, and set by checking the 'Control to repeat while held' checkbox in the assignments panel.

John

Yes, that's what I do.

Changing ButtonRepeat=20,10 to ButtonRepeat=0,0 does the job, trim speed then is as fast as if I bind a button to the same control (Elev Trim Up) in the sim., But this applies to all buttons. I would need this for the trim buttons and for the T-6A only.

Karl

[John Dowson]

Setting the ButtonRepeat ini parameter will apply to all buttons, as you say.

If you want to change for a single button, you could try using a lua script (using event.button) instead of a direct assignment.

But if this is for trim, doesn't the standard method of setting up trim work? i.e. rather than sending more/repeated inc/dec controls, set the elevator trim percent via offset 0BC0? You can also use different inc/dec deltas to have a fast and a slow increase/decrease. This is the standard method of assigning to replicate a trim wheel.
For example, these are the assignments I use on a rotary to control the trim (for most aircraft):

Quote

78=P174,10,Cx32000BC0,x3FFF0060     -{offset sword increment, offset 0BC0 (Incr=96, Limit=16383)}-
79=P174,8,Cx42000BC0,xC00100C0     -{offset sword decrement, offset 0BC0 (Decr=192, Limit=-16383)}-
80=U174,8,Cx42000BC0,xC00100C0     -{offset sword decrement, offset 0BC0 (Decr=192, Limit=-16383)}-
81=P174,11,Cx32000BC0,x3FFF00C0     -{offset sword increment, offset 0BC0 (Incr=192, Limit=16383)}-
82=U174,11,Cx32000BC0,x3FFF00C0     -{offset sword increment, offset 0BC0 (Incr=192, Limit=16383)}-
83=P174,9,Cx42000BC0,xC0010060     -{offset sword decrement, offset 0BC0 (Decr=96, Limit=-16383)}-

There are also some more advanced lua solutions in this FAQ entry: 

 

John

[kaha]

Unfortunately writing to 0BC0 does not work for the T-6A (as it doesn't for their new "Dirty Thirty" in MSFS2024). And reading from 0BC0 will not read the real trim but just what I wrote to it.

I will look into using a Lua script.

Thank you John!

[John Dowson]

6 minutes ago, kaha said:

And reading from 0BC0 will not read the real trim but just what I wrote to it.

That is interesting, as this means that what you wrote to the offset was actually applied, as the read values are populated from what is received from the FS, not what is written (there are separate memory addresses for read and write).. Strange this has no effect then. Do you see the (read) values change in that offset when you actually change the trim?

7 minutes ago, kaha said:

I will look into using a Lua script.

Ok, let me know how it goes or if you have any issues/further questions.

John

[John Dowson]

30 minutes ago, John Dowson said:

41 minutes ago, kaha said:

I will look into using a Lua script.

Ok, let me know how it goes or if you have any issues/further questions.

Thinking about this, it won't be that straight forward, as you need to repeat sending the control while the button is held down, and stop sending them when the button is released.
This can be tricky in lua. Off-hand, I can think of a couple of ways of doing this, but each may have issues and will need testing:

1. Use event.button and have the script auto-run (in the profile). The event.button handling function should loop forever sending the control.
    To stop the controls being sent, you need to assign the same button, but on release, to restart the lua script. This will then kill the existing script (and
    end the forever loop) and restart it ready for the next button press.
   The downside of this solution is that there may be a small delay after releasing before pressing will work again, as the script needs to be restarted (and recompiled first).
 

2. Again, have the script auto-ran (in the profile), but use event.flag instead, and assign the button press to LuaSet <luaScript> and the release to LuaClear <luaScript> (or maybe just both to LuaToggle), with the parameter for both being any flag number (0-255). In the event.flag handling function, you would either:
    - start an event.timer, which would call a handing function at regular intervals which sends the appropriate inc/dec control
    - cancel the existing timer using event.cancel.
   The downside of this solution maybe the speed/throughput, which will need testing.

Note also you could either use one script for both in/dec, or have separate scripts.

Let me know how it goes, I could maybe take a deeper look over the weekend (or next week) and see what works best, and provide you with a lua template script if needed.

John

[kaha]

16 hours ago, John Dowson said:

...Do you see the (read) values change in that offset when you actually change the trim?...

Reading back the offset I see what I wrote to it. Changing the trim using "Elev Trim Up/Down" does not change the content of 0BC0.

 

I'll let you know about the Lua script.

[John Dowson]

1 hour ago, kaha said:

I'll let you know about the Lua script.

Try the following:

local trimUpControl = 65615
local trimDownControl = 65607

function trimControl(flag)
  if flag == 0 then -- trim up
     while ipc.testFlag(0) do
	     ipc.control(trimUpControl)
     end
  elseif flag == 1 then -- trim down
     while ipc.testFlag(1) do
	     ipc.control(trimDownControl)
     end
  end
end

event.flag(0, "trimControl") -- trim up
event.flag(1, "trimControl") -- trim down
ipc.log("*** lua elevator Trim (repeat) script now running")

Have that script auto-ran via your profile [Auto.xxx] section, then assign your trim buttons to:

     trim Up: press to 'LuaSet <luaScriptName>' with parameter 0, release to 'LuaClear  <luaScriptName>' with parameter 0
     trim Down: press to 'LuaSet <luaScriptName>' with parameter 1, release to 'LuaClear  <luaScriptName>' with parameter 1

if its too fast, add an ipc.sleep(n) (where n is the number of ms to sleep, start with 10 and adjust as needed) after the ipc.control calls.

John

elevTrimRepeat.lua

[kaha]

Thank you John.

I have two versions of a Lua script now, the 2nd one is much smoother (obviously) and with it I can control the trim pretty nicely.

 

I will also take a look at yours.

Karl

Elevator_Trim.zip

[John Dowson]

18 minutes ago, kaha said:

I will also take a look at yours.

The script I provided will be a lot more efficient as there is no timer running and it just re-acts to the flag-change events.

Why are you testing/checking the aircraft name - are you running the script for all aircraft? Much better to just have the lua script auto-started in a profile for the aircraft that need it.

John

 

[John Dowson]

29 minutes ago, John Dowson said:

Why are you testing/checking the aircraft name - are you running the script for all aircraft? Much better to just have the lua script auto-started in a profile for the aircraft that need it.

Note also that all auto-ran lua scripts are killed and restarted when you go back to the main menu. If you are having the script auto-ran from the general [Auto] section (as opposed to a profile [Auto.xxx] section, you can just exit the script if  you don't want to use it with the loaded aircraft, as this would save resources.
I would not recommend changing aircraft without going back to the main menu (e.g. via devmode aircraft selector or other means) as this method is not fully supported by FSUIPC.

John

[kaha]

1 minute ago, John Dowson said:

Note also that all auto-ran lua scripts are killed and restarted when you go back to the main menu. If you are having the script auto-ran from the general [Auto] section (as opposed to a profile [Auto.xxx] section, you can just exit the script if  you don't want to use it with the loaded aircraft, as this would save resources.
I would not recommend changing aircraft without going back to the main menu (e.g. via devmode aircraft selector or other means) as this method is not fully supported by FSUIPC.

John

Yes. I'm not jumping back and forth between aircraft in one session. I always restart the sim when I change aircraft.

 

38 minutes ago, John Dowson said:

The script I provided will be a lot more efficient as there is no timer running and it just re-acts to the flag-change events.

Why are you testing/checking the aircraft name - are you running the script for all aircraft? Much better to just have the lua script auto-started in a profile for the aircraft that need it.

John

 

Thank you, I see. I will use it.

The only thing I'm thinking about is the following: If I press the trim button momentarily the script maybe sends the control just once. Not much will happen to the trim then. In fact the trim change will not be noticeable. I want to implement that the script sends the control continuously for at least 100 milliseconds (or some adjustable value), even if I let go of the button. With your example the script will end as soon as I release the button, though.

Karl

[John Dowson]

2 hours ago, kaha said:

I want to implement that the script sends the control continuously for at least 100 milliseconds (or some adjustable value), even if I let go of the button. With your example the script will end as soon as I release the button, though.

Use the ipc.elapsedtime function just before the loop starts (startTime) , and again after the control has been sent (nowTime). Then change the condition in the while loop to only exit the loop when the flag is not set or the difference between the two times is > 100 (i.e. ipc.testFlag(1) or nowTime - startTime < 100).

 

Edited 2 hours ago by John Dowson
corrected

[kaha]

1 hour ago, John Dowson said:

Use the ipc.elapsedtime function just before the loop starts (startTime) , and again after the control has been sent (nowTime). Then change the condition in the while loop to only exit the loop when the flag is set and the difference between the two times is > 100 (nowTime - startTime > 100).

 

So the button release:

release to 'LuaClear  <luaScriptName>' with parameter 0

doesn't immediately quit the script?

[John Dowson]

Just now, kaha said:

So the button release:

release to 'LuaClear  <luaScriptName>' with parameter 0

doesn't immediately quit the script?

Yes - and I corrected my previous post.

[kaha]

Ok, thank you.

[John Dowson]

Here's an updated script with that added:

local trimUpControl = 65615
local trimDownControl = 65607

function trimControl(flag)
  startTime = ipc.elapsedtime()
  nowTime = startTime
  if flag == 0 then -- trim up
    while ipc.testFlag(0) or nowTime - startTime < 100 do
        ipc.control(trimUpControl)
        nowTime = ipc.elapsedtime()
    end
  elseif flag == 1 then -- trim down 
    while ipc.testFlag(1) or nowTime - startTime < 100 do
        ipc.control(trimDownControl)
        nowTime = ipc.elapsedtime()
    end
  end
end

event.flag(0, "trimControl") -- trim up
event.flag(1, "trimControl") -- trim down
ipc.log("*** lua elevator Trim (repeat) script now running")

elevTrimRepeat.lua

[John Dowson]

Maybe better to send a fixed number of events on a short press rather than using the time, where the number of events could vary. To do this, use a counter instead of elapsed time: initialse the counter to zero before the loop, increment the counter in the loop and the loop condition should exit when the flag is cleared and the counter is above the minimum needed.