FusRoPotato

The Mig21 AI has been demonstrated numerous times on tacview to have super climb and maneuvering capabilities far beyond one that is human controlled. They can punch through a vertical straight into space if they want. Unlikely you will outrate them in all settings, but if you learn their behavior triggers, you can break their super rate abilities, but this is completely a simple-AI flight model problem and doesn't mean the F-16 is underperforming.

wow, NICE! ...Verified

I haven't given it another whorl yet, but I can vouch for a few friends I've seen CTD while dying in them.

Mods\aircraft\F-16C\FM\config.lua still has inertia values assigned to the incorrect axis that result in F16 having a pitch response that poorly matches public data. center_of_mass = {-1.4, -0.069, 0.0}, --x,y,z moment_of_inertia = { 12875.0, 85552.0, 75674.0, -1331.0},--Ix,Iy,Iz,Ixy -- Ix(roll) = 9496, Iy(pitch) = 55814, Iz(yaw) = 63100 [slug-ft2] --moment_of_inertia = { 4610.0, 48882.0, 52678.0, 0.0},--Ix,Iy,Iz,Ixy line 37 shows 85552.0 as Iy and 75674 as Iz. These two numbers need to be switched. Iz for American planes is the (positive-down) (positive-right-yaw) axis and Iy is (positive-right-wing) (positive-up-pitch) axis, but in Russia, the standard orientation is Z is (positive-left-wing) (negative-up-pitch) and Y is (positive-up) (negative-right-yaw). This is a data entry mistake as the values are correct, but their position in the table is not. Moments of inertia are found on pg 43 19800005879.pdf (nasa.gov) @DummyCatz Line 37 should read: moment_of_inertia = { 12875.0, 75674.0, 85552.0, -1331.0}, The correlation between table index and affected axis have been verified in this video:

The Mig29 has a lower *PEAK* thrust to weight ratio. A lot of people don't realize that the F16 is super dramatically dependent on already being up to speed to produce that peak thrust, about 6x more than static. The Mig29 engines are quite a bit more powerful in static conditions, but don't scale in thrust with speed as well. This makes them better at building energy and can easily escape an F-16

why

Options are usually always good. Why force some to be annoyed? If anyone knows how to read controller axis directly through lua, let me know. I'll do a sweep and post graphs. Also, why do these threads keep being marked correct, even when it's stated that changes are coming?

I feel like this is a broader problem in where the interpretation of what a control input should be, translating from a spring stick to either a force stick, collective, or cyclic, has limited to no customization in where the deadzones, latencies, filters, or even to what extent various types of feedback loops are available. I think it should be understood as a developer that how an aircraft moves affects the body and mind, something we don't get in our race gaming chairs. Our body physically reacts, not just by mental reflex, but by stress and the physical inertia of our arms as well. The only way to get around that is to offer those tools and access to all the gains, filters, and gain scalars(Reynolds#) for every aircraft. This is probably why there are zero instances of an F-14 ever having its wings ripped off in RL despite it being such a frequent occurrence in DCS, or why so many people wobble around in their choppers. They can't feel what is happening and their sticks aren't centered on neutral force. Currently I can fly around a helicopter and if I let go of the stick at high speed, the helicopter will just explode because my stick returns control to an exact center cyclic position rather than the neutral force position. The only way around this we've been given is by spamming a very distracting force trim button that's not realistic and that can also cause major accidents. A feedback loop and neutral force mapping would have been way better. I suppose it might be possible to implement custom feedback responses if there were some way to access control stick input through that export.lua since I can force a stick output position with the 2001 command, but I haven't found a reference for direct controller inputs yet. I don't know if what I'm seeing in the F-16 is a dead zone in position. It rather feels like a deadzone in small motion changes, as if the movement is simply filtered out or the feedback loop is dominating input at those small values. I could make more graphs of different input levels and durations if anyone is curious. Check again those graphs I posted and look closely at the F16. There is an 80 ms delay in reaction after an instantaneous change of input compared to what looks like 10 ms for the tomcat, but 10 ms makes sense because that's the framerate the script is running at. It's probably simply instant.

