FusRoPotato

I think you're addressing a different issue than what has been discussed here entirely, as there are different ideas bouncing around that lead the discussion in a different direction. A concern is not just visual lag but the oscillations and difficulties in gradual maneuvers due to the lack of tactile feedback in non-force feedback joysticks. Whether you choose to debate or change it is beside the point (seems like you are choosing to debate it anyways). If the current system feels unrealistic and users are unhappy, it will inevitably be a topic of discussion, potentially becoming heated. Attempts to dismiss these concerns with straw man arguments, appeals to authority, or by conflating them with other issues will only amplify any dissatisfaction. I personally don't feel too bothered by it, but I am seeing a lot of people express frustration about it and I understand why: An attempt was made to simulate force responses into sticks that don't provide force feedback. To make that work, assumptions were made as to how a pilot would react (or not react well) to said forces. In other words, This isn't because of how the stick is modeled, it's because of how the virtual pilot's reaction is or is not assumed. This creates unexpected control inputs leading to oscillations and control annoyances that are much less likely to exist with FFB where that tactile feedback is present. There seems to be an attempt to shift the topic and avoid responsibility in reluctance to engage with these issues or re-frame them as stick modeling. Failure to recognize how much that weakens claims of SME support can render a lot of those statements hard to trust. You are right, it could be easy for many to get used to, but that's aside the point. If flying a sim with precision using FFB is easier than without, there is work to be done with the non-FFB counterpart. Most of your consumers won't have FFB. It is very important to understand this. Things are straight forward and easy once you have all your moments, leverage, and dampening sorted from tail to stick. You just send those forces happily to an FFB stick and you're good to go. However, there is a general practice in MS&T: If the trainee can't sense it, either offer an preventative substitute cue, or inhibit/minimize the effect. I cannot reiterate this strongly enough: The disconnect between a spring-stick PC-sim and an aircraft disallows a certain level of realism, like some of the trim options for Helos in DCS. Things can go very badly for a products image if care isn't taken to respect that disconnect. Some things need to be accounted for or hidden in such a way that usage of a spring stick mimics an aircraft being expertly flown by someone with FFB or realistic recreation of a simpit. Otherwise, you will be expecting a pilot to learn and practice skills that are not typical because that feel can't be translated.

I don't find it difficult either. It's just one of those things that tends to get under people skins after a long time because they know there's no way to compensate for it without FFB. Feel has been scripted to feed back into a device that doesn't offer it.

When you attempt to connect a virtual aircraft to someone sitting behind a computer and spring loaded joystick, there are some disconnects that can't be avoided. In a simulation, the relationship between aircraft and stick may be complex and interesting, but it is not the whole story. There is also a relationship between the pilot and stick that is typically not well modeled in the industry or ignored entirely. Judging by the force options presented, at least someone agrees. For non-FFB/simput users, the lack of physical feedback from the aircraft and the stick itself often causes attempts at realism to become unrealistic. Modeling reactive forces without the ability to mimic the fluid and intuitive reactions of an experienced pilot leads to unexpected faults in control fluidity. This lack of nuanced feedback prevents users from flying the aircraft as smoothly and accurately as intended, diminishing both the realism and enjoyment of the simulation. Adjusting these features to account for the limitations of non-FFB hardware would enhance the overall experience for a broader audience, and may also help reduce the rather large amount of complaints I've been seeing across Discords. Disagree if you want, but I have to completely agree with @kablamoman, realism has been overstepped in an attempt to be realistic. Some things are simply not possible or reasonable with a spring stick. I get the impression someone has taken too much pride in developing the mechanical force complexities of these forces and now intends to try and force it onto people who don't have the necessary hardware. For many, you're only punishing and disappointing them. Will you gaslight or disrespect them as well? A lot of pilots will argue a point until they decide they have better things to do. If you're getting blowback from testers, SMEs, and consumers (which you will get much more of), getting them to submit by argument doesn't fix anything. The fact of the matter is, there is no "feel" in a spring stick. They are watching their aircraft wobble unexpectedly.

I've had this happen a few times and noticed I can fix it by switching between weapons. I haven't figured out what triggers it yet, but it might have something to do with clearing contrast locks. Still trying to focus in on replication. When I've experienced the failure, one thing I double checked was that LST was off. There is something else happening. I've only had it happen twice so the occurrence is rare.

Everyone here has already done far more than necessary. I suggest you kick back and relax. The developers don't need every detail spoon-fed to them like babies, and I don't need to waste my time explaining things to someone who seems more interested in proving bugs don't exist rather than addressing the issues multiple people have experienced and replicated with ease. I've heard similar dismissive remarks before about bugs that eventually got fixed without tracks. Numerous people put significant effort into name calling, shaming, and trying to prove the bug didn't exist because I refused to post a track. It's neither my place nor motivation to volunteer effort that further supports entitlement and passive-aggressive deflection. If you want someone to be nice and cooperative, consider not being rude yourself first and learn how to be a little more sympathetic.

