Jump to content

Recommended Posts

Posted

I have a weird issue ongoing.

 

I use the pinky trigger on the TH Warthog stick as a shift key for various functions such as NVG etc. I've bound the mic switch on the throttle with the pinky shift to change VHF AM 100 MHz and 10 MHz up and down. The cockpit frequency display switches correctly but I can't contact tower etc. unless I mouse click up and down on the freq keys in-cockpit, even though it just switches away and back from the frequency set by the HOTAS.

 

Any ideas? I'm using Helios for my touchscreen (which has the known VHF issues, but I don't think this is a factor as I'm not using Helios to change frequency).

Posted

It appears as though all keybinds associated with both VHF radios are simply broken. I'm unsure if this is as true of the UHF radio.

  • Like 1

Warning: Nothing I say is automatically correct, even if I think it is.

Posted
It appears as though all keybinds associated with both VHF radios are simply broken. I'm unsure if this is as true of the UHF radio.

I can confirm this. I noticed same when mapping rotary encoders via a joystick controller. Checking was done when TARS was running. When switching up one (1) MHz from 124 MHz the indication by TARS is only 124.900 MHz. If switching up one (1) more MHz then indication by TARS is 125.900 MHz. Same anomily followed going down.

Same test done using mouse click in 3D cockpit reveals correct frequency.

 

I solve the rotary encoders by applying mapping straight into the joystick.lua file e.g.:

{combos = {{key = "JOY_BTN10"}}, down = 3011, up = 3011, cockpit_device_id = 55, value_down = 0.1, value_up = 0, name = "VHF AM 1Mhz Selector Increase", category = "VHF AM Radio Control Panel"},

{combos = {{key = "JOY_BTN9"}}, down = 3011, up = 3011, cockpit_device_id = 55, value_down = -0.1, value_up = 0, name = "VHF AM 1Mhz Selector Increase", category = "VHF AM Radio Control Panel"},

 

This may be possible with keyboard commands also.

 

p.s. UHF I found to be fworking correctly without any change to the joystick.lua file

 

Cheers

Hans

Posted

P*Funk, if you want I have gotten a complete list of the direct inputs I am using here: http://forums.eagle.ru/showpost.php?p=1996518&postcount=42

 

All you need to do is copy the lines needed unto your joystick.lua files and type in the new button number that matches your input. If inputs are done by keyboard then insert as follows:

 

e.g.

{key = 'Num0', reformers = {'RAlt'}}

 

instead of e.g.

 

{key = "JOY_BTN10"}

 

Cheers

Hans

Posted (edited)

So, my preliminary tests show that this works. I'm able to change VHF AM Freqs using your borrowed entries and in game AI respond while TARS is showing the correct frequencies.

 

However this has created a strange by-product:

 

2002tl2.png

 

As you can see, all of my entries for the related radio are doubled. Is this expected or is it a product of my messy methodology?

 

All I did was paste over the existing entries in my keyboard.lua for the related controls. This is what appears in my keyboard.lua now:

 

{combos = {{key = "R", reformers = {"LShift"}}}, down = 3015, up = 3015, cockpit_device_id = 55, value_down = -0.25, value_up = 0, name = "VHF AM 0.025Mhz Selector Increase", category = "VHF AM Radio Control Panel"},

{combos = {{key = "R"}}, down = 3015, up = 3015, cockpit_device_id = 55, value_down = 0.25, value_up = 0, name = "VHF AM 0.025Mhz Selector Increase", category = "VHF AM Radio Control Panel"},

{combos = {{key = "E", reformers = {"LShift"}}}, down = 3013, up = 3013, cockpit_device_id = 55, value_down = -0.1, value_up = 0, name = "VHF AM 0.1Mhz Selector Increase", category = "VHF AM Radio Control Panel"},

{combos = {{key = "E"}}, down = 3013, up = 3013, cockpit_device_id = 55, value_down = 0.1, value_up = 0, name = "VHF AM 0.1Mhz Selector Increase", category = "VHF AM Radio Control Panel"},

{combos = {{key = "Q", reformers = {"LShift"}}}, down = 3009, up = 3009, cockpit_device_id = 55, value_down = -0.1, value_up = 0, name = "VHF AM 10Mhz Selector Decrease", category = "VHF AM Radio Control Panel"},

{combos = {{key = "Q"}}, down = 3009, up = 3009, cockpit_device_id = 55, value_down = 0.1, value_up = 0, name = "VHF AM 10Mhz Selector Increase", category = "VHF AM Radio Control Panel"},

