opentx 2.3 number jumping back to another value

[robschii]

for example you want to switch vtx channel....... number is jumping to the value before or you hold the plus/minus button for a long time

[hsuq510]

sames here, it seems the EVT_MINUS_BREAK is not properly handled. Any value changed with the minus button on a X9D+ (not 2019) has the effect when release the minus button the value returns the previous without any effect.

step to reproduce:
select a value, change it with minus , release minus button , see value change back to what is was at first

[robschii]

nothing happend till now

[RipperDrone]

referencing to OTX: opentx/opentx#6852 (comment)

[hsuq510]

betaflight event.lua has the following:

dial = {
    left = EVT_ROT_LEFT or EVT_UP_BREAK,
    right = EVT_ROT_RIGHT or EVT_DOWN_BREAK
}

removing the OR condition make script to work properly.

[RipperDrone]

maybe the Horus or Taranis 2019 wheel commands are mixed up with the old button commands the wrong way...?

[hsuq510]

can you please test if this in the events.lua fix the issue ?

dial = {
left = EVT_ROT_LEFT ,
right = EVT_ROT_RIGHT
}

[mikeller]

This code was added in #135 by @raphaelcoeffic. Maybe he has got an idea what needs to be done here?
As it is now with these scripts, we are supporting a number of different hardware types with different switches / toggles / wheels, so we need to thread carefully and do thorough testing to make sure we don't just shift the breakage to different hardware.

[RipperDrone]

Yes, it does (I first kept the wrong half of the expression, thinking the ROT_ identifiers were supposed to fit the Taranis 2019 with ROTation wheel... :-))

So dropping the EVT_UP_BREAK, EVT_DOWN_BREAK parts of the OR expression does the trick on my Taranis 2013 X9D+

[hsuq510]

Ok, good.

[RipperDrone]

Maybe the Taranis 2019 identifiers are pre-initialized to values which make the OR expression go wrong for a Taranis 2013?

[hsuq510]

well it seems like opentx 2.3 has wrongly EVT_DOWN_BREAK assigned to minus

[raphaelcoeffic]

As it is now with these scripts, we are supporting a number of different hardware types with different switches / toggles / wheels, so we need to thread carefully and do thorough testing to make sure we don't just shift the breakage to different hardware.

We have discussed this internally with the other opentx devs and it seems that some events have been broken for LUA since 2.3. We will need to look into it.

However, it should be time to think about moving to the new virtual events, which should normally bring compatibility with all radios with minimum effort.

[mikeller]

@raphaelcoeffic: You seem to be in the loop on OpenTX development, would you be able to propose a change to move to virtual events?

[raphaelcoeffic]

Yes, That’s the plan. I don’t have much hardware to test on, but I guess a lot of people are eager to test ;-)

[mikeller]

@raphaelcoeffic: Well, the hope would is that if we move to virtual events that are then mapped to hardware switches / wheels by OpenTX then the mapping to the different hardware types would have been done in OpenTX when they were added. 😉