LUA / LINDA very slow

[karlo922]

Hi,

 

I use a 128 button box and want to use my rotary knobs with FSUIPC. They send short joystick button presses for each direction a different button.

But as the are >32, I needed to use a LUA script and/or LINDA.

For LUA only, I just used the provided example - it somehow worked, but the refresh rate is very very low (~1 second). Even when setting poll rate = 100.

When I use LINDA it gets better, but it is still much to slow reacting. I stopped turning the knob (and no button presses anymore) but the heading bug was still increasing. It is also having around 1 sec delay. Also in the LOG I see this delayed actions.

Any advice?

 

Best regards,

karlo

[Pete Dowson]

1 minute ago, karlo922 said:

I stopped turning the knob (and no button presses anymore) but the heading bug was still increasing. It is also having around 1 sec delay. Also in the LOG I see this delayed actions.

These operate by sending controls to the simulator, and it appears they are being queued.  So, it your system quite heavily loaded? Queuing of actions in an aircraft is most usually to do with the aircraft itself and its displays. Try with a simple default aircraft to make sure it isn't that.

Note that when FSUIPC logs those controls (INC and DEC I assume?) that is when SimConnect reports back to FSUIPC that the control is being implemented -- it isn't the time when FSUIPC actually sends it.  There are some different log entries which can be enabled which shows the button press detection.

 I've never known any button press to take any noticeable time to be activated, let alone a whole second! The rotary is merely acting like a button. Try checking with a simple button instead of a rotary. Is there still a one second delay?

BTW with rotaries there's alternatively a "press" and "release" action on each click. So, you should program both press and release to the same INC / DEC operation for a change on every click.

Pete

 

[karlo922]

Hi, I just tried again with Classic Cessna 172 SP on a green grass stripe - same behaviour. 

And yes, there is still a delay when using a "normal" button, but you cannot feel it same as you cannot act is as fast. 

Concerning press/release - I'm not using a standard MMJoy or similar fiwmare, so I took care about the button presses in my own arduino firmware already. A "on press" event should be enough. But I cannot get rid of this huge dealy and as you correctly say "queing" of inputs....

[Pete Dowson]

16 minutes ago, karlo922 said:

Hi, I just tried again with Classic Cessna 172 SP on a green grass stripe - same behaviour. 

And yes, there is still a delay when using a "normal" button, but you cannot feel it same as you cannot act is as fast. 

Concerning press/release - I'm not using a standard MMJoy or similar fiwmare, so I took care about the button presses in my own arduino firmware already. A "on press" event should be enough. But I cannot get rid of this huge dealy and as you correctly say "queing" of inputs....

In the past I've written drivers for a lot of different hardware using dials and displays -- radios and autopilot/MCP controls . Some software delay and the resulting queuing action has always been present with all flight simulators since FS98 (when I started writing the drivers for FlightLink hardware). Maybe not as bad as with MSFS, but:

The way i dealt with it was to maintain the local display with the correct value as the knobs, displaying the value being read from the Sim when there was a gap in the button input arrivals -- more than, say, 500 or 750 mSecs. That always worked well, no matter what the sim or aircraft. The timing needs experimenting with to get just right.

But if you aren't maintaining a local display, and consequently are dependent on seeing the changing value in a gauge on-screen, then this isn't a solution for you.

Pete

 

[karlo922]

Hi Pete,

yes - unfortunately I do not have any displays. I'm testing around a little bit now with my encoder implementation and see if it can get better.

I will come back when I've tried it 🙂

[karlo922]

Hi, I re-designed the code for my rotary and it is working perfectly (using a joystick test tool to see what happens).

But this huge delay and queing still occurs. Maybe its a SimConnect bug with MSFS? I don't know. 

[karlo922]

I'm now using a different tool instead of LINDA/FSUIPC - this works fine. I do not know why it's not correctly working with LINDA/FSUIPC.

[John Dowson]

On 12/29/2020 at 5:06 PM, karlo922 said:

Even when setting poll rate = 100.

The default is 10 (i.e. every 10ms). So by setting this to 100, you are actually slowing things down.
It was probably the ButtonRepeat rate you wanted to adjust.

17 minutes ago, karlo922 said:

I do not know why it's not correctly working with LINDA/FSUIPC.

Me neither. If you took Linda out of the equation, then we could look into it, but if using Linda then you really need their support.
But as long as your happy with this 'different tool' (a name would be helpful for other users!), I will consider this closed.

John

[karlo922]

Hi, unfortunately I cannot use FSUPIC alone as I have those 128 buttons.
But also when I did re-arrange them so I could just use it with Buttons 1/2 and so without LINDA, I had the same lag. If you like we could have a look at this 🙂

The new tool is to be found here: https://github.com/Elephant42/FS_Tool

and the thread here: https://forums.flightsimulator.com/t/joystick-to-simconnect-mapping-utility-honeycomb-bravo-throttle-mappings-included/346493

[John Dowson]

1 hour ago, karlo922 said:

unfortunately I cannot use FSUPIC alone as I have those 128 buttons.

But this is easily handled by adding an additional lua. For example, see the lua scrips in the last comment in this post (derived from HidDemo.lua), that provide access to the buttons in the new Honeycomb devices that are > 32: 

 

However, if you are happy with your solution, then go ahead with that. I just want to emphasize that your issue was not caused by FSUIPC.
There are also various solutions around the 32 button limit, from lua files to using the vJoyOffsets utility, or this utility (written for StreamDeck, to provide virtual button functionality for that device, but I'm sure easily adapted): 

I have not heard of any "slow response" reports when using any of these.

John

 

[karlo922]

Sure - There must be something wrong at my setup -  but I do not know where to search for. As even without any lua and only FSUIPC i get this lag. Its a rather fresh install and clean setup... But currently I'm fine with the other tool. It's way more uncomfortable, but for now it works for my needs. Maybe we try again to solve it at a later stage if I neeed FSUIPC for things which are not possible with it. I will then come back to you. 🙂 Thank you for your help!

Regarding the 32 button limit - will this be solved when you go for xInput ?(I saw this on you "ToDo" List for future updates to cover Xbox One controllers)

 

[John Dowson]

55 minutes ago, karlo922 said:

Regarding the 32 button limit - will this be solved when you go for xInput ?(I saw this on you "ToDo" List for future updates to cover Xbox One controllers)

No, as that will be for xbox one and 360 controllers ONLY, as they do not support DirectInput (very well...).
DirectInput can support up to 128 buttons anyway, and I will also look into supporting more buttons (at least to 64, hopefully to 128)  via UI assignments at some point for DirectInput devices. Unfortunately, I am spending at least 80% of my time at the moment covering support, which leaves me hardly any time for fixing bugs, let alone adding/improving current functionality. Hopefully this will change at some point.....

John