virgo47

Or, the issue is RWY 33 with 0 wind. If it was 15 for 0 wind as well, Gudauta would be perfectly OK aerodrome that prefers 15 and switches to 33 when the upwind for it reaches ~3 m/s.

Yeah, I'd also think 33 is preferred for landing (and no problem for takeoff as a default), those mountains are really difficult to ignore on landing. In any case, the current situation is suspicious at least. I don't understand why the default map in DCS has multiple long-standing ATC issues.

When investigating... ...it started to be obvious, that Gudauta acts strange. So I've done some wind-related investigation and the results are: With 0 ground wind, RWY 33 is used - this would suggest that this is the "default" runway unless the opposite wind is too strong. But with any wind along the runway less than ~3 m/s in 151° direction (meteo 331), the RWY 15 is used. Now THIS also suggests the runway 15 is the default one - except for no wind at all. I tried various crosswinds - from either side, RWY 15 is used... of course, unless 0 m/s was set. (0 speed ignores the direction, which makes sense.) This really looks like the "default" runway for Gudauta is RWY 15 and there is a bug which surprisingly uses 33 with 0 wind.

So I've done some investigation and the results are: With 0 ground wind, RWY 33 is used - and this suggests that this is the "default" runway unless the opposite wind is too strong. With any wind along the runway less than ~3 m/s in 151° direction (meteo 331), the RWY 15 is used. Now THIS also suggests the runway 15 is the default one - except for no wind at all. I tried various crosswinds - from either side, RWY 15 is used... of course, unless 0 m/s was set. (0 speed ignores the direction, which makes sense.) What this suggests is that the true "default" runway for Gudauta is RWY 15 and there is a bug which surprisingly uses 33 with 0 wind. THAT SAID... the mission still uses WPs for RWY 33, so the wind should be set to 3 m/s.

So this now seems to be reported as a part of: I guess this is a duplicate now.

After the victory, this mission suggests pressing escape, etc... but there are WPs leading to the home base and I generally like practising my landings. My historic notes suggest that Gudauta default landing RWY is 33 - which would match the direction from WP 3 to the airfield in this picture from the mission: Strangely, even though the weak ground wind (red arrow) seems to match the 33 RWY, the ATC sends you all the way around for the RWY 15 (green arrow). To fix this, a minute change in the ME would be sufficient, just change the ground wind from 2 to 3 m/s. Before hurrying to "fix" my notes about default Gudauta RWY, I tried the same mission with 0 m/s for all the wind levels - and funny enough, it suggested RWY 33 as well. Why RWY 15 is suggested in the particular conditions for the mission is beyond my understanding. Is it some kind of more generic wind-ATC interaction bug or what?

