Jump to content

Keybinds for using ON/OF type commands are faulty and the resulting action does not match the key used, or listed in Commands list.


WillyPete
 Share

Recommended Posts

Example:

Commands list shows "LCTRL+LSHIFT+1" for "Battery 1 ON/OFF".  

However "LCTRL+LSHIFT+2" is the working key for "Battery 1 ON/OFF" even though that keybind is assigned to "Battery 2 ON/OFF"

 

Findings: 

In the commands list, setting "LCTRL+LSHIFT+1" to the  "Battery 1 ON" command allows the use of "LCTRL+LSHIFT+1" properly.   

 

In default.lua for keyboard input: 

"Battery 1 ON"  has the entry of "device_commands.Button_3"  

"Battery 1 ON/OFF"  has the entry of "device_commands.Button_111"    

 

 

All keybinds that use a 3 numeral identifier in the "device_commands.Button_XXX" entry in the default.lua used for input in the Mi-8 mod are faulty.  


Edited by WillyPete
  • Like 1
Link to comment
Share on other sites

37 minutes ago, Flappie said:

These issues have already been reported.

 

Thank you.  

I've tried searching for a solution or to see if it had been reported, but no luck with the search utility.  

As the post you linked is in French it did not flag for me.

Link to comment
Share on other sites

It's become obvious to me that there is a version control error for either Input>Keyboard>default.lua or Cockpit>Scripts>clickabledata.lua in the module files.  

 

To start with, I tried to find a command in the autostart macro that was not working.   

In autostart, the pilot's window does not close.

 

Macro_sequences.lua is the autostart macro for the Mi-8.  

During the startup, the macro calls to close the pilot's seat "Blister" or window.  

The command calls  

push_start_command(1.0,{device = devices.CPT_MECH, action =  device_commands.Button_15, value = 1.0})

 

clickabledata.lua uses the same Button variable when it specifies the type of action to be used:  

elements["PTR-BLISTER-LOCK-L"]	= default_2_position_tumb(_("Left Blister, OPEN/CLOSE"),devices.CPT_MECH, device_commands.Button_15, 215)

 

The default keybind does work for the pilot window.  

These are found in default.lua.  

default.lua has the following variable for the Blister (window):  

{combos = {{key = 'C', reformers = {'LCtrl'}}},				down = device_commands.Button_18,  value_down = 1,	cockpit_device_id = devices.CPT_MECH,	name = _('Open/Close Left Blister'),			category = _('Systems')},

 

 

The first two refer to device_commands_Button_15 while default.lua uses _18  

It's clear that many of the default keybinds, are not calling the correct commands and are mismatched between the different lua's that reference them.

Link to comment
Share on other sites

Thanks Flappie.  

 

This is new ground for me.  

Are there any approved guides that I can read to give me greater insight as to how the dependencies work between the lua files?    

 

For instance, am I right in thinking that macro_sequences.lua is actually looking up clickabledata.lua when it makes a call to "device_commands.Button_15" or is it referencing a different lua ort even a dll?  

Just to save me barking up the wrong tree and spouting inaccurate claims in trying to resolve my issues.

Link to comment
Share on other sites

Further to my last posts on locating the error.  

 

All faulty keybinds are restricted to the devices defined by three determining factors:  

They all belong to the device class: cockpit_device_id = devices.ELEC_INTERFACE,  

They all have a 3 digit identifier as seen in default.lua :    device_commands.Button_120  

They are all multi-action commands (ON/OFF, rheostat axis, CCW/CW, Cover OPEN/CLOSE)

 

The identifier matches that found in the hash that is visible when you export the keyboard bindings to HTML. (export is of a default bind list)  

Example: 

d3120pnilunilcd1vd1vpnilvunil  assigned to the action AC Ground Power Switch - ON/OFF

 

Using that example, if we increment the device ID number in the hash identifier by 1, we get d3121pnilunilcd1vd-1vpnilvunil which is the hash for 115V Inverter Switch - Down action.   

Using the default keyboard binding for AC Ground Power Switch - ON/OFF which is LALT+LSHIFT+` then we notice the 115V Inverter Switch being activated instead.

 

The finding is thus that the default keybind is activating the interface listed by the hash incremented by 1 for some of the faulty keys.   

 

The first bound key to suffer from this is the binding:  

RCtrl - 0    Battery Heating Switch - ON/OFF    Right Side Panel    d3107pnilunilcd1vd1vpnilvunil  

 

106 is the first listed hash, but there is no device bound to it. 

Binding a key to it offers correct function as the d3106 hash is for the separate On or Off actions, and not the ON/OFF action for d3107.  

 

106 and 107 are also unique in the default.lua in that they are the only commands with "cb_start_cmd +" instead of "device_commands.Button_"

Additional findings were that while the keybinds were affecting hash+1, they were also affecting the TYPE of action for the interface as defined in clickabledata.lua   

The sequence of +1 is also not maintained strictly, indicating it is not merely an issue of decrementing some values to correct it.  

 

Example:  
LALT+LSHIFT+9, LALT+LSHIFT+0, LALT+LSHIFT+-, LALT+LSHIFT+= are for the Gen 1 Voltage Rheostats CCW, CW and Gen 2 Voltage Rheostat CCW, CW respectively.  
LALT+LSHIFT+9 (assigned hash d3124) instead activates the AC Voltage selector (hash d3123 device), but also causes it to turn like a rheostat (device_axis_limited in clickabledata.lua) instead of a clicking Position Switch (multiposition_switch in clickabledata.lua)

 

The same happens for the DC Voltage selector (hash d3116) when you use the commands for the DC Rheostat (hash 117; LCTRL+LSHIFT+ -or=)

 

This indicates that the command sent to the sim is activating the next or previous device according to hash number, but driving the action as per the correct hash identifier.  

What appears to be an anomaly is that the Multiposition_switch type action is not present.   

I suspect that the two multiposition switches (DC and AC Selector) in the devices.ELEC_INTERFACE are missing from where the sim looks up the desired action called by the keybind, and the other actions have "filled the gaps".    

Keybinds are calling the wrong action, but they are dragging their correct device behaviour with them.  

If the action they are calling can't perform the device behaviour, the action simply fails.  

 

This would also explain why keybinds for inputs assigned to hashes d3106-108 do not cause any action, and the same for hash d3126, and why the keys activate the hashes+1 before the DC selector, and hash-1 after the AC selector.

 

Keys bound to single actions in the command list work as intended, *except* for the CCW/CW actions on multi_selector devices.  Before and after these, multi action commands (ON/OFF) all fail.  

 

Sorry this is so round-about and not a short comment, but I'm hitting this blind and having to make assumptions about dependencies and references in the ED file structure.  

I don't know what role the hashes or device ID numbers play in this structure.  

Basically it's a "I think we should look here, and this is why." type of post.  

 

Good luck.

 

Link to comment
Share on other sites

 Share

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...