Lever precision

[Wyverex]

While going through clickabledata.lua files, I'm having a hard time figuring out how the LEV class type defines how many steps are available in game. There always seems to be an example that contradicts all the rules I come up with.

 

These are the basic rules as I understand:

class defines what type of element it is. If you have more than one, they seem to be related to left mouse button, right mouse button, mouse wheel in that order

arg_lim defines the values the element can switch between for that class, basically a min and max value

arg_value defines the step size that one activation advances. So for an arg_lim of {0, 1} and an arg_value of 0.1, you'd have 11 switch positions/detents

 

This seems to work well for TUMB and BTN classes.

 

For the LEV class there is also a gain value. My assumption so far is that it is multiplied into the arg_value. But that doesn't really hold up when looking at different examples. Let's take the A-10C:

 

PNT-LV-HSI-HDG, the heading select knob on the HSI has a very fine precision. If you use the mouse wheel you can turn it by a degree or so with each detent. When expanding the definition you get these values:

arg_lim = {0, 1}

arg_value = 1

gain = 0.1

 

From that example alone I can't infer in any way how many steps the element has. Multiplying gain with arg_value yields 10 which is obviously wrong.

 

PTR-TACAN-CHANNEL-SELECTOR-2

Three different classes, the mouse wheel responds to LEV and controls the last digit of the TACAN channel. This one has a fixed number of 10 steps.

arg_lim = {0, 1}

arg_value = 0.1

gain = 0.1

 

Assumption: The arg_value not being 0 or 1 defines an actual step count (and the gain is somehow ignored here)

 

But we immediately find a counterexample:

 

PTR-HARS-CP-PUSH-TO-SYNC

The LEV values:

arg_lim = {0, 1}

arg_value = 0.5

gain = 0.1

 

Although it has an arg_value of 0.5, you have very fine control, there are no discernible detents, it basically behaves like the heading knob.

 

PTR-SASP-YAW-TRIM

The Yaw trim rotary on the left console

arg_lim = {-1, 1}

arg_value = 0

gain = 0.1

 

An arg_value of 0. Doesn't make much sense to me. For this one I actually counted the steps in-game. I came up with 67. It doesn't have full 360 degrees range so I assume that the full range could have around 100 steps.

 

So at this point I'm pretty much at a loss how from looking at these definitions you can know how many detents a LEV class control has. I'm pretty sure this is not defined by the animation keyframes in the cockpit model either since those just define the physical/visual range of motion and not how they relate to input.

 

Does anyone know how this works?

 

There are some properties I don't quite understand yet but I don't think they are related to the precision but rather have a visual effect:

use_OBB, side, attach_left, attach_right

Edited December 28, 2020 by Wyverex

[LeCuvier]

ED seems to have no global programming rules for these objects. How the object properties are used varies from module to module.

I use "clickabledata.lua" mostly to glean information for commands that I want to add to "default.lua", but have to use trial and error.

In some cases, I have modified "Gain" values in "clickabledata.lua" because the original value was too "fast".

[epolta]

23 hours ago, LeCuvier said:

ED seems to have no global programming rules for these objects. How the object properties are used varies from module to module.

I use "clickabledata.lua" mostly to glean information for commands that I want to add to "default.lua", but have to use trial and error.

In some cases, I have modified "Gain" values in "clickabledata.lua" because the original value was too "fast".

LeCuvier,

 

