virgo47

I was confused why some VORs don't transmit their callsign - they are simply silent all the time. I investigated and the conclusion is: Pure VORs (BEACON_TYPE_VOR) transmit just fine. VOR/DME stations (BEACON_TYPE_VOR_DME) do not transmit the code. I checked this with UH-1H both VHF AM and NAV-COMM radios and also with C-101EB with its VOR radio. I could clearly hear the signal from various VORs, but never from VOR DMEs. For example, sitting at Mezzeh (Syria), Damaskus 116 MHz VOR is totally silent (navigation still works). I checked the same on Persion Gulf map and found the same. Video demonstration: My position: Mezzeh 113.90 MHz is Baysur VOR (no DME), close to Beirut, 70 km away with mountains in between, code BAR - clearly audible. 116.00 MHz is Damaskus VOR/DME station, 25 km away more or less plain, code DAM, never received.

This one seems to be tricky. I extended the numbers in limits_6DOF, but this seems to work only for non head-tracking situation. I can easily move with above the central console with the bindings (when TrackIR is off), but not with the trackIR. I'm still not sure what is happening, but there definitely is a discrepancy between camera movement limits with bindings and TrackIR. I discovered this in UH-1H, but so far I'm not sure about other modules. EDIT: Perhaps the head-tracking range itself is not adjusted (I'm still not sure about it), but the "center" of the head is definitely modified - so you can combine the extended limits, move your camera/head where you want with the camera keybinds, and then additionally move it from there with head tracking. It's interesting to see your headless body this way... but I'd still like to see wider movement with the head-tracking because the head-tracking SW shows that I'm tracked in a wider range, but DCS stops moving within narrower limits.

I'm not sure what was done about it (EDIT: UHF reportedly fixed in 2.8.1.34437), I checked NAV-COMM (aka VOR/ILS), VHF AM, FM and UHF and currently, only VHF AM bindings are reversed. These: All volume bindings seem to be OK.

Naming of the elements for NAV-COMM radio (VHF navigation radio AN/ARN-82) is very confusing. I was absolutely convinced there are no bindings for it, spent some time looking at Quaggle injector setup for it (in vain), looked in Lua files in the UH-1H mod itself and after some device cross-referencing back and forth I found to my amazement that it is all there under VOR/ILS section (that "hides" in plain sight at the bottom of all sections): There is no help in the cockpit itself, because this is what the controls on the obvious VHF AM radio tells you: And this is what the similar NAV-COMM control tells you: There is nothing navigating us to the right section - and vice versa, VOR/ILS - while technically not altogether wrong - doesn't help us with referencing any other keywords "newbie" may use (VHF, NAV, COMM, AN, ARN, 82, nothing). Perhaps at least renaming the section (keep VOR/ILS there, but add at least NAV-COMM or something) would help. In the foldable view it's visible, and in the non-foldable view the category is also shown when searched for. Perhaps I'm the only one who lost nearly two hours to bind this. I don't know...

I like the gates... but for over a year it feels like nobody at ED cares enough about the gates, not even the single-player ones, to fix the scaling of the next gate. I remember vividly how important for my first steps in DCS and Su-25T the gates were - especially the scaling of the next one when player missed it. This is all gone with MT (which should be the go-to) version of DCS. I hope they will eventually fix this because I strongly believe the gates have their use and the functionality should not be abandoned, but indeed, expanded instead. It makes many missions fun and it is a useful tool.

I confirm that it works with 2.9.5.55300. Thanks a lot, guys.

It works with 2.9.5.55300! Thanks a lot!

I was happy to see F5-E, F-86F and MiG-15bis on the list! I didn't expect that (F5-E was announced shortly before the patch). L-39 is high on my bug-fix-wish list - and so is Yak-52. At least trivialities such as toggle bindings working as toggles. But overall, I'm happy to see at least some love for older modules there.

I believe the release dates are somewhat optimistic-realistic. Anything might have gone wrong. Perhaps the testing was progressing but in the end some issue proved harder. It's not like everything is tested two weeks sooner and they are just hovering over the "RELEASE" button. I've seen last minute surprises even in highly automated SW environments. Sometimes even when you didn't touch anything. I'm looking forward to tomorrow... or the day after.

Thanks for the info. DCS-BIOS profiles don't seem to handle neither axis inversion nor default switch positions. (I may be wrong, but there doesn't seem to be any parameter for these.) So for L-39 (and in the future perhaps other modules), patching/amending/extending DCS-BIOS config with PP files seems to be the only way. As for the TP-end for slider inversion, the feature request was acknowledged... but god knows when/if that is implemented. That's just an update from me, no pressure.

Will that be a free tool? I'm a bit confused about the messaging around this... Even as a premium tool - it will still be better than nothing, but that means that except for big fans or people who make money from missions will not benefit from this. Which would leave the current ME in a bit of a sad state.

Yeah, not to mention that perhaps a Shift+misclick shouldn't have such a frustrating effect.

