Jump to content

Recommended Posts

Posted

Hello.


I've just bought it but as i am away i can't check the controls.
With BS2 i had to create external hotas profiles (x56, bands) to
be able to use the knobs for altering: brightness and contrast.
Can you tell me if BS3 let you to assign them ?


Thank you.

Democracy was already invented, while Scrat was eating oak fruits.

Posted

The axes shown in the box below aren't available in BS3 out of the box, sadly. You need to put them in Lua files yourself (and then apply "user curve" 50, 55, 60, ..., 95, 100 on each).

axisCommands = {
-- scoobie begin:
-- taken from https://forums.eagle.ru/showthread.php?t=258812&page=2
{action = 3001, cockpit_device_id = 7, filter = {saturationX = 1, saturationY = 0.5, deadzone = 0, invert = true, slider = true, curvature = {0}}, name = _('HUD Brightness Knob')},
{action = 3002, cockpit_device_id = 8, name = _('IT-23 TV Brightness Axis')},
{action = 3003, cockpit_device_id = 8, name = _('IT-23 TV Contrast Axis')},
{action = 3008, cockpit_device_id = 9, name = _('ABRIS Brightness Axis')},
{action = 3001, cockpit_device_id = 23, name = _('Helmet device Brightness Axis')},
{action = 3006, cockpit_device_id = 46, name = _('ADF Volume Axis')},
{action = 3002, cockpit_device_id = 49, name = _('R-828 (VHF-1) Radio Volume Axis')},
-- my own:
{action = 3006, cockpit_device_id = 51, name = _('Lighting auxiliary panel brightness knob')},
{action = 3008, cockpit_device_id = 51, name = _('Lighting night vision cockpit brightness knob')},
{action = 3002, cockpit_device_id = 51, name = _('Lighting cockpit panel brightness knob')},
{action = 3004, cockpit_device_id = 51, name = _('Lighting HSI and ADI brightness knob')},
-- scoobie end.

 

  • Thanks 1

i7-8700K 32GB 3060Ti 27"@1080p TM Hawg HOTAS TPR TIR5 SD-XL 2xSD+ HC Bravo button/pot box

Posted (edited)

Agree and I've got a joke, too... This is because the cockpits are CLICKABLE.

The trick is that not only CAN you click them, you also HAVE to click them 😉
Haa haa... absolutely hillarious.

Now, seriously speaking, lots of people have basic HOTAS set. May be of stellar quality, but basic - stick and throttle and that's it (well, that's why it's called HOTAS). So people do use mice, for the lack of other equpiment.
I don't like using a mouse. Low or average quality potentiometers aren't expensive, jellybean electronics, Leo Bodnar's boards probably aren't too expensive, either. You may also buy one of those "control panels" with knobs and stuff from Virpil or other people, no problem.
So, really... I don't see why you HAVE to abuse the mouse to deal with knobs in an simulated aircraft in 2023 ("have to" is different from "choose to"), when at the same time people buy joysticks for hundreds of bucks. Turning hardware knobs just works and feels great (I've got 7 of them), whereas doing it with a mouse is like... OK, no poetic parallels, it's just worse, WAY worse.

