virgo47

I've got two icons pinned on my taskbar - DCS MT and Updater with parameter, so it doesn't start DCS - because otherwise, it starts default (non-MT) DCS. The end of my target looks like this: ...\bin\DCS_updater.exe update Also learned the hard way after being used to auto-update. This issue is not a problem for Steam users, but I'm sure it will be eventually gone when MT is our only version. Back to DLAA problems - or promises about the future of FC3 HUDs!

I can confirm it works well and the zone in the mission editor looks great too. Thank you very much!

The issue is fixed in the latest OB 2.9.0.47168. It is not blurry anymore, however, the HUD is of lower quality than the rest of the scene or when MSAA is used. Su-25T HUD now with DLSS+DLAA is quite jaggy (200% zoom): But otherwise, it works fine. It looks much better with MSAA though (different moment in the same mission, 200% zoom again): So I hope this is not the final version, but the most prominent problem is fixed. Thank you, ED.

I can confirm that after removing the Clickable-FC3 mod and then running .\DCS_updater.exe repair from the installation bin folder the issue went away. I can easily live without the mod (which is cool, if for nothing else, for all the labels/tooltips it gives you), but I can't live without HOTAS in F-15C. I'm not sure whether this is solvable by ED or whether the mod authors have to update it for 2.9.

I'm not at home at the moment, but I do indeed have the FC3 clickable cockpit mod active. I'll try with the mod disabled or uninstalled on Thursday when I get back home.

I wish this got at least aknowledged by ED. In 2.9 I'm more affected by bugs than features, which I can understand IF the fixes are coming soon enough. I like FC3 planes and with Su25T ltv bug there are at least two bugs that are not related to DLSS but are clearly a regressions.

Yes, I can confirm this, only some part of the TV is usable after the upgrade. This is easily reproducible after a few steps in the training mission "Vikhr Laser Guided Missile and Mercury Pod". I played it just a few days ago before the upgrade, and everything was fine. Now it looks as in the picture above. (I also played this just a few days before the update and everything was OK.) I tried single-threaded version as well - and that is also bad - nothing is visible there at all.

I tried Su-25T HUD, Caucasus Free Flight, just turning a bit and pitching up/down. It was always ghosty/blurry, with DLAA alone or with DLSS Quality. I had head-tracking off, so the HUD was moving only against the sky/ground. I tried both with sharpness 0, 0.5 and 1, it seems to do something, but I'm not really sure, because it doesn't help.

I guess they are gone, not a problem to redo them from my list, but currently it is not possible, when it's "darker", it's not available. Somehow the definition of these bindings refuses gaming devices except for the keyboard. Many modules have similar bugs on a smaller scale, but this one came out of nowhere.

This is OK in general, I also have one momentary button as a modifier on my throttle. What I suspect more is the logic behind those <> bindings marked as "Special for joystick". I don't have this module, but these often have a logic behind them, e.g. "when the button is not on anymore, return to default position". Try the bindings above, they should cover the same switch positions, or not? Often the <> stuff is for switches without middle position "press", but if you have three position with three logical presses (as it seems), you should be fine with the absolute bindings.

Great, I can confirm that with Canopy Jettison + Ejection (3x) - in this or reversed order - I was able to eject. Thanks for the fix.

After the latest 2.9.0.46801 (MT) I can't reconfigure tons of previously bound commands to my HOTAS for F-15C. The scale is staggering: I'm a firm believer - if it can be bound to a keyboard, let us bind it to a controller/HOTAS buttons as well! I know, this is just a regression, but you should somehow make some order in these matters, please. I hope that F-15C is popular enough that we will get some quick patch for NOT being able to turn even the radar on with HOTAS!

Yup, noticed this with Su-25T as well. Seems to be caused by DLAA, as it blurs the HUD with or without DLSS when DLAA is enabled. RTX 3060 12GB in my case.

