Nealius

Hopefully this will get resolved with further updates. My 4070TI Super with 16GB can't run the Apache in VR without overloading VRAM and causing headset artificacting. It's easily resolved by setting textures to medium, but needing more than 12GB of VRAM in a card is just rediculous and needs optimization. There is absolutely no need for such large texture sizes.

If "stepping on toes" (other map has this area) is considered a valid excuse, then Normandy 2.0 and Channel would have sections deleted as well.

Why model the uncommon when everything else models the common? The goal posts are being moved so much to fit what's convenient that a wishlist item seems pointless as well, if the arguments for not being consistent across all modules are going to be so arbritary.

Shouldn't these self-correct over time when flying straight and level? The old analog ones in the warbirds should, but in DCS they don't, which IIRC there's a bug report out on those.

For other ED modules, as well as previous changes to the A-10's FM and GAU-8 performance, SME testimony is considered "hard facts". Why is different logic being applied here?

In addition to what Gierasimov asked, tracer ammunition is not commonly used in modern US jets. SAPHEI (no tracers) would be a typical combat load. The only two exceptions I can think of are the Tomcat and Eagle variants, which have/had red tracers.

Good news is I figured out the comms issue: If you spawn on ramps November, Oscar, Sierra, Yankee, or Zulu, the comms tree defaults to the heliport as the F1 entry. Voice Attack profiles are programmed to press F1 as that should always be your spawn airfield.

With the amount of terrain detail bottlenecked by how fast you can stream internet? Even MSFS couldn't get that to an acceptable level, and they're orders of magnitude larger than ED. No thanks.

IIRC the A-7 was the first to have a CCIP as we know it today.

Appears to be a "hitbox" issue. The hitbox for the heliport is in red, airfield in blue. The heliport hitbox is prioritized over the airfield hitbox, and covers a majority of the airfield. This hitbox does not exist on the F10 map. This is also affecting radio usage, as spawning anywhere on the ramp within the red circle results in being unable to contact ATC on 360.20, while spawning outside the red circle works fine.

That seems to be part of the problem. Clicking on Kandahar (TACAN area) causes the heliport info to pop up instead of the airfield info. In the F10 map they're properly separated.

In the ME Kandahar's UHF is listed as 300.20, which does not function. F10 map info and functioning UHF is 360.20. Updated title; Clicking on Kandahar airfield in the ME shows heliport info. Clicking on the airfield in F10 map shows airfield info as it should.

It's still decoupled in-mission as well. Last night I flew in/out of Kandahar with winds set 2kts across the board and the Viper DED never showed higher than 3kts between 3400ft and FL200.

33, 1600, and 6600 were all at 2kts (using the decoupling mod for 1600 winds to not double), 26000 was 7kts. 9kts shouldn't have even been possible given the highest value was 7kts, and with Kandahar at 3500 it should have been well within the 2kts between 33 and 6600.

Maybe if it was a ghost. No AI traffic. Whatever it is, it's probably going to be as elusive as that old A-10 pitching on final bug.

Iran and the PG area does.

Crowd-sourcing info here, but after 1+hr flights in the Viper on Afghanistan, has anyone come across a really weird crosswind when landing at Kandahar 23? With mission wind set 100° (TO not FROM) 2kts, the DED wind page read a wind that shifted 270~330 up to 9 knots as I was descending on glideslope on runway 23, but I can't reproduce it in short test missions. That wind wasn't there when I took off. It's really weird. Has anyone else experienced the same?

I used to use "dot only" labels with the distances tweaked so that they only changed color within 2nm or so for VID in VR to be more realistic, however it seems "dot only" has changed to "dot neutral" and the label color does not change. "Symbol only" does work, however it doesn't seem possible to edit the symbol/position/color/range because such a "symbol only" entry does not even exist in the labels.lua file. Is there any way to get this capability back? Or edit the distance at which the "symbol only" label changes color?

My experience has been that AI-deployed flares are vastly more effective than player-deployed flares.

The yaw string is more accurate than the ball. The ball doesn't show actual slip until it's settled down from Newton's 3 forces acting upon it. E.g., bank to the left and you will see the ball swing right (indicating proverse yaw) while the nose reference and yaw string are still straight as an arrow.

Bug caused by the new launcher, it seems. I disabled the launcher and everything's been good so far.

You can see similar problems with the nomenclature used in the controls list. ED seems to prioritize the official terminology per the manual or other resources related to that item or module, to the detriment of the end user which needs more standardization for ease of use.

Wing fires on the B-17 is odd considering the self-sealing fuel tanks. I've removed one from a B-17 wing myself (well, me and like 8 other people because it's heavy af).

Yeah, I'm gonna pass on breaking all those user-made skins for a rudder animation fix that's hardly noticeable. We can't make a single coherent deck without the user-made skins; and half the default skins are for carriers we don't even have in DCS. This isn't MSFS where players just put around alone without the bigger picture of simulating military operations involving multiple aircraft.

There are also various roads that have breaks in them: And the road that should be going through the valley west of Tarinkot ends at a village.