FusRoPotato

I've not seen any evidence that any hard limit ever existed for any block. I think it's just some nonsense someone made up on a forum somewhere and ED rolled with it. It's certainly not like it'd be the first time...

I can get the menu to show again by hitting com1 PTT, but in order to get it to show again, I have to hit com2 PTT. Basically alternate back and forth to open the comms menu. Weird bug, perhaps there is something wrong in the control commands file like an overlapping definition.

I'm having the same problem and having difficulty figuring it out. The issue is, co-altitude returns at zero elevation appear but then disappear when entering super search. I've been using slow erase while scrunching the bars and azimuth and skipping through half action as fast as possible as a workaround, but I don't know if the game is broken or I'm doing something wrong. What I do know is, I can reproduce it quite often. When in pulse mode, it paints the terrain the same either way, but only the contact disappears as soon as I hit half action.

Sorry I meant to say 10 degrees. This isn't part of AOS feedback function, this is just a made-up hard limit that ED said matches publicly available data. Was it actually limited to 5 degrees in the game?

There might be something to it. I crafted an export.lua test to record pitch changes after forcing a pitch input and found that the game's F-16C doesn't react for 80 ms (10 frames at 120 fps). I did this by programming a loop that detected a certain speed, then slapped the stick with a brief pitch command that returned to zero. I repeated this, I forget maybe 10 times, then compared it to the F-14, which reacts on the very next frame. There's a link to the post with graphs. So it seems that our F-16 isn't as much fly-by-wire as it is fly-by WiFi. This is either intentional, or a filtering mistake of some sort. I don't know why, because the milstd for the time on fbw required much better than that and I don't think this would have passed

5 degrees sideslip is the maximum allowed by the FLCS

The video proves, without any doubt, that the roll applied to the aircraft being flown is receiving the yaw input necessary to hide all apparent adverse yaw. Is it the same F-16 as ours? Was the pilot perfectly using their pedals to achieve the same outcome? Those are valid considerations, but the F-16C did have an ARI tasked to perform this automation. Sometimes there are frequent claims that trickle down from pilots and engineers that have merit but won't have documentation to back it up. You're never going to get source code from your community. I think you should task your team to investigate and not worry if things outside your scope of expertise are valid. It's not what neither you nor your community gets paid for. If you really need convincing, hit up google with F-16 Aileron Rudder interconnect Nasa. You should be able to find a paper or two with example feedback loops that could be implemented directly to achieve the effect widely claimed. There are many open proposals in public. Something of some form made it in, but I don't have permission to share it. I figure your team should be allowed to, and be interested in, implementing their own version of it to mimic the true aircraft.

There's an unexplained control delay and a swapped inertia value that makes a 12% problem. Mix those two together and maybe you get an overshoot that makes bad draggies. I'd have to test to see what happens with a correct value, though there's nothing I can do for the 5-6 frame control delay at 60hz.

If a pilot says its bleeding too fast, but the data vs simulation doesn't, it may indicate a feedback loop problem. He spoke a lot about his controls being sloppy due to his spring, but I don't really know what he meant by that. I assumed his stick is physically sloppy vs a 16 stick. Can it be demonstrated that the ED simulation matches available data specifically for AoA response to pitch demand? If the AoA overextends by even a slight degree, this would result in a major discrepancy that would still fall within energy diagrams, especially if the interpreted focal point region concerns a G limit instead of an AoA limit. I suspect not, because there probably is no such data that validates the AoA, at least I've never seen or heard of such analysis. I can however tell you one possible source of such an occurrence... Moment of Inertia I could set up an experiment that evaluates this and checks for excessive overshoot. It would certainly contribute to excessive bleed if there is any.

Mover made comments on this again today in his videos. Unless you have evidence or proof the huds ran at 20hz, I think you should just change it as suggested. If a 30 hz video shows something moving once every 2 frames, that means it's updating at 15 hz. If it changes once every 6 frames, that means its updating at 5 hz. If it updates on every frame, that means it's at least 30. All you have to do is measure the time span between what is seen as changing and invert it. All hud tapes for F-16's have horizon lines updating every frame at 30hz (because they update at least that fast), and numerical indicators such as velocity update every 4 or 5 hz. Last thing you're going to do by fixing this is piss someone off.

Yeah I've been noticing a lot of unexpected flight characteristics of this plane. I've been so busy lately working on hypersonic stuff that I haven't had a good chance to getting back to this game, but there are definitely some things about the M2000 I'd like to look closer at. For one, hardly any energy loss at high alpha compared to aircraft like the F-16 and F-18, which is not a typical characteristic of delta wings. Delta wings are best known for their ability to carry heavy payloads at high altitude, achieve high AoA's, and perform high altitude interceptions, not low altitude sustained rates. Their CL/CD/alpha drops too fast. Secondly, I'm getting up to 600+ knots in no time, with less than mil power, on the deck, when fully loaded with all the bombs possible, a few magics, and a fuel tank. Acceleration and speed while clean isn't all that crazy, so I'd assume there no drag indices at all for payloads or drag in general is not being calculated properly. There really aught to be a standard for all aircraft in this game to go through some basic low-grade CFD or Roskam estimations to figure out ballpark performance profiles for these aircraft, or at least dig into some university libraries to see if anyone's already done it to test their own algorithms. Just for example, I've come across more than a dozen papers so far estimating the Su-33's sustained turn rates, or have found that their CL/CD's are much much higher than previously known because their vortex interactions are vastly superior to things like the F-16 and F18 lerx. This is also a reason why the Eurofighter and J-20 perform so well at certain attitude commands. Otherwise we have these aircraft that all either overperform or underperform unexpectedly because they are basing their flight model on guesses, warning labels, pretend SMEs, or "official" data that's simply not an honest representation of reality (it happens). They can't even copy inertia values to the right axis...

