FusRoPotato

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.

It's bugged. It's not possible for it to turn more than 60 degrees to the right, but it can turn 120. Once Petro searches near those limits, it's new lefthand limit is zero degrees and righthand is 120, instead of the range being -60 to +60. This is physically impossible because it's a simple mirror resting in a gimbal inside a housing of which the doors open to a -60 to +60 view. You can't physically aim it further than that. All you have to do to reproduce this bug is to very very slowly and gently yaw the helicopter while flat, level, and Petro is looking at a point that is more than 60 degrees to either the left or right. Even if you have him look too far left, the bug will permanently shift the entire sight 60 degrees to the right. Don't roll. It has nothing to do with roll. You can't move the sight like Petrovich can. This is a well-known controls limitation everyone who flies this module is well familiar with. It's simply too slow and based on inadequate controls translation. There is no visual reference to show what you can feel on the wheel, nor any quick way to slew it around, much like trim wheels on a P-51. I'd imagine you could use it just fine so long as your pilot is in a perfect hover and gives you five minutes to deal with it. Otherwise, you are starting to look habitually dishonest.

The reason is because of something called a safety factor. Just because it's against a rule or regulation due to safety doesn't mean the dangerous outcome is guaranteed to happen when you do it anyways. Perfect example of this is G limits and crack propagation. If you can't prove for a fact that an engine will stall every time a rocket is fired, or have a credible and definitive reference and proof such outcome is expected based on numerous case reports, research, and CFD, but instead base that assumption on rules, regulations, and secondhand stories, you are making an assumption. There's video of it. Definitely not an S-8. That's not documented and was obviously something much much larger.

Why was something that came up as a rare possibility turned into a guaranteed happens every time issue? Maybe the effect possibility is correct, but are its chances correct? By the descriptions I'm seeing, sounds overdone. Not like that kind of thing has never happened before around here.

null Not only is there another issue where the sight bugs out and can't move correctly because it somehow turns itself backwards, but in almost every encounter with ground units I come across, he cannot see them in plain view unless I hover there for 4-5 minutes. I'm sorry but this sight and AI needs a professional rework. Human gunner can't move the sight easily and Petro is blind.

How come when certain weapons are not compatible on other modules, the incompatible item is removed when the other is installed, but this module you can just equip whatever you want wherever you want? Like, how does one go through all the trouble of figuring out what can work with what, but not lay a finger on the loadout menu?

I was able to replicate this issue without any ships or TACANs present. All land/sea-based friendly units appear to cause disappearance from FOW so long as they are within detection range of the enemy. I can place a group of enemies down with a drone overhead. It will see everything. As soon as I command a friendly HUMV or APC to drive up, poof. LOS doesn't appear to matter. I can even get the enemies to disappear from the map by running an infantry up, so long as it can survive from building cover and get close enough.

They probably should allow using MSAA, FXAA, or nothing with the other upscalers. Those types of AA are a little more costly in performance, but they don't render the game unplayable and still offer performance gains over native without the blurryness of the lesser resolution. Games with small and fast-moving dots and objects just don't work with TAA. Also, I'm very surprised that after DLSS and FSR were implemented, that there still is no option to run basic upscaling. You know, that feature 95% of all games offer? With my old card, I had to decrease my windows resolution to 1080p, or, run the game fullscreen, because there was no basic upscaling for a window. Fun fact, if you run the game in windowed mode and change your desktop back and forth between 1080p and 1440p, the game will get stuck with a 1440p sized window running at 1080p render resolution. You can literally bug the game to offer this feature, but it's not an option?

Nothing in event viewer. That's not surprising considering it's hitting a breakpoint.

The log files have not been useful. None of them ever show a crash or hints because the process isn't actually crashing. I posted one log file as a demonstration. As I described, the log file just stops. It stops because the process is hitting a breakpoint. What should be very telling is what the dumps say. It's hitting a breakpoint. What and where is the breakpoint and why is it enabled? If I can find that out, maybe I can find a better method of replicating the problem if the problem is not obvious, but I suspect it will be obvious to someone who can see the source. crashLogs.zip