I was just really surprised how my landing got so much better with all the other planes I've flown before circling back to Su-25T. I can't imagine how bad my landings were before, because now even when I scowl at my Su-25T landings or try something really crazy (which I would not as in real life for sure - but that's also why we sim ;-)) my tyres are intact. Sure, I haven't tried to break them on purpose. Funny how time goes... sometimes I thought it super hard to NOT blow them up. Now it's kinda hard to do so. Thanks for the response.

I was trying this mission for a few days and when I finally survived for long enough it often ended in a strange way - soon after the enemy coming within 3000 m to the defended village, the mission ended with failure. I decided to investigate. This is the "Loss" zone: It seems it is used properly in the trigger: Yet, the mission ends like this: And no, no other unit, just recently destroyed, was that far ahead to reach the trigger zone. I saved the track, but it doesn't replay properly. But I made a video of the final less than two minutes, that starts with a glance on the map - and there is no way the units would get that far within less than two minutes. So some ahead unit could have been destroyed, but it wasn't in the trigger: Also, this seems to happen in this very sequence - a group is destroyed and the failure message comes too. I have no clue what happens from the look in the ME. If I manage to get it the next time, I'll try to save the track again.

I've returned to Su-25T for a few missions recently and I was quite surprised that I've had ZERO tyre blowouts so far. Sure, I'm landing better than back in the early days, but I've landed a few times with "there goes my tyre again!" only to find out all the tyres are intact. Is it just me or are they more solid now?

I've been wandering the same thing for well over a year... for Su-25 and Su-25T. There seems to be no lever on a stick, is it using pedals (two axes)? But even one axis would be much better than now, I constantly need to remind myself "this plane has no brake axis!" and use a different button than for all other FC3 planes.

This may depend on the plane, textures of the elements, particular settings, etc. An example is in this video (DLSS+DLAA). And it may get better with DCS updates, I don't know.

Sorry for not being clear - rotary elements in the cockpit like rheostats, knobs, etc. Complicated textures moving quickly.

In my case, DLAA introduced a lot of blur for rotary elements and textures and perhaps a bit of ghosting, but DLSS added much more. When I looked outside in a mission with gates (I know, who cares about gates!) and looked around, the gates ghosted like crazy. Without DLSS (DLAA only), this type of ghosting went away. But then, perhaps we all see different things with different cards, etc. I don't know. It's no silver bullet for sure.

I also ended with DLAA only. There is no comparison with MSAA in quality, but the performance is better, so I bit the bullet. DLSS ghosts like crazy, various scenarios, external views with contrasty things especially, I decided to avoid it. I don't understand why it does ghost though, I thought it was used for upscaling and not for frame generation - but there is little to no control (only on/off) for it, so I don't know. DLAA is bearable and a reasonable compromise for better performance. (RTX 3060 here, so that may be a factor too.)

Whow, nearly posted the same report... so the current behavior with NOT white tanks is correct, just the voiceover is obsolete now? I also noticed how overblown the red lights are - is that correct as well? This is the Mercury LLTV: Ingore (1) (that's a now-not-white tank), but (2) is caused by this: Should we consider this a non-buggy current version of Mercury pod?

There is perhaps another problem with the original voiceover and new mission version - there is just ONE (not "two") additional target - although comprised of three HEMMT trucks. BTW: This doesn't mean the updates to this particular mission are bad, the older version with hard armour was quite difficult. Even now the pods are mostly useless against M113 APCs (the internal gun is much better), but they are great for those HEMMTs. Considering that all HEMMTs can be destroyed in one pass, we can easily have two groups (two targets) as well. Marked with green smoke, that is.

After hitting the first targets, marked with red smoke, the voiceover mentions new targets marked with green smoke. There surely was one before, but now it isn't: It is not only the mirror problem, the same can be confirmed by the direct view, I just liked the voiceover + mirror image here.

After more than three months of playing with STECS Standard, I decided to make my video review of the unit: Long story short, I like it a lot. But there are still things I don't like (grip encoders mainly), although nothing is a deal-breaker for me. I'm happy for this upgrade from TWCS.

If any time modification is available in F-14 (I don't have the module, so I don't know), let's try to ignore it and use the one in the UI layer instead: In UI layer, you can find the "time" actions: These should work in all the modules.

Man, thanks, I didn't expect this answer. As a programmer, I understood the first and second paragraphs, although googling for DCS acceptDecimalPoint didn't provide any handy pointers (yet) and grep showed the option is used in various places (dll/dlg file, nothing in Config though) but from the look at it not related to this dialog. So my simple question - where exactly should I adjust this option? In/Out using a function that many other things rely on... pitty, but I can understand it will not be changed, although currently the output is very coarse (and I suspect it is floored, but not sure about it). The info about AB is a bit over my head (yet). I'm fine with current options, just not with the lack of precision. And the info about curvature supporting more "rows" - that's cool. But that asks even more for more precision for the values as well. But as "more keys" are available in the config only, I can enter the precise values there. User curves are not my main concern (but it may be for others). But curvature with more precision would be cool. Thanks for all the info... I'm going to further process it now.

Currently, we can only enter whole numbers (0-100) for the Deadzone, Saturation X/Y and Curvature - and also, only whole numbers are shown in In/Out fields. This is sometimes too coarse, for instance when matching the AB detent with Curvature (Deadzone/Saturation is probably OK, but there is no reason to not allow it there as well). The internal values are decimals in 0-1.0 range, the precision can be much higher, it is probably not necessary to allow any/max number of decimals, but two - or even the single one - would add tons of precision to this kind of setup. The same would be also great for user curves, of course: Here the difference of 1 is often very coarse on some ends of the curve. Currently we have to go to Lua files for any more precision. As you already work with decimals in the config info anyway (x100), it would be great if UI allows for decimals as well. Thanks.

FAQs are that long for a few reasons - this one being one of them. A note about the different Trial version should be also clearly visible on the shopping page. Trialable non-sellable module (as it appears on the shop now) would be probably more understandable. Otherwise, it will always be confusing when Normandy 1944 is the name of the module we download for a trial. I'm not sure this is good for Ugra Media either, I hope you'll manage to come to a less confusing setup. Best luck and thanks for your patience.

When I wrote "lies", I meant it technically, I know there is no bad intention. Perhaps it's all part of the confusion - there are three versions: The old Normandy 1944 The new Normandy 2.0 (which is not trialable at this moment) And then the updated version - how is this one called? "Free Normandy 2.0 update"? I always assumed that the modernized Normandy 1944 is still called Normandy 1944, it's just the upgraded/updated version of it. I looked at the FAQs and the map shown there, and it is very hard to assume that Normandy 2.0 can mean "modernized Normandy 1944". I eventually learned (on this thread) what version of the map I trialled - but is that the map you want to (also) call Normandy 2.0? Perhaps I'm not clear, but what should I write under the screenshot of low-res Paris? "Normandy 2.0 trial"? We can be descriptive here, but that version should have a clear and distinctive name. Also, isn't it a bad precedent that the trial and full product may be different? If the updated version of Normandy 1944 (which is what I see in the game) is used for trial, let only that one be trialable. Disable trial from Normandy 2.0 in the shop. Compare the following scenarios: I trial Normandy 2.0. Shop says it's Normandy 2.0 on trial. DCS downloads Normandy 1944 anyway (which I consider just a naming problem). And I see the upgraded Normandy 1944. Confusion. I can't trial Normandy 2.0. I trial Normandy 1944. The shop clearly says it's Normandy 1944 on trial, Normandy 2.0 doesn't offer the button and doesn't show confusing Trial info. I download Normandy 1944. Yes, it is the upgraded version, but not the "true" 2.0. No confusion. Sorry, if it seems like pushing it, but I didn't start this thread, many people had the problem. The name must be totally clear. It would be best to stop using Normandy 2.0 with whatever adjective for the upgraded Normandy 1944. Of course, we appreciate the upgrade, but isn't it still Normandy 1944? Didn't all the users of Normandy 1944 get it? If yes, then it's just the most recent of Normandy 1944 - or not? EDIT: When it comes to Normandy 1944 "upgraded" and "updated" conflate, as it is a free upgrade, it acts as any other update of a module. Correct me if I'm wrong.

Hi @BIGNEWY, thanks for looking into it. I thought the question of whether Normandy 2.0 should be trialable was resolved a long time ago, that's how I also read your answers in this thread from May 2023. Of course, I have no problem with whatever decision. Not-trialable Normandy 2.0 is fine with me too, but this should have been decided at the release time. However, the communication around it should be clear to avoid confusion, no Trial for the map should be offered in the shop. The current state of affairs is very unfortunate. Now I know what I know, but when I first saw Paris in "Normandy 2" I was underwhelmed and thought the problem is on my end (graphics settings, etc.). Also the info in the shop must be clear, currently, the two versions of Normandy are somehow connected (when I trial one, I also trial the other one). I guess the duality is because you want users with 1944 version to upgrade to 2.0 version, not to have them as separate products. But the result is that the shop "lies" to me when it clearly states I'm trialling 2.0. When you introduced Black Shark 3, it was clear that BS2 was trialable and BS3 was not, there were no problems. I hope when you figure out the Normandy problem you will avoid it in future product upgrades and their trials. Trials are a great thing, thanks for those, not sure what data you have, but in my personal experience they often lead to purchases.

Hi @BIGNEWY... still no answer from the team?