Got a little bored today and performed a little experiment. Set up an export.lua to allow for two things: Record pitch response data Enforce a strict timed impulse of perfect control input using LoSetCommand(2001, input) I performed this by hijacking a button in the F16, the radar emission switch (why not). I begin with a hot airstart and have the export.lua programmed to detect when I turn the radar to quiet mode. Once in quiet, it holds pitch input steady at 0 for 1 second, kicks it up to 1 for 200 ms, then back down to 0 again while recording the pitch rate using LoGetAngularVelocity(). I did this for speeds starting around 200 and going up to 500 in increments of 50 while at 4kft no stores, then repeated the process again for an F-14, only this time using the missile step button as a trigger (why not lol). I can share the export file I used that shows how this is accomplished if anyone wants to repeat or expand on the idea, but digging through lua files to find the argument ID for the stick position and some random trigger switch can be a challenge. Here is what I found: First graph is what the response looks like very close up in the span of 100 milliseconds: 2nd is zoomed out to 2 seconds after impulse: 3rd has all the speeds (longer wave is slower speed) just for the F14 shown next to the impulse control input (black line). 4th is the F16, same idea Interesting to notice more of a delay in the 16 on response by about 80 millis, that and it appears overdamped vs the cat's underdamped response. I will have to do more digging to see if I can find any specifics on damping factors, but it looks like the 16 got hit with a basic PID which I don't think is correct. I have to double check. If anyone wants to continue this, here's a miz and export.lua. You will have to modify it to your own log file path of course and change some of the argument IDs based on which plane you fly, but I noted the numbers you need for the 16 and 14...ExportFMTEST.zip

There is no joystick calibration trick that can make up for latency or rotational inertia problems.

The curve has no effect on response time. All it does it increase/decrease demand based on stick position.

IRL it's based on contrasting pixels, but not in DCS. The Mavericks ability to lock in DCS are only based on 3 things: temperature (D), time of day (H), and range. So long as the target falls within the constraints set for each type, they will be allowed to snap to it and lock. If they snap, they snap to a radius on the closest layer. The bug is that the radius for buildings can be many times larger than the building itself, so if the building is closer to the maverick than the target, it can cause the maverick to snap to the building even if said building is not even shown on the MFD. Usually, this is major problem for any buildings that are long and skinny such as those at airfields, but the rules are not consistent. To fix this bug, a tech needs to discover what sets the radius and put some constraints on it. This radius is probably calculated by the maverick missile files themselves. This should be fine because nobody has ever needed to lock onto the corner of a building in DCS. Just constrain the radius and it will be fixed well enough.

The only real issue I've been seeing on the 16 is the sluggish control response. Other than that, the popular dogfighting expectations of this aircraft are usually far overblown. It's measured CL/CD per alpha is shallow and wing loading much higher than a lot of other fighters. I think the more obvious issue is when other aircraft in this game *COFFM2000COFHFGH** don't have nearly the drag they are supposed to at low speeds and high alpha.

Has this issue come back for anyone? I've been seeing this happen a LOT lately, however not with elevated launches, just level-flight at ~20k on targets 50nm away. They just go straight up and backwards.

My group has been trying to hunt down a crash with unknown cause since the MT update came out a few weeks ago. We have no crash dumps, no clue in full debug log files, and nothing in events, but eventually a server always crashes at some random point in time. It can happen after 30 minutes, or as long as 4 hours later. We have several machines across the world over different providers and different hardware. All were working fine up until the update. We've tried both elimination of components one by one, including the most basic of missions possible, to the extreme other direction of using the most stressful missions possible to try and get any hint whatsoever of what's causing it, but have not been able to strike a correlation with anything. We've tried: Massive respawn rate and destruction of ground and air units. Massive Sam Site count radar stress Mass movement of units, 250+ units choosing random paths until CPU is nearly maxed. Huge furballs with dozens of AI dogfighting Large amount of clients Zero clients with unpaused mission Empty missions without scripts Old weather system Different maps, Caucasus, Marianas, Syria, Normandy, no difference And no correlation. The server crashes at a random time within 4 hours regardless. There is no apparent jump or increase of ram usage during the crash, noticeable changes in fps, network, or disk usage prior, it just simply stops as if hitting an inf loop somewhere. Wondering if anyone else has run into this?

This bug still exists many many updates later. Would like it looked at please. It highly restricts loadout diversity and just about eliminates the possibility of night-time squad illumination and smoke spotting because I am forced to drop all bombs before using rockets. DarkMatter_Caucasus_SandboxPvE_Endless_0.3-20230403-231350.trk

@BIGNEWY I'm trying to take the quality of this product seriously, but you locked the thread and renamed it? Why are you marking things correct if you don't even know what correct is, and instead of reading the thread or testing the complaint, editing my post so you don't have to? There are just two numbers backwards, numbers that would show obvious error in a response analysis. I would also advise that the fact his aircraft spazzed so little for what essentially should have been a singularity suggests there's something else wrong with the state space equations. Are you the person actively working on the F-16 Flight model?

TMS down between steps 7 and 8. You're not supposed to have to do that, but you do anyways.

Ok, @janitha2's video proves it because they edited their numbers and were able to get a reaction. When I edited my file and reloaded the game, I don't know why, but it didn't change anything, probably because I edited the file, then closed the game, then reopened it. Either that or I did the wrong file. The Iy is the pitch axis and should be 75,674, but when you change this number in the file to zero, the yaw oscillates. If you change the Iz to zero, which is supposed to be the yaw axis at ~85,552, the pitch oscillates. This proves they are used incorrectly. Yaw axis inertia always has the highest value because it includes both the body length of the aircraft and wingspan. Pitch is only body length, and roll is only wingspan. Sorta... When I saw the values in the table have a different relative order of magnitude compared to the tables commented out, I knew they had to have been flipped by mistake. Thanks again for making that video Janitha2

