Lidozin

To verify the claim that the AI has 100% situational awareness and no blind spots, there is absolutely no need for advanced flight testing skills. The procedure takes no more than five minutes: simply enter a known blind zone of the AI—one programmed to unconditionally engage any airborne target—and remain there briefly. Then transition into an area where a human pilot would immediately recognize a threat. This is exactly what was done.

In addition to all else, the video demonstrated that a qualitative comparison of energy performance between AI and human pilots (i.e., “who caught up or overtook whom”) can produce highly variable and non-repeatable results — even when the net energy gain at the end of the maneuver differs by no more than ±5%. As previously mentioned, maintaining position in close formation behind an AI lead is inherently problematic due to its constantly varying load factor. For this reason, it is more reasonable to move toward an analytical comparison of energy performance across three configurations: the default SFM, Curly's mod, and a minimal tweak that adjusts thrust at low speeds to match values from the reference documentation. Setting aside the entirely justified reduction in the maximum lift coefficient (CL or Cy, in Soviet notation), which only affects performance in non-steady maneuvers and may actually lead to slightly better energy retention, we can focus purely on the energy characteristics. We begin again with specific energy rate. The graphs show that both mods reduce energy rate at low speeds; however, Curly’s mod grants the AI an unjustified bonus in the 500–800 km/h range, and at altitudes from 0 to 5000 m — precisely where the aircraft is most efficient in gaining energy. These same modifications also lead to a slight overstatement of sustained turn performance. In both cases, the default SFM data remains a closer approximation of the flight characteristics documented in the reference material. Finally, we consider the graph of longitudinal acceleration vs. true airspeed. Unlike video comparisons, this type of plot could more effectively prompt developers to revisit the model data — since it clearly reveals a discrepancy from reference values at low speeds. One particularly interesting detail in the reference documentation is that the airspeed values on the graphs correspond to raw cockpit instrument readings, not corrected for compressibility effects. For example, at 5000 m altitude, a true airspeed of 1044 km/h would correspond to a corrected indicated airspeed of 809 km/h, while the graph shows 830 km/h — exactly matching the uncorrected table value. This means that deviations of the calculated curves from the acceleration graph at high Mach numbers should not be taken as significant. Returning to the observed change in AI behavior — specifically, when it stops climbing slowly at speeds around 350 km/h — this aligns well with the reduction in available thrust at low airspeeds, as reflected in the thrust curves. It is plausible that the AI logic recognizes the diminishing return of continuing such a maneuver and instead opts for a different course of action.

With sincere thanks to Katmandu for kindly providing both the mission and the AI mod data file, I conducted a series of tests using only this mission setup. In these tests, the AI aircraft flew using three configurations in sequence: the default SFM data, the same data but with engine thrust corrected according to the reference curve in the low Mach number region, the data set from Curly’s AI mod. For all cases, the time interval measured was from the moment the aircraft entered a climb by establishing a 1.5g load factor, until it began rapidly decreasing its pitch angle. This time, 58 seconds, was adopted as the reference for both AI and human-piloted aircraft. Since it is virtually impossible for the human pilot to match the AI’s exact initial airspeed at the moment of climb onset, the comparison was based on specific energy height: He = H + V² / 2g, which reflects the aircraft’s total mechanical energy and offers a more accurate basis for analysis. The human pilot followed the AI’s climb profile as closely as possible, keeping the entry load factor below 2.5g and maintaining a pitch angle near 35 degrees. The result was somewhat unexpected, yet entirely explainable: the human-piloted aircraft outperformed even the default AI with increased thrust. This illustrates a point mentioned earlier — that the exact climb profile can significantly affect energy performance and the resulting He gain over the climb segment. While it is difficult to pinpoint the exact source of the additional energy gain, it most likely resulted from a smoother pull into the climb. A more definitive answer would require time-stamped recordings of flight parameters for both AI and player aircraft, allowing for a detailed comparison of dHe/dt during the climb phase. The influence of flight profile on energy climb rate was further highlighted in the final test, where the player attempted to follow the AI in a zoom climb (see video). The result was even more surprising — and again, entirely explainable.

As far as I understand, the forum thread was discussing a recording from an online session, since the aircraft names match the nicknames of forum participants. Are there any references showing such large TacView discrepancies occurring exclusively in offline missions?

