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.

Sure.

I already answered that question. If I do someone else's job for them, it will save them time. True.

Unfortunately, I haven't been able to find any sources that describe a possible source for it. The signal and servo input runs at a very high frequency of 300hz, which suggest there probably isn't one, but there's no way to know what else it would come from. I've measured it using export lua and commanded input scripting (to avoid any possible issue with physical joystick delays). It floats between 50 and 60 ms when the framerate is locked to 120, while no other aircraft I've recorded shows this including the F-18. It's a small delay that most might not be able to "feel", but some of us can. This is essentially 6 frames of delay at 120, but I haven't done a run yet at 60fps to see what that's like. If it's based on frame count rather than time, it could be much worse for people who have poor frame rates. Being really heavy into estimation and filtering techniques, I'd put my guess on a filtering mistake somewhere in the joystick translation scheme. It may be waiting for a history or 3-4 input ticks before deciding how fast and far the input curve should move. IMO, it would probably be best to undo anything complicated with the stick interpretation and allow something more direct.

I appreciate when assistance is offered in good faith. However, it seems your contribution here, marred by a hint of smugness and insincerity, is more about continuing a past argument from another thread than genuinely helping. Let's keep discussions constructive and focused on the issue at hand, rather than recycling frustrations from other threads. This bug has been reproduced by several others. Thanks for the suggestions, but they are unwarranted.

no need, but thanks for the suggestion.

Of course you couldn't reproduce it. You didn't follow the instructions. You banked, flew with speed, and locked targets.

So you're unable to piece together the specs into a contextual understanding and have never seen one of these devices before, but still scratch for an argument regardless to defend the presence of a few bugs? You have zero sources in agreeance with your interpretation. That sight is just an upside-down periscope that was designed all the way back in the 30's that was adapted to many boats, submarines, and tanks. It is completely mechanical. Sorry but that's just the fact of the matter. There is no physical limit to how fast you can aim it. You've taught yourself this is how it really works by DCS reference, a common mistake, and some book that lacks any technical drawings because it's just another author's loose interpretation.

It says "Rate of slew of stabilized line of sight." You are misinterpreting what that means, likely because you don't understand how old corrective gyro systems work. Pay special attention to this: "Maximum rate of laying of stabilized line of sight" This means the gyro is no longer 'layed' when moving faster than 2.5 degrees per second. It will not be considered 'aiming at a target'. Beyond that, you move it manually, mechanically, as fast as you want, then when moving faster than the stabilized slew rate limits, the gyro can no longer keep up to maintain a stabilized line. Of course, in reality, there is going to be some kind of physical limit that promises damage if zipped fast enough. If you turn the steering wheel of your car fast enough, I'm sure you could break something, but the specs here do not describe such a thing, nor are you ever likely to find such a spec. It's a direct connection and does not limit physical input, literally the same type of device they used on tanks and boats of the time. If you think they had digital or analog joystick feedback loop systems back then, you are grossly overestimating technology of the time. They are very simple and use a gryo to correct, dampen, and stabilize the motion. That correction will have rotational rate limits as shown, but the control input of the mirror will not. Nobody had the tech back then to make such an input scheme responsive and accurate enough. I don't know the exact physical details, but most stuff like that designed prior to the 80's would have been a quad pull-pull cable system because it does the job extremely well. At least in my experience seeing it implemented on tanks, that's typically what was used. What occurs here is something that has occurred many times in DCS. A manual is read, misinterpreted, and thus a system becomes misrepresented, or a failure becomes overrepresented. The recently corrected wing stall myth is a perfect example of that. The way Petro moves it is far more realistic. If you think you're proficient at it, please post some demonstration videos. You'd be the first.

What do you need a track for? I described how to replicate the bug easily. The handles aren't push buttons that limit you to some degrees per second. They are directly connected to the mirror.

Why don't you watch the video linked in the incident you shared and look at the smoke trail? Then go look at videos of an S-8 salvo. An S-8 is not going to engulf an entire helicopter in black smoke.