{combos = {{key = "W", reformers = {"LShift"}}}, down = 3011, up = 3011, cockpit_device_id = 55, value_down = -0.1, value_up = 0, name = "VHF AM 1Mhz Selector Increase", category = "VHF AM Radio Control Panel"},

{combos = {{key = "W"}}, down = 3011, up = 3011, cockpit_device_id = 55, value_down = 0.1, value_up = 0, name = "VHF AM 1Mhz Selector Increase", category = "VHF AM Radio Control Panel"},

--[[{pressed = iCommandPlane_VHF_AM_025MHz_Dec, name = "VHF AM 0.025Mhz Selector Decrease", category = "VHF AM Radio Control Panel"},

{pressed = iCommandPlane_VHF_AM_025MHz_Inc, name = "VHF AM 0.025Mhz Selector Increase", category = "VHF AM Radio Control Panel"},

{pressed = iCommandPlane_VHF_AM_01MHz_Dec, name = "VHF AM 0.1Mhz Selector Decrease", category = "VHF AM Radio Control Panel"},

{pressed = iCommandPlane_VHF_AM_01MHz_Inc, name = "VHF AM 0.1Mhz Selector Increase", category = "VHF AM Radio Control Panel"},

{pressed = iCommandPlane_VHF_AM_10MHz_Dec, name = "VHF AM 10Mhz Selector Decrease", category = "VHF AM Radio Control Panel"},

{pressed = iCommandPlane_VHF_AM_10MHz_Inc, name = "VHF AM 10Mhz Selector Increase", category = "VHF AM Radio Control Panel"},

{pressed = iCommandPlane_VHF_AM_1MHz_Dec, name = "VHF AM 1Mhz Selector Decrease", category = "VHF AM Radio Control Panel"},

{pressed = iCommandPlane_VHF_AM_1MHz_Inc, name = "VHF AM 1Mhz Selector Increase", category = "VHF AM Radio Control Panel"},,]]--

 

Anything I should be doing differently? Would it be better if I had unbound my previous keys for the altered controls before making the lua changes?

Edited by P*Funk

Warning: Nothing I say is automatically correct, even if I think it is.

Posted
Yeap I have the same. Didn't realise it as I never looked at it. I have deleted unsed but I still have double fields..

 

Cheers

Hans

 

Delete them from the Saved Games/DCS/Config/Input/A10C/Joystick/yourfile.lua and it should get rid of the extra entries.

  • Like 1



Win 10 64 Pro, MSI Z390 I7-9700K @5ghz Kraken Z63, 32Gb Corsair Dominator, MSI RTX-2070, 1TB NVME 2TB SSD's, TM Warthog, Pro Rudders, OpenTrack w/ IR Clip

Posted

If I wanted to try to use this solution elsewhere in my config for other controls in the future, how do I determine what the entries should be?

Warning: Nothing I say is automatically correct, even if I think it is.

Posted (edited)
As long as you have the "old" VHF entries in any other LUA file (keyboard or joystick) you will see double entries. The only solution is to make a batch conversion to all of your LUA files, or delete some of the joystick.lua files (which will force DCS to do it automatically).

 

 

Thanks Home Fries. I will try that.

 

P*Funk take a look at these threads:

http://forums.eagle.ru/showpost.php?p=1428587&postcount=6

http://forums.eagle.ru/showpost.php?p=1626473&postcount=15

http://forums.eagle.ru/showpost.php?p=1665116&postcount=16

 

Its for the KA-50 but it works the same way for A-10C. There was another link which summed it altogether but I can't seem to find. Sorry.

 

Cheers

Hans

Edited by Hansolo
Posted

Thanks for the help, I'll give that stuff a look.

 

Just to clue you in, what I'm curious about is if this methodology could be used to overcome some of the default keybinding limitations with the A-10C. A good example is how the canopy switch works. In the clickable cockpit you hold the switch down to close but releasing before it seals leaves the canopy as it is when you released the switch. The controls menu entry for the canopy switch however is a simple Open/Close toggle that has none of the characteristics of the real switch. I wonder if this method could make it work as it ought to for a keybind.

 

So far looking at the clickabledata.lua entry has left me with something not addressed in any of your linked posts.

 

elements["PTR-CANOPY-OPEN"] = {class = {class_type.TUMB ,class_type.BTN},

hint = _("Canopy Open/Hold/Close") ,

device = devices.CPT_MECH,

arg = {712 ,712},

arg_value = {1.0 ,0},

arg_lim = {{0.5, 1.0} ,{0,0.5}},

 

action = {device_commands.Button_6,device_commands.Button_7},

stop_action = {0 ,device_commands.Button_7},

stop_value = {nil ,0.5},

use_release_message = {false ,true}}

 