Sadly, there's an unfortunate coincidence which may make some of one's own binding result in various "artifacts" when you turn a particular axis to absolute minimum.
This is because most axes in 3D models go (move) from value 0 to 1, not from -1 to 1 (which control bindings window assumes).
When you create your own binding (in the way depicted in the post above), you need to "Axis Tune", click "slider" and "user curve" and the curve goes 50..100 in increments of 5. So far so good. Unfortunately, the Axis Tune window does a trick - even if you start with the value of 50, the axis starts with the minimum value (like 0%, but technically it's -1). There is no real reason for it, but it does that. I don't know if you can do anything to rectify it. SO... when you turn your axis to minimum, it goes to minimum... which is -1 for the cockpit control (knob, rheostat, whatever), which means the cockpit control is set to a value to which it wasn't designed to be set to at all. And sometimes you get unexpected results. For example - the gunsight in the Hind (screenshot attached).
It's not very nice 😞

hind.PNG

axis_tune.png

Edited by scoobie

i7-8700K 32GB 3060Ti 27"@1080p TM Hawg HOTAS TPR TIR5 SD-XL 2xSD+ HC Bravo button/pot box

Posted

If you argue like this, you dont need any Keybinds. Why i have an F-18 Take-Off Panel? I mean it is just a couple of lines to put into a lua file. Is it so hard for devs in Ver3 on top?

I cant do it, im to stupid....so i decided to pay money and let do the job pros.

Am 17.12.2022 um 18:24 schrieb scoobie:

The axes shown in the box below aren't available in BS3 out of the box, sadly. You need to put them in Lua files yourself (and then apply "user curve" 50, 55, 60, ..., 95, 100 on each).

axisCommands = {
-- scoobie begin:
-- taken from https://forums.eagle.ru/showthread.php?t=258812&page=2
{action = 3001, cockpit_device_id = 7, filter = {saturationX = 1, saturationY = 0.5, deadzone = 0, invert = true, slider = true, curvature = {0}}, name = _('HUD Brightness Knob')},
{action = 3002, cockpit_device_id = 8, name = _('IT-23 TV Brightness Axis')},
{action = 3003, cockpit_device_id = 8, name = _('IT-23 TV Contrast Axis')},
{action = 3008, cockpit_device_id = 9, name = _('ABRIS Brightness Axis')},
{action = 3001, cockpit_device_id = 23, name = _('Helmet device Brightness Axis')},
{action = 3006, cockpit_device_id = 46, name = _('ADF Volume Axis')},
{action = 3002, cockpit_device_id = 49, name = _('R-828 (VHF-1) Radio Volume Axis')},
-- my own:
{action = 3006, cockpit_device_id = 51, name = _('Lighting auxiliary panel brightness knob')},
{action = 3008, cockpit_device_id = 51, name = _('Lighting night vision cockpit brightness knob')},
{action = 3002, cockpit_device_id = 51, name = _('Lighting cockpit panel brightness knob')},
{action = 3004, cockpit_device_id = 51, name = _('Lighting HSI and ADI brightness knob')},
-- scoobie end.

 

in which lua file? Much apreciated to get maybe a better instruction from you.

Specs:
12th Gen Intel(R) Core(TM) i9-12900K   3.20 GHz,  RAM 128 GB, Win11 Home, RTX3080Ti

Posted

The file would be:

<DCS Install Dir>\Mods\aircraft\Ka-50_3\Input\ka-50_3\joystick\default.lua

You need to find this "axisCommands = {" in your file and inject things I outlined with those "scoobie begin/end" comment lines. People say you must use "Notepad++" editor for that, I'm not sure why but apparently some folks are using some editor(s) or other software that messes up Lua files. How - I don't know.

You also need to have some means of preserving your modifications - each DCS update will overwrite your changes, so you need a mod manager or another solution. Alternatively, there is a mod which lets you keep your own binding commands in <Saved games>, so updates won't harm them... it's just I can never remember how the mod is called.

There's an extensive tutorial on the subject made by LeCuvier here:

 

 

  • Thanks 1

i7-8700K 32GB 3060Ti 27"@1080p TM Hawg HOTAS TPR TIR5 SD-XL 2xSD+ HC Bravo button/pot box

Posted (edited)

Thanks a lot. I give it a try. 

But i stay on my opinion that it is a joke that devs are not able to implement a coulpe of lines into a lua file to make life easier.

 

And there are missing more things...only as examples: Shkval scan knoob. We need the single positions, not only "dial up and down" , HUD Mode (Reticle Night Day - same problem).

Sorry, but from a Version 3 of a 10 yrs old Model, i expect stuff like that.

Edited by Eisprinzessin

Specs:
12th Gen Intel(R) Core(TM) i9-12900K   3.20 GHz,  RAM 128 GB, Win11 Home, RTX3080Ti

Posted (edited)

Thank you all for your replies.

For my part, is "keybinds-waste" to spend 2 buttons for a pontesiometer type
from the time that my x-56 has 2 pontesiometers that i am using for all of my
modules. And once i can use the x-56 3 modes, with a modifier to each one
i can save 24 precious buttons for other functions.
Yes, i can use lua & editor to do this mnually, but i was expecting BS3 to
save us from al this trouble. Maybe as a wish list addition devs will add it.

Thank you.

Edited by ADHS

Democracy was already invented, while Scrat was eating oak fruits.

Posted (edited)

upload_2f890da246a6223d1f504c0277694070.

 

PNL Light - can not use (planned: HUD Brightness)

Wing Fold - can not use (planed: Hud day/nicht/reticle)

Select jett - can not use (planned: radio channels 828)

Sliders left/right: can not use - Axis

Park "stick" - can not use

 

Edited by Eisprinzessin
  • Like 1

Specs:
12th Gen Intel(R) Core(TM) i9-12900K   3.20 GHz,  RAM 128 GB, Win11 Home, RTX3080Ti

Posted (edited)

It's hard not to agree with you, guys 😞 Such a pretty panel...

On top of that... those "default.lua" files could be generated automatically. ED are not far from there (especially them, 3rd parties vary in this regard). In clickabledata.lua they already have the whole "zoo" of cockpit control classes, 2-way toggle switches, 3-way toggle switches, various "levers" etc. All they need is to enrich them, so each gets a human-friendly name (e.g. "Gear Lever" instead of LEVER_0136 - abstract example), introduce meaningful position names (e.g. {'CHECK', 'EDIT', 'OPER'} for PVI-800 mode knob) or "link" such names from the "library" of generic names (e.g. {'OFF', 'ON'}, {'SAFE', 'ARM'}, {'OPEN', 'CLOSE'}). Now, if the nature of these controls was defined, keybind commands could be generated automatically. And no - not ALL possible commands in the Galaxy, just a sober subset of them. We'd still need the possibility to add our own, because some people have really convoluted sim-pits, button boxes or whatever, so ED cannot cater for all such contraptions.

Examples below. Not code, just an idea. Very raw idea, not a ready-to-use solution (obviously). I can see already that some details below are silly, but it doesn't matter - the idea is shown. Examples look like functions, but they would have to be "mixed in" to what is already there in clickabledata.lua, not as separate entities. So, if a particular switch is defined in clickabledata.lua, it could be enriched with definitions similar to what looks below like a function (I don't have DCS here, so I can't throw code off the top of my head, can't remember how exactly things look like in clickabledata files).

Holy Directions are always these: out-in/released-pressed/bottom-up/aft-fore/left-right/CW-CCW; unjustified violation is a bug.
Behaviour definition: following holy directions, a position with an underscore is spring-loaded to postion "pointed with" the underscore, e.g. {ON, _ON} - the right one springs back to the left one. Something of this sort. (There must be some way of telling the code that a position is spring loaded, for example to tell between a push button and a latching 2-way toggle switch - they need different sets of keybindings).

No default positions or behaviours (from "the library") are given below - for illustration. Examples in English only. Translations of switch labels only where multilingual cockpits are planned or already exist (below it is assumed translations are neccessary).

k041_reset_btn = cpit_ctrl("_('K-041 Reset Button')", "_('K-041 Weapon Control Panel')", {ON, _ON}, {"_('RELEASE')", "_('PUSH')"})

generated commands for default.lua (just one):
'K-041 Reset Button PUSH'

Why only one? Because the "behaviour" says the control has only two positions, one of which is spring loaded - this is either a push button or a toggle switch of OFF-(ON) type (effectively the same as a push button).

2-way latching toggle switch, :
master_arm_switch = cpit_ctrl("_('Master Arm Switch')", "_('Instrument Panel')", {ON, ON} , {"_('SAFE')", "_('ARM')"})

generated commands:
'Master Arm Switch SAFE' ("stateful" command, e.g. for an ON-ON switch)
'Master Arm Switch ARM' (a/a)
'Master Arm Switch Toggle' ("relative" command for an OFF-(ON) switch, i.e. a pushbutton, e.g. a keyboard key)
'Master Arm Switch ARM else SAFE' ("spring-loaded command" for an OFF-ON switch)

How do we know we need these 4 commands? The control has 2 latching positions. Somebody may want to use a single button/key for it ("Toggle"), somebody else preferes seperate keys (e.g. "M" and "RShift-M") for either position. Someone else has a ON-ON switch, so he also may use the "stateful" commands for each position, explicitely. And someone else has a typical OFF-ON switch (TM Warthog throttle base or whatever), so he nees "spring-loaded command".

Now a real plane example - 3-way latching toggle switch.

A-10C, LASTE LAAP Mode Switch:
autopilot_mode_switch = cpit_ctrl("_('Autopilot Mode')", "_('LASTE Panel')", {ON, ON, ON}, {"_('ALT')", "_('ALT/HDG')", "_('PATH')"})

Middle position is assumed common for a set of two "spring-loaded commands" - this is for typical 3-way ON-OFF-ON toggles in joysticks. Switches which have more than 3 positions don't generate "spring-loaded commands" at all (they only get "stateful" commands for each position plus those "relative" ones - next/previous and toggle).

generated commands:
'Autopilot Mode ALT' (stateful command)
'Autopilot Mode ALT/HDG' (stateful command)
'Autopilot Mode PATH' (stateful command)
'Autopilot Mode ALT else ALT/HDG' (spring-loaded command)
'Autopilot Mode PATH else ALT/HDG' (spring-loaded command)
'Autopilot Mode Next' (relative command, only goes up/right/fore/CW, never "rolls over", i.e. goes ALT -> ALT/HDG -> PATH and gets stuck there)
'Autopilot Mode Previous' (a/a, opposite direction, so "gets stuck" at ALT position)
'Autopilot Mode Toggle' (relative command, goes "CW" around all positions, does "roll over", i.e. ALT -> ALT/HDG -> PATH -> ALT -> etc.)

These control keybind files shouldn't really be written by a human, EXCEPT where it is absolutely neccessary, which would be perhaps 5% of such files, the rest can be automatic.
Automatic means there will be keybind commands generated for EVERYTHING defined in the cockpit.

Same goes to axes, they seem even simpler than switches.

You define everything in an appropriate file (perhaps clickabledata.lua or another) in a fashion similar to shown above. Then you run a generator, which spits out auto_keybinds.lua. Then you manually write a "master" default.lua file, you include auto_keybinds.lua there ("dofile" or however it's done, I don't know Lua) and you add the neccessary manual (hand-written) commands to the default.lua. If any!

 

 

Edited by scoobie
  • Thanks 1

i7-8700K 32GB 3060Ti 27"@1080p TM Hawg HOTAS TPR TIR5 SD-XL 2xSD+ HC Bravo button/pot box

Posted (edited)

Hello scoobie

Thank you for in depth analysis. Awesome and gongrats for your project.
I've use your instructions in past to free the reserved (grayed) slots
of "Special for Joystick" category.

What i see here, is that BS3 is not something new but an extension of BS2.
Besides Igla addition, seems that nothing have changed since BS2 or BS1.
Off course i will give some time for improovements to the devs, but for
now there is nothing new. And as for other areas of DCS (monitors, temps etc)
sadly, i have to manually programming copy paste overwrite my custom fixes.

Thank you.

 

Edited by ADHS

Democracy was already invented, while Scrat was eating oak fruits.

Posted (edited)

This really pis**** me of. i mean we are not talking about a alpha. We are talking about a payed update from a 10 yrs ols module, where (nearly) nothing has changed in view of control bindings. Yes, thats really BS x3.

Edited by Eisprinzessin
  • Like 1

Specs:
12th Gen Intel(R) Core(TM) i9-12900K   3.20 GHz,  RAM 128 GB, Win11 Home, RTX3080Ti

Posted (edited)
20 hours ago, Schlomo1933 said:

Why u guys don’t use “Munkwolfs community bindings” with quaggles injector mod? 
 

all the needed/ requested bindings are inside. It’s for BS2 but also working in BS3 .

 

https://github.com/Quaggles/dcs-input-command-injector

 

https://github.com/Munkwolf/dcs-community-keybinds

 

Hello and thank you for your reply/idea to help.

This is a problem that goes many years in the past. When there were no HOTAS, with knobs.
Now, there are and we can have them. Even the most cheap joystick have knobs. BS3 doesn't.
(In my opinion) i don't like to use external apps or mods to fix something brand new
that i bought. If my new refrigerator have problem, i won't accept to fix it. I would ask
for a replacement with another NEW, that is not problematic.
Here is a bit different. We all buy "early access". Means that we accept that is not final.
Besides BS1 and A-10, the most that took a module to get out from early access was ten years.
So:
Usually, after every DCS update, most of the external mods even my own custom scripts
have problems and need re-programming. And this will getting worst once DCS deside
to upgrade it's core to multithread. Means that we've got to forget all of what we know.
Personally i prefer to create a common secure Logitech profile for all of my modules or
even to overwrite the Config after every update.

Thank you.

Edited by ADHS

Democracy was already invented, while Scrat was eating oak fruits.

Posted (edited)

@ADHSi know and understand completely how you feel …. The next stupid thing are that we need separate bindings for switch caps….

Heatblur made this so mutch easier. Flip the switch, and the cap will opened automatically. 
 

but I don’t believe that ED will change all those things in the near future. The cockpit is useable with mouse and most of the users don’t have complete cockpits at home. So they make only the most important switches as 2 and 3 position switches…. 
 

it’s just not more up to date….

Edited by Schlomo1933
  • Like 1
Posted
On 12/25/2022 at 9:38 AM, Schlomo1933 said:

but I don’t believe that ED will change all those things in the near future

Hello.

For now: Logitech profiler -> Bands 🙂.

Thank you.

Democracy was already invented, while Scrat was eating oak fruits.

  • Recently Browsing   0 members

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