virgo47

That means you did not save the profile explicitly - those are your saves, not game's saves. You have to click on the device dropdown menu at the top and by default this is the selected folder. It's your backups, but still stored under Saved Games folder. But not to be confused with automatically managed input config of the game (Config/Input), separate directory is used.

OK, I've got mine for two days. It's a great piece of gear. I love the detent system and overall feel. However, one of my fears came true and so far I can't get to a satisfactory solution. I love the encoders on the STEM module, they are useful and I'll use them as encoders. But so far, I hate the encoders on the grip. They are no substitute for a real axis. True, they can be configured as an "axis" and move it relatively, which seems fine, but their step is way too big - ~15°. This is fine for encoders, but not as a minimal step for an axis. You can have either a fast and imprecise axis, or a slow axis that is hardly usable. Do you have the throttle and prefer the encoders? How do you use them? For what function in what planes? Do you use them as encoders or mapped as an axis? I know we're talking "money" here, but I wish any of the triggers had a spring-loaded axis (e.g. for eastern-style brakes if you don't have a stick with it) and there was a spring-loaded self-centering axis and another normal rotary axis instead of those two encoders. Encoders can't even work as push-and-hold for some action. The rest of the throttle is great. I like the Standard version, good size, not that much bigger than my old TWCS, and actually narrower. Great upgrade with tons of new possibilities. But I'm not sure when (and IF) I overcome those encoders on the left grip. Not a good substitute for an axis, and I have no use for encoders there. So far all the uses I came up with would be better served even with self-centering two-way switch/hat.

I'll gladly contribute this kind of changes when the time comes. I know that after PP change I have to regenerate the plugin, that's not the problem. (I do this after upgrades as I enable EU speed in common data. No problem.) How about those inverted sliders? Is there some kind of way to do something like (65535-<valueFromBios>)*-1 in the PP file for that =ctrl(...)?

I don't think there is, it seems that the previous plane goes offline when you actually start another plane (change slot and click Fly). That's how the events are delivered.

Hi @xoomigo , another question popped up during my stab at UH-1H panel. I'm adding volume mapping for radios and I've got a couple of problems. I know you're generating PP files somehow and the problems are probably on the DCS-BIOS side (if not DCS itself), but PP file is the place where I can fix it: Many names are quite terrible, short, non-specific. E.g. "Power" is actually VHF COMM Power, but that's difficult to guess. And there are two "Volume"s and two more "Volume Control (step...)" for various volume knobs. It seems that the PP order is preserved, so eventually I can map it all somehow. But adding insult to the injury the volumes for the radio are INVERTED! Max is 0 and vice versa. Can I somehow redefine the =ctrl(...) expression to invert it? I can be creative with inverted colors and have slider going from top to bottom, but that sucks. There are also minor offences like Dome light saying that 0 is WHITE when in fact it's GREEN. But this is no problem at all, I can just add a comment to the button and march on. Compared to inverted sliders this doesn't bother me at all. But it all brings the question. Do you regenerate those PP files every time, or do you manage them separately and only merge in changes from DCS-BIOS? Would it be possible to fix it on your end or should I manage my own patches for PP files - for times of DCS-COINS upgrade.

Guys, what is that COMM TEST button on VHF radio supposed to do anyway? I press it when out of tune - nothing, in tune - nothing. Manual - nothing (except there is a binding for it). I can use that radio to contact the tower, so I guess I here something through it. But what does the TEST button do?

I'm mapping these volume knobs to sliders in Touch Portal via DCS-COINS and DCS-BIOS - and I noticed that they are inverted (0 = max value and vice versa). Is this somehow related or is it just DCS-BIOS issue? Originally I thought it is, but seeing things working "inverted" here, I rather ask before bothering those guys. I also noticed that many right/left clicking in 3-state switches is exactly opposite to "ED standard" (e.g. L-39) where right click goes up and left click goes down - but that is probably a completely different story.

On the collective, search light hat is configured so that EXT is up/fwd and RETR is down/back. I set my hat the same way. But when I actually press EXT binding, the hat in the cockpit tilts AWAY from the EXT description (down). I don't know what the real movement of the hat is, but isn't this a bug? For L/R it acts as expected - the hat tilts toward the used direction. Is this inversion in real UH-1H as well? This looks more like a cockpit bug. Actual function is fine, EXT extends the search light in the exterior.

