Gladiator NXT Programming questions

[ivanobulo]

Hi,

Couple of days ago I've finally received my Gladiator NXT and very happy with almost everything. It is super precise, great ergonomics and quality! Before that I had CH Fighterstick and I didn't like the mechanical part and lack of buttons. But the ability to program it was amazing.

With NXT I'm still trying to wrap my head around the software and am having certain issues with En1 and En2 wheels on the controller. They are mapped as encoders and what I wanted to do is to bind flaps to "En1" in IL-2 sturmovik. Idea is simple: while the wheel spinning one direction key/button should remain pressed. Spinning in other direction - other button remain pressed. Button is "released" only after let's say 200ms w/o an event from the wheel.

Unfortunately it seem like this is not possible to do with existing software. It only allows to generate short key strokes controlled by T_Enc global value. Which causes flaps extend extremely slowly... I tried using Generator but it doesn't work well for this. Also because I wanted to use the same wheel as a trimmer with SHIFT the Generator wouldn't work anyway.

Would it be possible to add a new type of encoder to simulate this scenario?

[fallout9]

Flaps are realistic in game, so really slow; can't be tricked by software I mean you could definitely make the flaps go 20% with a press of a button (instead of 20 presses), but you can't halve the time.

[ivanobulo]

This is just an example. It is not about making it faster. It is about making it open as fast as possible in the game. Wheel En2, in general, is good for opening closing oil/water radiator for instance. In game they open quickly. With encoder mapped buttons it takes a long time to do it.

[hon0]

Probably because IL2 button to axis have a slight delay before the axis start incrementing/decrementing. So if you use an encoder you have to wait for the delay at each pulse of the encoder. Its best to hold a button. Or to set the encoder to keep holding a button as long you as keep turning it within a set delay. I do not know if that is feasible. Maybe simply by increasing the encoder pulse time, and then move the encoder faster than that time?