this is highly interesting to me.. For example in the A-10C2 I have several Leo Bodnar rotary encoders for light brightness on the right console. I have to spin them for like 5 seconds to get them to increase all the way (and that's all I ever do is turn them all the way up - since I play in VR). So is there a way to make them "more sensitive" - in other words so I don't have to spin them as many times to get them to increase? That would be super helpful!!!

thanks as always! You have singlehandedly improved this game for my button boxes!

[LeCuvier]

I picked 5 light brightness adjustments from "clickabledata.lua":

elements["PTR-LGHTCP-ENG-INST"]            = default_axis(_("Engine Instruments Lights"), devices.LIGHT_SYSTEM, device_commands.Button_1, 290, nil, nil, nil, nil, nil, {70, -135},{90,-45})
elements["PTR-LGHTCP-FLIGHT-INST"]        = default_axis(_("Flight Instruments Lights"), devices.LIGHT_SYSTEM, device_commands.Button_2, 292, nil, nil, nil, nil, nil, {70, -135},{180,-45})
elements["PTR-LGHTCP-AUX-INST"]            = default_axis(_("Auxiliary Instruments Lights"), devices.LIGHT_SYSTEM, device_commands.Button_3, 293, nil, nil, nil, nil, nil, {70, -135},{140,-45})
elements["PTR-LGHTCP-FLOOD"]            = default_axis(_("Flood Light"), devices.LIGHT_SYSTEM, device_commands.Button_5, 296, nil, nil, nil, nil, nil, {70, -135},{180,-55})
elements["PTR-LGHTCP-CONSOLE"]            = default_axis(_("Console Light"), devices.LIGHT_SYSTEM, device_commands.Button_6, 297, nil, nil, nil, nil, nil, {70, -135},{180,-45})

They all use the function "default_axis" which is declared in the same file for the A-10C I and II:

function default_axis(hint_,device_,command_,arg_, default_, gain_,updatable_,relative_, cycled_,attach_left_,attach_right_)
    local relative = false
    if relative_ ~= nil then
        relative = relative_
    end
    local gain = gain_ or 0.1
    local cycled = cycled_ or false
    local default = default_ or 1
    return  {    
                class         = {class_type.LEV},
                hint          = hint_,
                device         = device_,
                action         = {command_},
                arg           = {arg_},
                arg_value     = {default},
                arg_lim       = {{0,1}},
                updatable     = {updatable_},
                use_OBB     = true,
                gain        = {gain},
                relative    = {relative},  
                cycle        = cycled,
                side        = {{BOX_SIDE_X_top, BOX_SIDE_X_bottom, BOX_SIDE_Z_top, BOX_SIDE_Z_bottom}},
                attach_left    = attach_left_ or nil,
                attach_right= attach_right_ or nil,
            }
end

As you see, the 6th parameter of the function is the "gain_"; and if none is supplied in the function call, it will use 0.1.

The 5 function calls send "nil" (the 2nd nil in the argument list) and therefore they all use 0.1 for gain. I replaced the second nil with the value 0.3, and that gave me a satisfactory response using a rotary encoder. Give it a try! You know of course that the file will be restored to the stock version if you run Update or Repair, so you need to have a backup, resp. use OvGME or JvGME to manage your modified files.

PS:
1. "clickabledata.lua" is in the folder "...\Mods\aircraft\A-10C_2\Cockpit\Scripts\"

2. some aircraft modules, e.g. the Harrier, have the function declarations in a separate file "clickable_defs.lua".

3. I'm lazy and use a macro that turns all 5 lights up with one button click.

Edited December 30, 2020 by LeCuvier

[epolta]

Awesome as always thanks! I'll definitely update my values and save with OVGME!

Brilliant!

 

[epolta]

Worked like a champ thanks for teaching me how to fish I was able to modify multiple other modules with the improvement!

[epolta]

@LeCuvier

They recently added light bindings for the JF-17 for Flood/Console/Inst/ in two places:

I've tried to tweak the third value like I did on the other modules, but it doesn't seem to have any effect. Perhaps there's something different about how these are coded?

-- Flood light direction
elements["PNT_965"] = default_axis_limited(_(cmd_names.PNT_965), devices.LIGHTS, click_cmds.PNT_965, 965, 0, 0.3, true, nil, {{0,1.0},{0,1.0}})
elements["PNT_966"] = default_axis_limited(_(cmd_names.PNT_966), devices.LIGHTS, click_cmds.PNT_966, 966, 0, 0.3, true, nil, {{0,1.0},{0,1.0}})
elements["PNT_967"] = default_axis_limited(_(cmd_names.PNT_967), devices.LIGHTS, click_cmds.PNT_967, 967, 0, 0.3, true, nil, {{0,1.0},{0,1.0}})
elements["PNT_968"] = default_axis_limited(_(cmd_names.PNT_968), devices.LIGHTS, click_cmds.PNT_968, 968, 0, 0.3, true, nil, {{0,1.0},{0,1.0}})

-- lights
-- INT
elements["PNT_944"] = default_axis_limited(_(cmd_names.PNT_944), devices.LIGHTS, click_cmds.PNT_944, 944, 0,  0.3, true, nil, {{0,1.0},{0,1.0}}) -- INST仪表照明旋钮
elements["PNT_945"] = default_axis_limited(_(cmd_names.PNT_945), devices.LIGHTS, click_cmds.PNT_945, 945, 0,  0.3, true, nil, {{0,1.0},{0,1.0}}) -- CONSOLE操纵台照明旋钮
elements["PNT_946"] = default_axis_limited(_(cmd_names.PNT_946), devices.LIGHTS, click_cmds.PNT_946, 946, 0,  0.3, true, nil, {{0,1.0},{0,1.0}}) -- FLOOD泛光灯旋钮

 

[LeCuvier]

@epolta:

I don't own the JF-17, so I can't investigate on my end. You should look at the fuction declaration for "default_axis_limited" to find out what parameter the "0.3" stand for. I would have guessed that it's "gain", but it might be something else.