+1 on this and all similar cases. Whenever I can use a key, why can't I use a HOTAS button too and vice versa. There are many instances of this bug in many modules and the inconsistency is frustrating. About this one specifically, this is an example of how multi-crew binding for Huey is not very well designed. Why do I need different bindings for the "same" button on another stick? I can't actuate the button on the partners stick anyway - just try it, bind the Pilot Unhook, switch to 2, press it - it doesn't move (or is it just a visual sync bug and it works? I don't know). In any case, there should be one binding for the same button on both cyclics and it should work depending on where you sit. OR two separate control sections, so we can define the same button for each of the "same" buttons on both sticks. Current setup makes no sense at all.

Ah, I see that. I didn't know where the limitation was. Never mind then. Thank you for the explanation.

Yes, something like that - to avoid 5-way IF/ELSE nested block. I have Number TP variables backing most of my buttons anyway. This way I could write "increment" and then set that incremented value to AC Voltmeter Source, instead of doing it in IF/ELSE block-fest. Of course, this would be practical for any more than 2-state button, but 3 is still manageable as well (I've done many of those)... around 4 it starts to be more annoying. But I'd understand if this was the least important thing in DCS-COINS for you, of course. I like it as it is, I like the sliders added previously, it's cool that we at least CAN do this.

I'm not using the existing Huey page, but doing my own for the fun of it. Huey/DCS works fine and communicates with the buttons - or at least with those few from the overhead console I managed to configure. I had quite a problem with DCS-BIOS for a while though, it reported the common values, but none others, I tried to reinstall it repeatedly, in the end, I even removed/renamed the Export.lua, just to make it work, because otherwise the DCS-BIOS installation didn't add the line there. But in the end, it should work. I tested it by running cmd, went to Munt.G_DCS-COINS directory and ran: DCS-COINS.exe -v When it didn't work properly, I could see an action on Touch Portal button press, but no activity in DCS. Also, there was no activity when I did something in DCS. Not only for UH-1H module, but for any other module that worked for me before. After persuading DCS-BIOS to work, I could see both-way communication clearly and everything worked fine.

Talking about possible flexibility improvements... The first section shows how I cycle through three states now. The second shows, how I can't - because I don't see a way how to set AC voltmeter integer value directly. Would that be easy to implement? This only gets more and more elaborate for 5 way knobs (DC VM in Huey), etc. I tried to put the actual commands into On Events sections instead (where the red box is): But this does not work very well with the increment command. If I click very fast on the Touch Portal button, the increment action and the setting in On Event phase feet into each other and the cycle can start that is very difficult to stop (mostly by slowing down either Android app or DCS). In other words, it's not systemic, I'd rather not issu commands back to DCS-BIOS when I react to DCS-BIOS, if you undestand me. I'd like to drive everything with variables. I can leave it in On Pressed section, but then I can't avoid that ugly multi-level IF that only gets uglier with more values. Having action to set the value directly would be cool. At least for more than 2-way switches. But... I realize, it is ANOTHER action. Unless the same action offers both direct value (like today) OR variable. I don't know what you see as reasonable. Or do I want too much?

No rush at all. BTW: Touch Portal guys plan to add rounding in the next major version (but it is not planned yet). They also plan to support multi-page import with the same values (reusing value IDs from previously imported page), which will be super practical for multi-page panel for a single plane. And multi-page export/import too. So I've learned on their Discord today, although we don't know how far the version really is. Finally, they gave me a tip how to round it with text processing, quite complicated, but in my case I didn't mind to "floor" the number of meters (round down). So my solution in the end was very simple: So at least for this scenario, I'm covered.

Hello, xoomigo, sorry to bother you again. I'm trying to solve one cosmetic problem. In common values, DCS-BIOS provides speed both in metric (_EU) and imperial (_US) variants. But for altitude, I don't have that option - only feet there. Touch Portal offers some options, but it is cumbersome: Using something like ${(value:mgdc_commondata_st_alt_msl_ft) / 3.28} does not work. You have to set an event with "When the plug-in state", then choose the common alt feet value, and use "does not change to" option with some unlikely value (e.g. -1). Then you can do some math "Calculate with Value), but / 3.28 produces an ugly number with decimals, there seems to be no rounding available. So it definitely is possible somehow, but it is not satisfactory (at least what I know about now). Would it be possible to add some basic calculation and rounding to your PP files? Is it even possible to have two lines there bound to the same DCS-BIOS input?

Thank you for the example. On my end it's not Arduino device, but virtual Android panel with limited options. I will check with DCS-COINS project (an intermediate layer) if they can add some basic math into their definition files.

I assume it is possible then. I also know how to convert feet to meters. (I actually do that in my head now when needed. ) But I don't know where to do it. In my previous question, I asked about CommonData.json, but now I realize this is already part of DCS-COINS, not DCS-BIOS, as some kind of definition, or interface, between DCS-COINS and DCS-BIOS. In DCS-BIOS there is only LUA file. Should I add another defineIntegerFomGetter there? If the customization means I have to adjust files after upgrading DCS-BIOS, I'd probably just skip it. DCS-COINS will not introduce the definition if it's not in DCS-BIOS. Is it viable to request it on DCS-BIOS side?

I'm using DCS-BIOS via DCS-COINS for Touch Portal (Android). I noticed that common data offers ALT_MSL_FT only, while for speed we've got both imperial and metric systems. Is there a way to add some kind of ALT_MSL_M? And if so, is editing CommonData.json in DCS-BIOS all that needs to be done?

Great news! I understand the frustration a bit, many modules have annoying long-standing bugs... great one of them is down now.

Ah, yes, my bad, I forgot that DCS-BIOS is not updated automatically. I removed the old one, DCS-COINS installer installed the new one and my Black Shark III reports properly again. I wrote it to my notes, because I do it so rarely, that I bet it's not the first time I forgot to remove the old DCS-BIOS.

+1 on this. I was surprised to see separate bindings for the same (relatively speaking, from the pilot/copilot seats) buttons and functions. Having bindings for pilot's radio buttons that don't work from copilot position anyway is not useful at all. I have one stick, but I can't have the radio there after I switch positions, unless I use some kind of modifier. There is more to this, but first I wasn't sure. Perhaps it's normal that the pilot extends copilot sights, but somehow I doubt it. Why is there a different keybind for each sight? (Strangely, but luckily, the copilot cannot extend the pilot's sight. ) I know these are physically different switches, but the reality should be practically adapted for the simulator. For comparison, this is much better executed in L-39, where two physical buttons with the same function in both cockpits have the same binding (e.g. intercom on the throttle). This doesn't seem like a feature, this is more a design bug. Either the buttons should be unified wherever possible (preferably) - working only from the position where I currently sit (this applies to anything duplicated on the dashboards too, such as QFE pressure knob, etc.) - or there should be two separate profiles in Controls Options which would allow us unified settings. (BTW: Is this taken into account when it's not in the bugs subforum?)

