Vakarian

It's not Retribution/Liberation/Mist/Moose... whatever related. We had a mission in my group the day the Fog patch landed. Mission was made after the patch dropped and had literally this: Dynamic spawns on Wujah and Beirut airfields, 1x SA-8 at Rayak airfield, uncontrolled AI MiG-21s, Su-24s, Mi-8s, few active infantry dudes and 3 static buildings from now in DCS core. No mods, pure 100% vanilla DCS. Some of us still experienced flickering.

Nope. As soon as you introduce delta, the entire flightplan changes. EHSI and the HUD will continue to show nav data to the now offset points because they just show the info how much away is the current point. The system doesn't know that your intention isn't to navigate to the offset points. If you had for example Steerpoint 7 on the threshold of the airfield, before you have done some TGP work and found some targets (it's irrelevant how) and you didn't CZ, when you start flying back to the airfield you will notice that the steerpoint is no longer at the threshold, but the system is guiding you to the offset position of the Steerpoint 7. That is precisely why after every engagement you have where you targeted something (moved the SPI away from the steerpoint/markpoint...), CZ and then try find another target.

Linking for context

I've seen this not only in the Viper but also in Kiowa and in the Apache. On a hunch, it could be the DCS VoIP related thing but I don't have any conclusive evidence to show, only that I've experienced it in multiple modules.

It is an option in the mission editor

Well, you could have lead your first post with this and all would be fine Yeah, I know IRL and Digital worlds do not compare, but I didn't want to see this thread turn into a technical discussion rather keep it in "is there a gameplay / useability value" domain. As we now all agree there is a gameplay value and would be beneficial to have them functional, the more of us agree the better chances of it getting implemented.

Ok, so IRL pilots having visors is just an "accessibility" feature and they don't need it? Do you guys honestly never use visors when playing DCS? It's not about monitors image brightness being too high, it's for when you are flying in DCS, on a sunny day where the sun is almost blinding to the point you can't see HUD. Plop down a visor and you can see better. Did you try that feature on any of the aircraft in DCS that supports it? If you did, can you still argue that there's no benefit of having such visors in DCS? Yes, OP is using his IRL problems to further drive the point, but the root problem is that the visors are not implemented in most of the modules in DCS where they should be and it has an actual gameplay value! I can see stuff in the air way better when having the visor down, however sometimes I have to lift the visor to see the stuff on the ground better as the sun is not in a way there.

You missed the point by a mile. OP just describes, in a very detailed way (nothing wrong with it, better this way as it drives the point more), why the visors are needed for every module, not just a select few. I mean, you have a visor on your 3D model of a pilot, but it's not functional. So "simply" make it functional, that's it. I fully agree with OPs point, I love the visor on the KW, wish the other modules (mostly ED ones) would implement it as well and have it required as the standard.

Are you sure? I'm 99.69% sure not true. I currently use Virpil Rotor collective and I've used both TM Warthog and TWCS throttles as a collective before, in all cases the input was normal axis, not a slider and it registered just fine in full physical range. There was no physical/virtual axes disconnect

From my albeit limited texturing experience, this seems to be the case when the roughmet texture doesn't match so it is then seen with this different background. Different lighting will only make it more/less visible, but the core issue isn't the lighting but the incorrect texture. You can see that one part of the numbers are displayed correctly while the other part (preceding one) does have different background. My guess is that that part is fixed in a texture somewhere and that part needs a touch up to fix.

First post

This looks like something in the rendering pipeline. What could be bad news for us is that if it is, we are likely not going to see the fix until the switch to the Vulkan codebase.

Yesterday we flew a mission in the heavy foggy weather with Light Rain 1 preset, and powerlines always renders weird when their backdrop was fog (and in the distance the sky). When there was fog behind them and a small bit after that was land, they rendered normally. If track's needed, I can make one tonight, but wanted to check if anyone else experienced this as well. EDIT: just to be clear, they looked exactly like in the OPs screenshots

Nice find I'd just like to stress out that is seems like the issue encompasses more things than just weapons, so in my opinion it would be good to run an small internal analysis to see if there are some things that are "not contributing" in the physics calculations.

Well, at least this case is logical to me. Regardless if the bombs are jettisoned or dropped in a CCRP attack, they both behave the same. When dropped from 32000ft, they reach ~780kts (M1.17) on impact. Now, whether this is correct or not, I'm not completely sure but same as before, gut feeling is that this is wrong. I really don't think that the free falling object is capable of accelerating on the way down and reaching M1.0+ speeds near or at ground level. jettisonAndAttackDrop.trk Tacview-20241203-211342-DCS-crashTest.zip.acmi

Yeah, sure. Give me a moment

Bear in mind, I did no calculations prior to see if this is possible or not, but my gut feeling tells me that something is wrong. In this scenario, I've first jettisoned all stores (with a bit of fumbling in the cockpit) So I had fueltanks and Mk-82s being jettisoned. Both objects reached speeds well over Mach 1 before impacting the ground. Drop tanks reached ~900kts (M1.35), Mk-82s reached ~780kts (M1.18) before impact. That seems crazy high. My aircraft after being destroyed (I've also shut down the engine to minimize its impact) first fumbles in the air, maintaining ~180-200kts of speed and then when it turns near vertical with the nose pointing upwards it just starts accelerating without stop, reaching 600+kts before impacting the ground. Attached are tacview file showing the ordnance speeds and a track file in which you can see the aircraft speed before impacting the ground. There's also another track where I've tried to be as fast as possible before getting destroyed. Regardless, when I got shot, aircraft started to tumble and lost a lot of speed (~400kts -> 180kts) but again, as soon as the nose pointed up it started accelerating and impacting the ground at ~680kts. Can someone smarter than me double check this? Is this legit or is something off with the physics? aVeryFastCrash_startSpeedHigh.trk Tacview-20241203-202018-DCS-crashTest.zip.acmi aVeryFastCrash.trk