Thanks for the materials! Small modifications to the aerodynamic polars — especially within the low-to-mid Mach range — have minimal impact on overall energy performance compared to relatively larger changes in thrust. That said, it’s reasonable to acknowledge that changes in thrust, and thus in the bot’s energy potential, can under certain conditions influence its combat logic or maneuvering behavior.

This is quite interesting, but judging by the graphs posted by Curly, the aircraft's aerodynamics (i.e., the polars), which are solely responsible for energy performance along with thrust, were barely changed in the low-to-mid Mach number region where your test took place. Therefore, in our case, thrust is essentially the dominant factor in energy gain. The maximum lift coefficient, unfortunately, has the opposite effect on energy: if you reduce it for the AI — as was done in the mod based on the reference document — the AI will actually preserve energy better than the default version. Unfortunately, I haven't been able to locate the mod file to try it myself. Would you be willing to share it? If you still have the track from your test, it would be quite valuable to see video of both runs — one using the default data file, and the other using the modified one. In that case, your piloting should remain the same, and the AI’s trajectory should presumably change. And, by the way, how can I make the AI perform such a maneuver in a mission?

Does this refer to online TacView sessions, or are there known cases of such 100% mismatch in offline missions as well?

Thank you — I agree it's good to see that SFM and PFM align well under stable conditions. However, zoom climbs of the type shown in your video are difficult to verify without detailed data. The results depend heavily on maintaining the same speed-energy profile and minimizing oscillations or excess control input. To make conclusive statements about energy performance in steep climbs, a TacView recording or a comparable export of time history for TAS, altitude, and G-load would be ideal — for both aircraft. That would allow direct comparison of energy rates and drag profiles. Even if we assume that the thrust curve in the low-speed regime was deliberately adjusted for some internal purpose (though I’d argue that it's not simply a "no-loss" curve, since the shape doesn't fully match that either), the difference in equivalent vertical velocity at the worst point (IAS ~250 km/h) does not exceed 8–9%. Given that the AI spends almost no time at those speeds, the contribution to its total energy gain is negligible. At higher speeds, the difference becomes virtually zero. So, even replacing the base thrust table with one that strictly matches the theoretical curve would not result in any substantial change to the outcome of dogfights against the AI.

Thank you for the entertaining interlude — sincerely. It's always refreshing to see people stay engaged, even in parody. However, as enjoyable as it was to read, I couldn’t find in it anything resembling a technical counterpoint to the tested climb profile or the data comparison with the real-world reference chart. Regarding the 500 knots straight up — if that was a serious remark, I would kindly ask for clarification. A well-trimmed MiG-15 starting from 950+ km/h (which is about 510 knots) absolutely can convert kinetic energy into altitude for a short time — that's basic energy conservation and directly tied to its dynamic ceiling. There's nothing unnatural about it unless you're claiming the AI sustains it indefinitely, which is easily testable in TacView or even with a stopwatch and status bar, as already demonstrated. You’re very welcome to propose a reproducible test that demonstrates any claimed violation of physics. If it's testable, measurable, and repeatable — I'm all ears. Otherwise, I’d suggest we let the data speak. Because ten minutes of quiet measurement saves hours of speculative back-and-forth.

Most of the frustration and speculation expressed in this thread seems to stem from combat-related behavior. I haven’t come across many complaints about AI taxiing, takeoff, or landing. And to be honest, those phases don’t particularly interest me either, since I primarily view the AI as a sparring partner in aerial combat. Now, climb performance represents a critical component of combat behavior ( it’s energy gain at 1g, and while it doesn’t occur in isolation that often, it fully defines acceleration in level flight and in shallow dives) both of which are common in real engagements. What I’ve shown is that in this regime, the AI follows the physics defined in its data tables and behaves exactly as the real aircraft would according to flight test documentation. That alone should dispel many doubts. What do we observe more often in dogfights? Sustained or transient turning flight with increased load factors, where energy is either lost or traded in ways governed by well-known aerodynamic relationships. I also showed that the aerodynamic data used for the FM (lift, drag, thrust) supports correct energy behavior in those turning regimes. So far, everything lines up. However, to completely rule out the suspicion that the AI is “cheating” in these cases, the next logical step would be to analyze a 1v1 fight recording where both the player and AI aircraft are of the same type. Specifically, you’d export the time history of TAS, altitude, and G-load for both. Using known energy equations, one can compute the specific excess power and compare it to the observed load factor. If the AI is cheating — by bypassing the FM or using hidden scripts — it would become immediately obvious. Either its energy behavior would be physically implausible, or you'd see clear discontinuities or artifacts in the data. I believe this type of empirical comparison would cut through all the theoretical debate and provide developers with a solid foundation for any investigation or follow-up.