The problem I was experiencing suddenly stopped happening after an update that didn't have any notes on it. I never figured out what the problem was, but it seemed to only last for one version.

Thanks for reminding me of your limitations. I only recently hopped into a Mi-24 to try it because I heard about all the issues it was still having and was immediately able to verify. I am just parroting some of the experiences already shared here that must have shown up for no reason at all. The devs will take it or leave it, and I will invest my time and money accordingly. If the state of the game hangs on your downloading of 30mb track files that don't even record properly, I will let it be.

I've been having trouble getting him to see targets that are on slopes or nearby fences/walls, even if the unit is entirely visible. Thought sometimes units out in the open just can't be seen. I can only imagine that there is some kind of logical offset issue, like the origin of a unit being 1 millimeter underground, but might be compounded with some objects hiding LOS through transparent geometry. Sometimes, he will be able to continue tracking a unit that falls behind a hill while Petro will spam target lost messages. I've also been getting toppled sights for reasons that I don't think are intentional. Just handing off control or going in an out of the sight seems to trigger it going sideways, or he is suddenly pulling a bad maneuver that I am not aware of because there is no visual helper cue to help monitor the pilots orientation. It might be the sudden jerky motion Petro puts into the helicopter when I give him control but I'm not sure. There might be something buggy just with the transition process into and out of the sight causing it because I keep seeing it change orientation. After which, telling him to align the helicopter after that sign seems to have shifted has him fly the helicopter in the wrong direction. I wish there was just an easy way to use the sight and fly the copter at the same time like the Apache. I know being 2 people at once isn't realistic, but neither is Petro being unable to see something with a scope that I can see without, nor his handling in the pilot seat. In real life, we can feel things that we can't feel in a game, not just with orientation and motion, but with force feedback as well. Without such senses, it only makes sense to implement a few helpers here and there that make up for control issues and potential accidents that may result. That might include visual indicators, damped inputs, or input barriers. if you run things raw and ignore those considerations, you might do very well for someone with a sim put and FFB stick, but with a few bugs in related to limits, it's going to make a bad experience for people using basic hardware.

Maybe something was fixed with it because it's not going beyond 60 degrees anymore, but it still exhibits some broken behavior. This is really unfortunate because with an inability to correctly use the sights, we have to rely on Petro, but Petro has his own list of bugs that make him half-the-time unusable for operations requiring his assistance. There is not a single flight that goes by where at least one of these things doesn't happen: Sight Misalignment. It used to be getting stuck an extra +60 degrees right. This may be fixed now, but still gets borked in offset, only now it also includes roll. The only thing I do to replicate the issue is go in and out of the sight and opening and closing the doors while in straight and level flight. It just goes sideways. Petro Crashing the helicopter while in the sights. He can't fly. He wobbles the aircraft, gets into VRS, and will just straight up plow right into mountains. He will sometimes perform maneuvers that are so wild that they break the sight. Not sure if that's supposed to happen, but I have no control over his flailing wacky inflatable pilot arms. We used to have pilot control while in sights, but now we are forced to hand them over. Whether or not the AI piloting can or will be fixed, I'd much prefer to have control back and maybe even a helo-to-sight crosshair alignment helper. He either refuses to align the helicopter with the sight, or the site orientation vector is bugged and he aligns it to a different direction. It's hard to tell, but he often just turns a different direction or ignores the command. Still can't see ground targets that are clearly visible. Sometimes he can see them if I approach from the completely opposite bearing so it might be some kind of entity location clipping, terrain angle, or LOS error, but it would really help if I could take over on days he forgets his glasses. The broken sights are making that very difficult. For now, it seems the Mi-24 is good to use so long as all the targets are out in the open, on flat ground, and I avoid using the gunner seat or allowing Petro to fly. I think there's a huge amount of room for improvement here. Sorry that I did not retest it much sooner. I've been very busy developing some AI projects of my own. This is looking straight ahead on a freshly opened sight while the helicopter is straight and level, just shortly after takeoff. Moments after he crashed into a tree.

I remember this and much preferred the feature. It allowed me to play with the sight while maintaining a specified course vector instead of losing control and crashing, hitting vrs, or just performing a wildly chaotic maneuver. I've been having a real hard time getting Petrovich to see targets I can clearly and easily see from the pilot seat. I was hoping I could just do both tasks simultaneously like with the Apache to work around that bug, but that doesn't seem to be the case anymore. Now, I have to deal with him not only failing to find targets, but failing to properly fly the helicopter as well. I understand it's not realistic to perform two different roles at once, but Petro's AI is sometimes not usable and it was valuable to have a workaround to it, especially when he decides to stop performing alignments properly. There still seems to be a lot of bugs with his AI in general still. I tried playing with that setting but it doesn't appear to matter whether its on or off. It requires handoff either way.

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.