virgo47

+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.

EDIT: Never mind. Uncoupled Aiming On/Off seems to be the answer, works for the gunner as well! It would still be neat if DCS had a global binding to enable/disable Track IR. Going to the Controls and right-clicking there ... it's a bit annoying. However, for this scenario, Huey provides that "Uncoupled ..." binding, so no problem. (Except... it can only be bound to the keyboard, but better than nothing.)

If I shoot the ground up close, the particle effects make the game stuck and unplayable, although while recording the bug I noticed the FPS graph goes on. The game does not fix itself anytime soon (if ever), it's not completely frozen technically, but it is from the player's perspective. It does not react to input at all, the view is frozen too, etc. Only Task manager helps in this case. Video (see the graph up left): This reminds me of similar problems I had with cluster ammunition when I was flying Su-25T more than a year back. The moment the game gets to single-digit FPS, it's likely to get stuck like this. I guess it's not really Huey-specific but related to the low performance of smoke close to the player. This is the first time I encountered it with RTX 3060 I've gotten a year ago, but, granted, I haven't shot the ground from this close since. Seems like faster FPS helps, but the problem is somehow systemic. The game should be able to recover from low FPS situation, not effectively freeze. Log is attached. dcs.log

What? Oh, shh... you're right: https://flightsimcontrols.com/2023/09/08/stecs-in-eu/ (last paragraphs), I wish the warning was closer to the actual price tag. That's the price for impatience but never mind now.

Perhaps it can be limited to those other buttons, not left/right. Those are very unlikely to be pressed on hover. Depends on when you want the tooltip to go away, of course. But thanks for the feedback!

Thanks for the info, it must be a day max or so. Well, the pricing isn't THAT great after all 320 USD + 20% would be around 360 EUR, but it's 415, so the EU is paying an additional 15% premium, not to mention shipping - but I guess that's EU reality. But it was my birthday recently, so I'll probably finally replace my TWCS. 3 mins later: I opted for Standard after all, and it's ordered! Damage is done...

BTW: Enigma has a good video review on his YouTube channel with some interesting thoughts and solutions, e.g. encoder to axis, etc. Compares it with Virpil Throttle CM3. I'm still waiting for EU pricing, I hope it will not be that off from US (+VAT of course), because in US prices the value is very good (even if I add ~20% for VAT).

This is not a serious bug, but it is kind of strange and definitely annoying. I use a side button on the mouse (indicated as MOUSE_BTN4 in DCS) for two disjunct functions: Center View - when I don't use head-tracking And "Toggle while held" in opentrack, when I do use the head-tracking The problem is this: When I press the button with head-tracking, to stabilize my view, the cockpit elements DON'T show any tooltips, unless I was positioned on an element and the tooltip was already shown. Then it nicely shows also tooltip for other elements I move my cursor to. Otherwise, no tooltips. First I thought the Center View binding is causing this, but it is not. Even when I unbind it, it doesn't help. I could understand BTN1/2 disrupt the tooltips, because we use this (+ the mouse wheel scroll) to interact with the elements. But the tooltip is not shown, even if I press other buttons (mouse button 4, 5, etc.). I know it feels obscure, but: Anyone: Can anyone with temporary head-tracking disable button on the mouse confirm this? DCS: Is it possible to fix it? It would help tremendously in cockpit exploration when it is very hard to keep the mouse on smaller elements to get the tooltip. Of course, I can also bind the button to head-tracking toggle, but that is less flexible (I cannot use the button with modifiers for other tasks without toggling the head-tracking in the process).

Hello guys, With both Black Shark II and III, I encountered a strange problem I'd never seen before in any other plane. Normally, when I save the snap view (Save Cockpit Angles, RAlt+Num0 by default), I see no difference, when I go to the snap view right after saving. But in Ka-50, there is a camera shift, like some axis/translation is not saved at all. I played with it for a while, it seems that it is somehow related to the translation that comes with view rotation in the horizontal axis beyond ~90deg (you can see that the "head" moves forward for these). Strangely, the snap view is shifted EVEN MORE forward for these. Now, I'm used to the snap views being somewhat relative - they change with the chair height, or in MiG-15 with the Q-key (view align to the reticle), etc. This is all annoying but somewhat understandable... but this situation in Ka-50 makes any over-the-shoulder snapviews double hard to set - and you never get exactly the angle you wanted.