mods/aircraft/F-16C/FM/config.lua Line 38 Nothing. I've tried making the values super high or small to verify the directions, but they don't seem to affect the aircraft at all. This is why I pose the question, because if this is at all any kind of reference to internally hidden configurations, it indicates a mistake in order that might explain why pitch feels so mushy compared to past versions.

I had been doing some research and calculations of my own as well using basic body frame lift estimations from Roskam. Apparently, the F-16 is physically capable of maintaining a knife edge between ~300-480 kts but will never achieve sustaining it (while naked) on some models because the FLCS does not allow the required and achievable sideslip ranging between 12-18 degrees at those speeds. To minimize the risk of departure at more extreme angles, it is hard limited to 10 by the computer, thus will never sustain one without cheating by rolling a few degrees and stealing some z axis lift. However, the calculations are close, and since I don't have any reference to EZ calcs based on pylon interactions, I suspect that a CFD analysis of an airframe including pylons, or even just a targeting pod, may yield very different results just based on the added body lift at 10 degrees sideslip. I make this assumption because the B and D variants are just barely capable of sustaining knife-edges at 10 degrees into transonic. What are your thoughts on xz-plane lift-forces due to pylons and stores? I'm not sure I can notice whether or not the effect exists in game, but to be fair, I'm not certain I honestly really care because there's no need for knife edges, but it would be a very nice touch. What about these inertia numbers? I titled this post flopping fish because the knife edge wasn't important. The order of y and z Inertia values are flipped in the lua. Maybe it's worth double checking they aren't flipped in the FM as well and not just a typo? I ask for two reasons. One, it's an obvious mistake or typo. Two, I sense this module feels like it has a lot more control latency than others. Excessive y-axis inertia can contribute to that effect, but it could be something else as well. It could even be realistic, but how would you know? Based on the general nature of MILSPECs, it's certainly not a reasonable expectation that any noticeable degree of latency or sloppiness would be acceptable.

This has been the general consensus I have been observing across the internet discussing this module, so when I discovered the opposite to be true, I assumed something was wrong. I do have to trim a lot, but the chopper always has a consistent and expected reaction to stick changes. With the AP on, it often can't decide if it wants to pitch up or down, oscillates, and sometimes go as far attempting to do a loop on its own as soon as I turn it on.

Haven't had a crash yet, many vrs deaths later it seems fixed.

Small update: Making a basic single player mission, I've been able to engage AP without any roll issues. It seems to be almost centered initially and takes very little rotation to correct for level flight. The pitch is still very bouncy when adding slight input, but I'm not sure if it's supposed to be like that or not. Let me know if you want track files on that but I don't think it shows anything important. In multiplayer however, I think I am narrowing in on the roll dial somehow being many many revolutions off.

Just recently got this module so yeah, obvious first thought was that I'm not using or setting something up right, which may be, but I did just watch a cockpit.dll crash of some sort get fixed and my intuition says otherwise so I dunno... Basically, every guide I've seen so far on this helicopter says always turn on the roll/pitch autopilot. It's the little green light all by itself in the middle of the engineering panel. However, when I do this, the pitch spazzes up and down. On top of that, the roll sometimes tries to hunt for a silly bank angle. I've tried special options "autopilot adjustment" ticked and unticked. I've told the engineer to adjust the AP with the autopilot adjust key command. I've tried binding the autopilot adjust to a mini-stick with absolute output to see what'd happen, and also tried binding adjustment keys (without the axis) so that the dials would stay put after rotating them. I cannot figure out what any of this is suppose to do because it seems no matter what, the pitch and roll just want to do whatever they want to do. It's difficult just to fly in a straight line with any of it on. Flying around with the AP disabled however is perfectly fine. This isn't harming my experience much because the chopper flies great without the AP and I could probably completely do without just fine. I'm just wondering, is the stability system supposed to make the chopper more stable? Because it feels quite obvious like it'd doing the opposite. One thing I noticed is that, if I hold down the adjustment key for roll, for a very long time (20 something revolutions), it will eventually flatten out and hold level, but the engineer won't adjust it like that. Also, I can't get my track replays to repeat what I experienced in-game. The helicopters just crash shortly after takeoff . Wondering if it's related to what seems to be an AP malfunction or setting desync related to the crash that got fixed last patch?DarkMatter_Marianas_SandboxPvE_Endless_0.19-20230324-195448.trk DarkMatter_Marianas_SandboxPvE_Endless_0.19-20230324-201929.trk