I mean, you have to account for a thing that I suspect the majority of the community doesn't spend their days on the forums (like some of us do ) so it could be a major reveal to them. Also, when it actually happens then we actually have something to hope for.

Hmmm, it seems it's not just the stores, I've seen on a few times that when I get shot down my wreck ends up smashing at the ground supersonic. It's been a while since I've sat through a physics class in the school, but that doesn't sound plausible. It's almost like the falling object doesn't have any drag whatsoever and just keeps accelerating at the steady pace. I'll spend an evening trying to reproduce this now that I've seen I'm not the only one to observe it

Well, same could be said to you... No need to be so combative all the time https://www.digitalcombatsimulator.com/en/news/changelog/stable/2.9.9.2280/

So, IRL Hornet pilots mention that the FM is good enough and you think it's not realistic. Well, no amount of arguing is going to change your point of view so this entire thread is kinda pointless IMO. This is first and foremost a game. So if you think something is not "good enough", only way to even incite some action is by providing hard proof of what's wrong. So something tangible, like the numbers, charts and if you can use those to prove that things are off, there might be a chance that this gets investigated. Feelings don't mean much, especially if you don't have first hand experience with the said machine. I don't so I take what SMEs tell as granted due to being in no position to argument with them. If it's fine for them, it sure as hell is fine for me too. Also, keep in mind two things. First is that you'll never get 1:1 representation due to the fact that some things have to be extrapolated or "guessed" in order not to fry your CPU whenever you fly and enable somewhat sensible performance. Second thing is, you'll never get 1:1 representation as certain militaries might not like everyone and their brothers having access to the perfect flight model of the aircraft in their inventory by some game for measly ~80 dollars (worst case scenario). Manage expectations...

You seem to be forgetting that in the sim you don't have cues you would get from the real aircraft so you can only react to the visual cues (and be proactive as you should know to expect). That's a reason why it's so much easier to get into the PIO in the sim than it is IRL. You said that you are a IRL pilot so you should be aware of that. On the other hand, as the others have demonstrated here it can be mitigated through a lot of practice. In other words, it's really nothing else than (gaming) skill issue. From all your human sensors, you are reduced to only one when flying in the sim, ofc it's going to be harder.

Cycle the hardpoint power switch, that should fix it

This was introduced many patches ago I know I've been using that for over a year and yeah, it's a really nice thing for quick menu navigation.

You can try to pause and then in the options change the FOV. I've just learned of this possibility few days ago because of the same issue