This mod is unlikely to make a meaningful difference, if only because the thrust has been adjusted in the TAS region below 300 km/h — a regime the AI almost never flies in, even at low altitude. During climb, the AI typically maintains a TAS around 700 km/h, where the thrust values in the mod remain essentially unchanged. So any claimed improvements are unlikely to impact the AI’s actual climb behavior in a measurable way. Instead of relying on modifications, you can perform a direct test using the standard setup: Place the AI-controlled MiG-15 ahead of your aircraft at a distance of 600 meters, both starting at sea level with a TAS of 700 km/h. Assign the AI a route with waypoints that require a continuous climb to 11,000 meters at full power. Position your own aircraft directly behind the AI (600 m), matching its speed and heading. At mission start, apply full throttle and maintain level flight. Let your aircraft accelerate naturally until it reaches 700–705 km/h TAS, then initiate a gradual climb, maintaining 710 ± 10 km/h TAS throughout. Use trim gently to hold pitch; avoid aggressive control inputs. The goal is not to match the AI’s pitch angle, but to fly a clean, energy-efficient climb profile.

What you’re describing is exactly what separates a well-trained pilot — or a skilled virtual one — from someone just “flying it by feel.” Yes, it's hard. Yes, it takes discipline. That’s why real-world flight and combat manuals emphasize very specific energy management techniques: Climbing at the most efficient airspeed. Maintaining coordinated, smooth flight. Avoiding unnecessary g-loading. Turning at corner velocity. Trimming properly and flying clean. These aren't theoretical details — they're core to real-world air combat doctrine, because that’s what allows you to stay fast, stay high, and stay alive. You don’t need to be a robot. But you do need to avoid wasting energy through unnecessary control inputs. And even if your airspeed control is only accurate to ±30–40 km/h, that’s often enough, as long as you don’t induce drag by chasing the fight with abrupt pitch changes. As for the AI: it simply flies by the tables with clean logic and no wasted motion. That’s not superhuman — it’s what happens when someone (or something) doesn’t bleed energy. In fact, I suspect that when some players meet another human online who does understand energy fighting, timing, and aerodynamic discipline — they’re likely to call them a cheater, too. That said, I’d like to remind everyone that the original goal of this analysis was not to examine AI behavior in terms of tactics or input realism, but simply to test the claim that the AI “doesn’t obey physics, or has physical performance beyond what a player-controlled aircraft can achieve.” The flight test results suggest otherwise. Let’s avoid shifting the discussion away from that specific and measurable question.

I’m not suggesting that the AI behaves perfectly in every respect — only that, in this specific context, its energy performance in sustained climb matches both the manual and computed data to within a few percent. That’s not “superhuman” — that’s simply a correct implementation of aerodynamic tables. The formation example is a common misunderstanding: A wingman falling behind during a climb is not necessarily a sign of AI "superpowers", but often a result of human-induced energy loss — especially when trying to aggressively hold position by chasing pitch and throttle changes. In real flight, a lead aircraft never climbs at full power unless deliberately trying to leave the wingman behind. If you want to stay with the AI during a clean climb, fly exactly like it does: hold a stable profile, minimize control input, and don’t chase energy with abrupt g-load changes. This isn’t hypothetical — it’s perfectly doable in practice. In fact, in the test shown earlier, a human-flown aircraft matched the climb profile almost exactly by simply following the documented TAS and keeping the g-load near 1.0. Finally, if there are concerns about other aspects of AI behavior — like situational awareness or detection — that’s a separate discussion, and worth having. But let’s not conflate that with correctly modeled flight performance.

If your goal is to tame the AI's energy performance, one practical approach is to keep the original polar coefficients while simply zeroing out the B4 term. This will already reduce excessive climb and turn rates. For more accurate tuning, however, it's worth adjusting the values to better reflect real-world aerodynamic characteristics: Cx0 ≈ 0.025 B ≈ 0.07 These values are typical for aircraft of this class and will result in a maximum L/D ratio around 12 — a realistic and well-balanced figure.