FusRoPotato

Control response (in pitch) has been remeasured due to reported changes on Reddit by @BIGNEWY, this time at 165hz! It appears the response latency in control for the F-16c has been reduced dramatically to a point of imperceptibility in the last update. Changes to pitch rate are seen 2 frames after input at 165 FPS: Also just to avoid not being smart, I recorded a response at 60fps to make sure it was more time based instead of frame based and confirmed the pitch rate responds on the very next frame. The black line is the controller input forced by the command LoSetCommand(2001, 0) and LoSetCommand(2001, 1) while recording pitch rates simultaneously from the export.lua using LoGetAngularVelocity() Also, I can only record pitch or pitch rates AFAIK, not the position of the elevator itself. It is possible the elevator is being moved even sooner before the dynamic model reacts to it.

I've also run into problems where 6 54's on the belly will cycle through 5 but not the 6th until all 5 of the others have been deployed. I've also seen the ARM page bug out after firing AIM-120's from the wing but then and try to select an AIM-120 slot that existed on a previous loadout but doesn't exist for the current loadout because there's a sidewinder in its place instead. When this happens, it puts boxes up in the ARM page like it's ready to launch but there is no missile listed. It makes the rest of the missiles unusable. Possibly this is all related, or maybe not?

I assume you meant "permanent deformation". The wings on these aircraft don't permanently deform without a rupture. They are covered in composite with titanium shear bars, almost entirely 100% elastic profile, no plastic region. It's a material configuration that only cracks and snaps. Go ahead and try to find an F/A-18 bent wing photo online, or even one from an F-15 or F-16. Unless they have bullet holes, they won't exist. It's not how that material works.

Turning on "Global Illumination" appears to have solved the problem.

I've been seeing screen flickering as well, on both ST and MT. It's a rare occurrence, like once every few minutes. Trying to investigate if it's some kind of issue with Vsync or framerates, but it's definitely not a monitor problem as I have 3 of them. Not only does it flicker, but it sometimes shows these weird horizontal static lines about 1/3rd up from the bottom of the screen, like what you might expect in a failing monitor or loose cable. It's most noticeable during dusk and dawn, as you describe, but can still be somewhat seen at night and day. I've tried playing from another monitor, but it does the same thing, and the alternate monitor doesn't have Freesync. Does what I describe sound similar to what you are seeing? I'm using a 7900XTX and haven't seen the anomaly on other games yet.

I'd like to add a suggestion: That final range defined in all .lods files should probably not be interpretable by the LOD setting. In other words, the setting should probably only shift everything else and leave the final entry as it is. Otherwise, it has a dual function of being both LOD scaling and maximum render range as well, while there already exists another setting that controls render range. The advantage of an LOD setting would then not only be that of increasing frame rate but doing so while maintaining the same number of rendered objects.

It's a little different now because it's more than just a mile, which is an improvement, but still within 3 and is more of a problem with reduced LOD settings. With the LOD set low enough, it can be made far more obvious. Either way, Try setting your LOD factor starting with 0.1. I've found it to show a void space for LOD values lower than 0.3, meaning there is a range where there is neither dot nor model. At 0.5, the model will disappear while there is dot beginning to become visible, but it is a sudden an obvious reduction of 90% of the visible pixels. heliViewTest.9.miz Then run this mission file. It is a frozen F-15C looking at a long line of Apache's that get further and further away. options.lua Here is the options.lua, but there shouldn't be anything relevant in here. The cause and fix for the problem is explained here:

When the helicopter is more than 2 miles away, it vanishes. This can be made worse by having a higher FOV than normal or reducing the LOD slider in the options. Even at just 500 meters, it can be made to vanish by setting the slider to 0.3 or less. By then, you can see the Apache as a flying pair of rocket pods. Turn down the slider further and it vanishes completely at close range. This creates a bit of a problem for anyone who might want to PvP against Apache's but doesn't have 20 gigs of Vram. The helicopter might be too far for rendering while too close for dots. I suspect the problem is here: {"ah-64d_bl2_lod5.edm",3000.000000}; in file ah-64d_bl2.lods, because throwing in an extra zero solves the problem. All aircraft have the last LOD range set to 50,000 (including helicopters) with the exception of the C-101, which has it set to 10,000. The Apache is set to 3,000, but it cannot be fixed while passing IC.

This bug is still present btw, and now it is very easily reproducible because you can just move the LOD slider down to 0.2 and watch all nearby Apache's turn into floating rocket pods.

If you're going to throw shade on someone for completely baseless and delusional reasons, that's heat you make for yourself. You're pointing at me telling me I'm the one pointing... lol that's definitely not what's been happening here.

I also described that a track would not be necessary, but despite not being a dev yourself or familiar with the code, you insisted otherwise and wasted your own time trying to make a point. Starting to understand why BN and NL lock threads so quickly.

The only thing crucial is to keep calm and to read carefully. It took you about an hour to waste your own time with something that was warned several times to have already been verified, then proceeded to demonstrate nothing greater than commitment to an entitled hissy fit. If you yaw very slowly to the right, and just gently tickle the right-hand limits, the sight will eventually nap all the way to the right side. This is most likely a simple Euler rotation matrix singularity translation mistake.

Yes, that is a replication of the bug produced exactly in the way it was described, but like I explained, this effort was not necessary. Incorrect. The issue was already reported and replicated. No track or further discussion was necessary. If was people like you who very snarkily continued to insist a track file was needed for something that was not because you have some kind of severe and stubborn egotistical problem preventing you from reading an accepting what was repeated several times over.

No, he's wrong. You can yaw into it very gently, as the original post described very clearly and concisely, and the new limits of FOV will pop 60 degrees to the right.

They have resolved approximately 95% of the issues I've reported, all without requiring tracks. They've even done a few hotfixes for severe bugs I've found and demonstrated on their servers. The only persistent bug they haven't addressed is the one that causes a drop in frame rate when looking backwards in a Harrier Tpod in FLIR mode. Whenever someone reports a bug in my software or any script/mission I've developed for DCS, I usually know precisely where to look and often have a clear idea of the error as soon as it's reported. I generally expect the same level of insight from other software engineers and developers, as this is indicative of proficiency in our field. Consequently, I assume ED devs are this competent because of their high success rate in addressing all that I've reported to them. It's disappointing to see that some participants are more interested in discrediting the existence of this bug due to a lack of a track file, rather than engaging in a constructive discussion. It's evident that this skepticism isn't really about the track file, but rather about supporting a friend's attempt to discredit my report, likely stemming from poor arguments from another thread. I want to clarify that a track file is not always necessary to confirm a bug. This issue has been replicated by several users and is not an isolated case verified by just Redbjorn and I. The description of the bug was precise, detailing a specific sequence of events leading to an undeniable outcome. Using other reports consisting of user error is a poor attempt to undermine this bug report. Engaging in baseless arguments or insults only detracts from our goal of improving the software.