Today I had some problems flying UH-1H after a hard manoeuvre, and while trying to figure out what is wrong, I checked Debriefing log window. No damage, so I tried to recover, believing the ship is fine. But later I saw this: Main rotor gone, no report of damage in the log. Is it OK? I rely on the info there for learning what went wrong, now I know nothing. (Well, in the picture above, I know what went wrong. But in other cases, I don't.)

That sounds reasonable... BTW, do I see it right that this does not affect F2 or other external views, only the view from the cockpit? I tried to find the device around my Albatros in F2 or F4... but I can't turn my head enough to see it in F1. Originally I though this is a very ugly hack, but if it only affects F1 view, then the position under the tail and facing backwards (just as it would in the cockpit) sounds reasonable. I also checked the night - seems good as it is, but the move/turn should not affect it at all. So yeah, I think it would be a better position!

L-39 module has a coarse trim, the action is quite fast, so even a short tick to the trim hat changes it often more than for the perfect position. In any case, without a track file, we can't say more.

That sounds taxing. Of course this is only for "sliderable" things, that is ctr(...). Not sure how that is handled. Currently, there is no sync from cockpit (you mentioned that caused some performance problems too), so it should only be relevant for outgoing changes. But I don't know the architecture and possibilities, so I'm not sure whether this can be optimized. BTW: Wouldn't a separate ictr(...) control type help? This is the tricky one... so far I only worked on some description fixes - this doesn't break anything. I may also suggest those default switch positions we talked about for L-39, that should also be OK - but for now, please leave the PP file "patches" there. But inverting a value - that breaks all existing panels built for UH-1H. Not sure how many people have that. I'll ask how they see it. For what I know the inversion may come all the way from DCS, it wouldn't be the first element that is inverted (wheel brake axes in various planes work opposite for whatever reason). I had also another idea, to suggest this to TP directly. For them it should be reasonably easy to invert the slider and it should also be efficient enough. The question is what's their backlog and when they get to it, of course. So, let's not sweat it on your end right now, unless you find some nice and easy solution , and I'll talk to TP guys first on their Discord. Even if it's not done, one can still create those top-to-bottom "inverted" sliders with a hack (inverting the value/background color) - so it's no show stopper.

Ouch, now I see... I was wondering what kind of direction the shadows represented. Strange "design". A flat 2D representation for popup would be perhaps even better than this... monstrosity. I bet it's also behind those other brightness-related issues.

Hi, thanks for the update. About the inversion - do you mean that having an inverted value would cost for any other action as well, not only when the slider changes? And if so - only if used or even if added as a feature (minus some if check, perhaps)?

@xoomigo, hello. After some time with L-39, I returned to UH-1H. And the beast has all the volume knobs inverted. My memory is overloaded recently, but I recalled that we talked about it - the need to invert the sliders, so that 0 is max and 65535 is min. Please, is that feature still on your TODO list? Currently, I'm using a nasty ugly trick with inverted colors - but this means I have to slide down for more. EDIT: I'd also have some PP patches for Huey (duplicated "Volume" names from DCS/DCS BIOS are quite confusing), but I'll probably get more, so just let me know when you're about to release and I'll sum it up then. I started the cosmetics contributions to DCS-BIOS - such as Description fixes, e.g. deduplication (adding specificity) or fixes of typos (e.g. Back vs Front for some L-39 elements). This means that when they release a new version and you'll use it, eventually some descriptions will be fixed. To fix it at the source (DCS-BIOS) makes more sense for these things. EDIT2: What DCS BIOS build do you use? Is this the current official repo now? https://github.com/DCS-Skunkworks/dcs-bios

It's better with those things, but it's not "nothing". I never wanted to transform scale and rotate, perhaps because I never expected such thing from the current editor, but many times I wanted to move/clone a few selected units - and use marquee select for that.

Mentioned in another thread, but I'm not sure you're tracking this: When one tries to resize the device, the bar gets resized but the device does not. After that, you can also freely move the bar away. To see the new position and size you have to cycle the view of the device (off/on).

Hi all, I tried NS430 after a long time, in MT the brightness of the scene is not affected anymore, however, the NS430 itself seems very dark: This is in L-39, so it's probably modeled somewhere where the gunsight is. The display is fine, but the rest is mostly this rather flat shades of black. As I turn, I can get it brighter, in some particular directions I can even get it like this: But this is only a very particular angle, most of the time it's significantly darker or plain flat looking. Would it be possible to make it brighter overall or at least not so dark in the extremes?

I fully understand why it can't may be nontrivial really. Just because we see virtually the same set of parameters (sometimes some go away, e.g. between FLAG IS TRUE or TIME SINCE FLAG there is additional time) it doesn't mean the dialogs are designed to share the info, it can even be programmatically a different piece of input (and perhaps if it isn't, that's what caused the problem, just speculating here). Also, if I first chose a wrong action/condition accidentally (non-flag) and then another one with the flag, it would be nice to see the original values - and it works this way in conditions. E.g. after going through a few completely different actions, if I return to FLAG EQUALS FLAG, both flag name inputs are preserved. The UX question then is: If I switch from condition FLAG IS TRUE with 6 to FLAG IS FALSE and change it to 5... what should happen after I change the type to FLAG IS TRUE? Currently, the new 5 stays there, which is probably what we want when working with flags. But if we looked at each set of parameters for each TYPE as a separate subdialog, then seeing 6 would also make sense. Finally, these are not even dialogs, it's just a bunch of inputs, no confirmation, whatever you do is applied. I guess all this affects what is possible and what is difficult to implement in ME. I'll not comment on the architecture of ME.

I guess the undo can be the harder one, but why the "marquee select" does not work is a bit beyond me. I often try to select multiple units only to misclick (which is extremely easy) to lose the whole selection. I wish it was easier to consistently select the units without accidentally deselecting everything.

I like this "bug" a lot when changing conditions... it's a small but nice life-quality feature. Hopefully, they can make it work in actions as well without "messing with other parts".