Replaying the tracks posted in here appears to replicate the issue just fine, but doesn't always crash. Being able to reproduce a crash "sometimes" by repeating identical replays is a very specific kind of clue.

I've had this happen a few times on Marianas. Mouse wheel out far enough and boom, it just gets stuck on full zoom out. Sadly, I can't remember what I did to break out of it. Center on player perhaps? I have a feeling it has something to do with how the mission was saved from the mission maker.

I have seen a number of instances now since I first reported this where the missile does reacquire as expected, so whatever I saw beforehand had to have been a loss of track due to some other reason, or this system does not work properly in every case.

I set up a script that removes junk in a small radius around a group when the group is destroyed. I also set up an f10 option to remove junk from the entire map. So long as a player is nearby units that were recently destroyed (in visual range but not necessarily looking at them), there is a high probability (approx > 80%) that it will cause them all to CTD at the same time, seemingly a random number of seconds later. I have logs from 3 people, including my own. We all have different hardware, but all Nvidia cards. The logs seem to suggest an Nvidia crash, possibly something to do with a 'torch'. Probably a good guess is that not all instances of information are being removed, or that part of the rendering thread is not checking first of those objects still exist. All logs except for the most recent were on the ST version, but MT will crash as well. One thing noticed with the help of Special K is that a lot of these compressed crash zips are getting corrupted and are not being sent. Some of these will have to be opened with 7zip or WinRar as windows will see a corrupt end-of-file. dcs.log-20230422-020327.zip dcs.log-20230422-014239.zip dcs.log-20230423-190200.zipLogs.zip dcs.log-20230422-024133.zip dcs.log-20230422-215333.zip dcs.20230422-215826.zip

There are several of us still experiencing a CTD when dying in the Mi-8.

This could be easily fixed by trading rotational shake with translational shake. Shaking the angle of the viewport just makes the screen unviewable.

I don't mind if the plane shakes, and I don't even care for what reason it does/doesn't, I just don't want the SCREEN to shake. Air may be buffeting my plane and thus buffeting my body, but I've been in plenty of shakey situations in my life that did not buffet my eyeballs. Please, an option to remove screen shake. Plane shake is fine, not screen.

Affirmative. Will work on getting some tracks together, just need some time because I have a lot of work for the next few days.

No, it has lost the track. STT is still active. It should still be transmitting continuously on the same frequency and phase. That's how it recovers a track. If what you are saying were true, these would have always been dumbfire missiles throughout history because momentary track loss is common.

Yes, this is what is experienced and what I think sounds like a bug, however, the patch notes suggest otherwise: "If target tracking fails, synchronization is lost" The problem is that when a lock is maintained, but tracking is briefly lost before the lock is lost, but then reacquired, the missile guidance does not recover. This can happen a lot when maintaining a lock with the assistance of EO, but it is now resulting in a lot of trashed missiles. It would have made more sense that if a lock is completely lost, tracking fails.

If you've never seen a tanker sized aircraft beyond 15 nm, you gonna need some majorly thick glasses bruh. I'd say you shouldn't even be qualified to fly if you can't spot one 60 out, having a general idea where it should be.

I can see the ISS fly overhead at night so kjabsdfkjbaskdjuvhouh, load of bs. Typical distance to spot a fighter jet with 20/20 vision is about 30 nm and I can bold harder than you so don't even.

This should have been a standard improvement long ago. There should never have been a bias for resolution nor any ability to see aircraft more than 40 nm away. This also shouldn't have been sat on and ignored for so long because of its importance. Now we have a shader mod that can be edited, and thanks to MT bugs, we can now see where everyone is, anywhere they are, anytime they are, and at any range. We can now even see when a phoenix is coming at us from 65 nm away the instant it's launched, and without smoke!!! Just mash a few numbers into the file and you have yourself a full fledged ESP. Bignewy and Nineline, I don't think you should notify the team about this. I think you should roll it up and beat them over the head with it.

Documentation? No radar from that era is going to change frequency or phase while continuing to emit its STT unless it has TWS2 capabilities. Unless the radar falls completely out of STT, the missile should recover. It's a major part of why EORL exists. Please elaborate how STT changes phase or frequency mid lock. If the track blips for even just a blink of the eye, the R-27 goes dumb now. There should be no desync when STT is still on. Also, the recent changes don't appear to apply to AI launched missiles.