Great update, thanks for it! I want to ask about Ka-50 III. When I start dcs-coins -v, I can see that various mgdc_commondata_* is coming in for L-39 or UH-1H, but not for Ka-50. Is that COINS or rather DCS BIOS problem? I also tried to flip some switches, but these didn't log anything either, so it's not only common data, so it seems. BTW: Have you been thinking about that GitHub or other project for DCS COINS?

There are two aspects of this: Drop in FPS. Would be nice to be more graceful. Drop is OK, but FPS dive like this is bad. But that is still not my main concern. Unresponsive game that needs to be stopped. That's my problem. So I don't mind the slideshow. It's ugly, but whatever. But... DCS, please, just let me continue on the mission.

If anyone gets here, check Uncoupled Aiming On/Off binding. And in case you want to use the joystick for aiming Absolute/Relative Axis Aiming is also handy. With TrackIR you'll still have separate view and aiming, which sucks a bit. There should also be an option to sync the view to the gun - or, indeed, to disable the TrackIR, which effectively does the same.

+1, this is an unnecessary limitation. If I can aim with the joystick, it would be neat to be able to enable it with it - not to mention the default RShfit+T is hardly a one-hand binding. The same goes for Absolute/Relative Axis Aiming (RShift+Y by default), which is especially handy for joystick aiming. Also can't be bound to controller buttons.