This makes sense! The zone is quite small - if the graphic is precise - because it is quite likely I aligned just in front of the numbers 09! I'm not sure if the zone can be enlarged without triggering lots of QA on your side, but I'd suggest to cover the wider area - e.g. anything fromt he start of the runway for the most "borderline" pilots. What could have happened when it did not work with the axis and then worked with the +/- binds is that I moved a bit, just to get to the zone. If it checks the gauge (and not the binding) it is generally the right logic. Thanks, Flappie, this all makes sense. EDIT: Why can't I remove/change the "solution" mark? Or is it possible somehow?

I'm totally puzzled now. I tried today and couldn't reproduce it either, although previously I definitely managed to repeat it a couple of times - otherwise, I would not be able to figure out the "workaround" and I'd not dare to report it. So I guess it's "cannot reproduce" for now. Sorry about it. If you see something suspicious in the script, cool, but while I'm not 100% sure it's OK, I can't do more about it now.

So it is flaky somehow? I'll get back to this and provide the trackfile, it was pretty reproducible in my case, I could repeat the test a few times and nothing, but I'll double-check and get back to you.

Yes, I forgot to mention I know the trick. The report is about official training missions that should just work. But thanks for mentioning it. I just copied the file from \games\dcs-openbeta\Mods\aircraft\Flaming Cliffs\Missions\Training\MiG29S - 8 - KMGU-2 CBU Dispenser.miz (installation directory) to my Saved Games DCS.openbeta\Missions\, opened it in the Mission Editor, saved it - and it started to work without even going to the zip.

The mission cannot be started as it requires WWII Armour and Technics? This must be some kind of misunderstanding, or leftover accident in the mission file. I don't remember doing this before, so I'm not sure if it's a regression or what. But I'd like to start it without WWII module.

The training mission description shows CCRP: But the mission itself is all about CCIP, e.g.: This should be easy to fix in the mission description.

They recently (not sure when, some time between 2.7 and 2.8) changed the mission... slightly for the better. The first group is now 5xM113 instead of a single quite difficult and fire returning vehicle (in addition to a lot of side-wind)... and the second group are 3 HEMTT which are easier to dispatch with the pods. (Green smoke is missing though, but not a problem.) I'd say this is better than before... wasn't there one Abrams in the old days? Definitely something crazy for the pods. M113 are still tough targets for the pods though. BTW: Perhaps I'm stupidly hard-headed or what... but I'd say this is the most played mission for me. I don't recommend that to anyone.

There is also one important distinction between 4x and BSE (which is actually VSE or "vsjo"). BSE still works only for 4 pods, but it also zeroes any gunpod elevation. This is mentioned in the training mission for pods - but it does not explicitly mention that "all" is not gunpods+internal gun. BTW: I'm not sure what I'm doing wrong, I tried many times, but the results are often anything but "a rain of 23mm rounds can be quite deadly". Pods seem to be extremely weak against anything except unarmoured targets. There is no comparison to the internal gun which is many times stronger.

Hi guys! Modifiers seem to be dead-easy, but there is a bit of depth in them, especially when used for axes. And they can be renamed, which is super cool for a couple of situations. So here is my take on the topic:

Yup, modifiers are plane-specific, you can have the same button as a modifier in one plane and not in another. You can even have two different physical buttons as the same modifier (when you specify its name) in two different modules. When you define the modifier there is a warning that the button is used, but you can go on - which is actually good. You'll just see all the wrong bindings with red exclamation marks. I've just created a video about modifiers, btw... there are some interesting applications, especially with axes and when you play with the logical names of the modifiers:

Do you use that modifier as "modifier" or is it a "switch"? I've never had such an issue with a modifier, but I can imagine it with the "switch" (which I totally ignored until today).

I totally missed this thread but not the issue itself. I didn't know it was a new problem because I had wrong default fov in some planes long before this, so I didn't bother. After some experiments I too discovered that there is a workaround. After using any snapview the zoom normal works again! So now I just calmly press snapview 5 and zoom normal - which I have next to each other - and go on. But it is an embarassing bug indeed. BTW I use 2560x1440p common resolution.