There is a problem that has existed for a long while now across many aircraft and systems in DCS. I've often just shrugged this issue off, but after installing a new video card today, I noticed the problem is slightly more pronounced. Problem: When slewing, whether it be on an F-16 TPOD, Radar cursor, FC3 Mig/Flanker Radar, A10A Mavericks, Frogfoot or Ka-50 Shkval, many of the sim's systems will lag, hitch or suddenly speed up or slow down making it difficult to control the position. Meanwhile, there are many other systems that seem unaffected, such as the TADS/PNVS, Hornet Tpods, or numerous other screens. When holding the controller axis in a position as still as possible, such as full deflection, the motion tends to lose its hitching and erratic behavior and move smoothly. The issue mostly seems to occur when the axis itself is changing position or another axis affecting the slew begins to change. When this change occurs, the motion seems to nearly double in speed briefly. The problem seems to be worse when using atypical refresh rates and varying styles of vsync. My monitor currently runs at 120 hz, but I have other monitors running at 60. This may be the problem. Deadzones and curves have no effect on the behavior. Hardware: This may or may not be relevant because I don't know how the game itself captures input and translates it into each systems movement. My primary controllers are two VKB Gladiator NXT EVOs. In addition to those, I've tried mapping such controls to a PS3 controller instead with the same results, and also attempted some testing through Vjoy and freePIE just out of curiosity if it could be a resolution or polling rate related issue. It doesn't seem to matter Previously I was using a GTX1080 and now I am using a 7900XTX. In both cases, I was getting 120 fps, my monitors max refresh. The only difference being a massive change in visual quality and resolution. My sticks were recently flashed and updated. I am running windows 10 that is also updated. I have verified that my stick signals are clean and have also tried passing them through vjoy with additional filtering and granularity enhancements to be certain. Assumptions: Since there is no change in framerate, I suspect a frame time measurement conflict or error. If any prediction or assumptions are made about controller positions that are based on frame time, that might cause the issue. It's almost as if an 'axis position rate' times 'frame time' is added to the control motion to hide latency, or perhaps some kind of general output motion scaling based on the time between frames. The result I see is very much like that of such system that has the frame time incorrectly measured. This measurement error seems to occur most when the axis value is changing. Through something entirely unrelated, I had run into a similar mistake of my own because I didn't regulate or dampen thread timing. I had a system that was jumping between about 64 and 666 hz causing a feedback loop to explode, because windows was attempting to do some low energy shenanigans. Perhaps the game suddenly thinks the frame time is 16.6ms when the axis as recently changed value, then reverts to 8.3ms once held still (the frame time the game is being drawn at). I don't know if this would need a track. One could just instant action a F-16 or Ka-50 and slew things around. This might require multi monitors at different refresh rates, or have something to do with AMD refresh rate stuff. AMD is new to me but I'm flicking switches trying to see if anything helps fix it.

We've had a rare and random crash on our server for several months now concerning a breakpoint in edterrain4.dll. When the server crashes, all AI freezes in place, but players can still talk, shoot missiles, crash, die, eject, and pop flares, but to other players, they appear frozen in place, along with any missile they fire off. Part of the simulation is freezing while others continue. It is not mission, map, codebase, or hardware dependent. All have been ruled out by diversifying as much as possible and will still crash in completely vanilla environment. We've seen this on a 32 gig AMD server from Europe, and also a 64 gig intel server in New York. We don't own every terrain but it has crashed on Caucasus, Syria, the Channel, Persia, and Marianas. Seems completely random. It can crash after 45 minutes of running, or run for two weeks without a single crash. Unfortunately, I have not been able to figure out how to force the crash, nor determine if the presence of anything in particular causes it to be more or less likely. Luckily, it gives a very straight forward clue. It's a breakpoint in edterrain4.dll. The server logs never show a clue unfortunately. I've tried placing debug messages before spawning units, on the deaths of units, and some player activities, but nothing ever comes of it. I only included one log file because there's no point looking through them. dmpLogs.zip

The sight gets stuck with a new forward orientation about 60 degrees right, such that full left on the sights limits is straight forward relative to the helicopter and full right allows the sight to see 120 degrees right, which is physically impossible. How to reproduce (and this has to be exact) Command Petrovich to look forward and search a location. Yaw the helicopter either 90 degrees left or right gently while keeping the helicopter flat and level. Turn the helicopter back to face the commanded location. Regardless of your choice in turning left or right, the sight now gimbals between 0 and 120 degrees to the right instead of -60 to +60. The sight can no longer look left. I can reproduce this 100% of the time and doesn't seem to require any loadout or depend on cold/hot start. Can't find a fix or workaround. Somehow the default orientation is taking a new value. There is a second bug I found that when going in and out of the sight manually, headtracking sometimes gets stuck off. I don't know exactly how to reproduce this as it seems random, but an easy workaround is to just go back in and out of the sight again.