In the examples in your links the relevant controls used only one device_commands.Button, not 2, so I'm uncertain how to interpret this.

 

It seems to me that already I should be able to use 0, 0.5, and 1.0 as the appropriate values, but I am otherwise unsure where to go from here.

 

I wish I could help myself more here, but I'm far more competent replicating a defined process than hashing a new one out on my own, sadly. :no_sad: :dunno:

Warning: Nothing I say is automatically correct, even if I think it is.

Posted

Hi P*Funk,

 

Did at test and this should work:

 

Find your keyboard.lua file and delete following:

{combos = {{key = 'C', reformers = {'LCtrl'}}}, down = iCommandPlaneFonar, name = 'Canopy Open/Close', category = 'Systems'},

 

 

Then copy this instead into the keyboard.lua:

{combos = {{key = "JOY_BTN19"}}, down = 3006, up = 3006, cockpit_device_id = 39, value_down = 0, value_up = 0.5, name = "Canopy Open/Close", category = "Systems"},

{combos = {{key = "JOY_BTN20"}}, down = 3006, up = 3006, cockpit_device_id = 39, value_down = 1, value_up = 0.5, name = "Canopy Open/Close", category = "Systems"},

 

You can always map it differently, but here it is mapped for RCtrl + C and LCtrl + C. It is important to remove the original line. Otherwise is superseeds the two added lines.

 

p.s. I didn't use command_button_7 at all.

 

Happy hunting

 

Cheers

Hans

  • Like 1
Posted (edited)

Thanks, I'll give that a try tonight. :)

 

EDIT. The test was successful. Observing the behavior of the Canopy Open switch now however sees it function the same as the Canopy close switch, ie. it only functions so long as you hold the key depressed, meanwhile merely clicking and releasing the corresponding switch in the cockpit causes the switch to automatically remain depressed until the Canopy is fully open. I wonder if this new behavior is actually more realistic than the original one... hmm. Could this Button 7 thing perhaps have something to do with it?

 

In any case thanks alot. This has been exciting to explore. I'll post more if I get in trouble again.

Edited by P*Funk

Warning: Nothing I say is automatically correct, even if I think it is.

Posted

Behavour might be due to the fact that the real switch shouls actually be an (on)-off-on switch where (on) is momentarily.

 

Cheers

Hans

 

I'll try to remember to ask the A-10 maintainer that I know about that.

 

In any case, regardless of which is meant to be the correct real-world behavior, for me understanding how to manipulate the LUA to achieve both would be valuable for the future as I tweak my current set up and one day, hopefully, construct some kind of home pit.

 

Thanks again for your help.

Warning: Nothing I say is automatically correct, even if I think it is.

  • 2 weeks later...
Posted (edited)

So apparently the canopy open switch is meant to lock when you flip it up until the canopy fully opens at which point it returns to neutral. I presume this is what that Button_07 thing is meant for.

 

I'm gonna toy with this.

 

EDIT. Well that was pretty easy to fix.

 

{combos = {{key = "Num+"}}, down = 3006, up = 3006, cockpit_device_id = 39, value_down = 0, value_up = 0.5, name = "Canopy Open/Close", category = "Systems"},

{combos = {{key = "Num-"}}, down = 3006, up = 3006, cockpit_device_id = 39, value_down = 1, value_up = nil, name = "Canopy Open/Close", category = "Systems"},

 

All I had to do was replace the value_up from 0.5 to nil. Works exactly the same as clicking it does now. Didn't even have to use Button_07. This is I assume because of this behavior being built into the clickabledata.lua. It uses the nil command there in the stop_value, and it also has this line:

 

use_release_message = {false ,true}}

 

The false appears to line up with the column that defines behavior that corresponds to the canopy open action. No idea if this is at all related or if it just inspired me to figure out the solution.

Edited by P*Funk

Warning: Nothing I say is automatically correct, even if I think it is.

Posted
Due to the function can it then be assumed that the canopy toggle switch is actually a magnetic held switch like anti-skid, SAS and anti-collision light?

 

The way it was described to me was that when you push the switch up its physically locked until the canopy reaches full extension. You can override this in real life by pulling the switch out and returning it to neutral.

 

I don't remember if this was supposed to be magnetic or if its a mechanical uplock that is released physically by whatever signal indicates to the system that the canopy is fully up. I doubt that the other switches that use magnetic holding would require you to pull the switch out so if I had to guess I'd say this one is mechanical.

 

I could always ask again. :D

Warning: Nothing I say is automatically correct, even if I think it is.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...