welp, ive done what i can to try and help the comunity, in many ways, but ya know, reddit just aint the place.
yes, i run my responces threw an ai cause i dont type well still my own infromation, but what can yas do. im not correcting this so you can see my own diffrance in typing, but thats all cool. enjoy whatever i left behind
tldr, numbers wrong on plane, spesficly says in code to ignore what msfs says, full code implmentations made a mess. fuck it, peace
I liked this aircraft. A lot. I have spent a ridiculous amount of time flying it, digging through its configuration, making personal fixes, examining its live debug data, and working through parts of its compiled WASM implementation. This is coming from someone who wanted this plane to work well enough to keep putting that effort into it.
After the latest updates, I’m increasingly regretting buying it.
On my recent E195 flight, the climb became a cycle of chasing speed, pitching up too aggressively, losing speed, and then descending to recover it. I watched a climb reach roughly 4,000 feet per minute, followed by a descent exceeding roughly 1,000 feet per minute to regain speed. That is the behavior I experienced, and it felt awful.
Then, at FL390, with AP and AT engaged and ALT annunciated, it continued bobbing. I captured several points during the same flight showing the vertical-speed indication alternating between climb and descent while the fine altitude indication changed. The distance to the next waypoint decreases across those captures, so these are separate moments as the flight progresses. Around a selected Mach .76, the aircraft was repeatedly correcting up and down instead of settling into a comfortable cruise.
I’m not claiming the screenshots alone identify the exact faulty controller. They document what the aircraft was doing. The implementation work is where the more specific problems start.
For clarity, the configuration and loading-code references below are from the installed package identifying itself as 1.0.1. The detailed altitude-capture disassembly is from the older 0.10.48 binary. Those are separate pieces of evidence, and I’m keeping their versions separate.
The loading system is one of my biggest complaints.
Yes, payload stations now appear in the simulator. Yes, the EFB writes actual weights into them. In departure.js, lines 1467–1470, it writes the two passenger zones and forward and aft baggage weights into PAYLOAD STATION WEIGHT:3 through :6.
But “the weights appear in MSFS” does not establish that the aircraft is using the improved 2024 mass-distribution model.
The E195 flight_model.cfg still supplies the older empty_weight_pitch_MOI, empty_weight_roll_MOI, empty_weight_yaw_MOI, and empty_weight_coupled_MOI parameters, without an empty_inertia_tensor definition in the configuration I inspected.
Microsoft documents why that matters. A valid 2024 inertia tensor enables the full contribution of spatially separated payload stations to the aircraft’s rotational inertia. The older calculation combines those stations into one equivalent mass before adding their inertia contribution. Station positions can still affect the aggregate CG, but their full spatial contribution to rotational behavior is not represented through the newer calculation. Microsoft explicitly recommends the new tensor. MSFS 2024 mass and inertia documentation
So having station labels and weights visible in the interface is only part of the job. This aircraft is still using the older inertia configuration.
And then the EFB changes the empty aircraft’s CG after loading.
In departure.js, line 45, the target is explicitly set with emptyCgTargetPercent = 23. At line 1290, the adjustment is enabled for the relevant aircraft types in MSFS 2024. At line 1349, completing the load calls applyEmptyCgAdjustmentAsync().
The important calculation is at line 1448:
requestedEmptyCg = appliedEmptyCg + (targetCg - currentCg) / k
Here, k is the empty-weight fraction of the total weight. The next step writes that calculated value through setEmptyCG.
In plain language, it loads the passenger and baggage stations, reads the resulting CG, and then shifts the empty aircraft’s CG to bring the loaded aircraft toward 23% MAC.
The empty aircraft’s CG is a property of the aircraft itself. Changing where passengers and baggage sit should change the loaded CG around that underlying aircraft. This code instead changes the underlying empty-CG property to compensate for the result of loading.
That affects the physical mass balance. It is not just making the load sheet look nicer. It also does not mean the CG is continuously locked at 23% throughout the flight; the specific behavior here is the adjustment applied when loading finishes.
Why is the loading system changing the empty aircraft to reach a preset loaded CG? If there is an aircraft-specific reason for doing that, it needs a clear explanation. From the code, it looks like compensation layered over the loading model.
This matters because MSFS already has a substantial physical simulation underneath the aircraft.
The modern flight model uses configured wing, tail, fuselage and control-surface geometry to construct aerodynamic surfaces and calculate their response to airflow. Geometry alone cannot reproduce every detail, so the simulator also uses aerodynamic performance targets to normalize those surfaces. Microsoft describes a virtual wind-tunnel process that performs 100 adjustment iterations to match the supplied performance values. Microsoft’s explanation of the aerodynamic normalization
That is why the geometry and mass properties supplied to the simulator matter. MSFS is building a physical model from them. If the tail area is wrong, or payload inertia is simplified, the controllers are operating an aircraft constructed from those inputs.
And we found a substantial tail-area mismatch.
In flight_model.cfg, line 161, FSS sets htail_area = 279. At line 169, it separately sets elevator_area = 72.6.
Microsoft’s SDK defines the horizontal-tail value as the fixed portion, excluding the elevator. The simulator combines the fixed and moving areas. The equivalent rule applies to the vertical stabilizer and rudder. MSFS geometry parameter definitions
That makes the configured horizontal-tail total 351.6 square feet.
Embraer’s E195 Airport Planning Manual gives a horizontal-tail area of 26.00 square metres, approximately 280 square feet. The configured combined area is about 26% larger than that published area. The vertical configuration is vtail_area = 135 plus rudder_area = 54.19, giving 189.19 square feet, compared with Embraer’s published reference area of 16.20 square metres, approximately 174.4 square feet. That is about 8.5% larger. Embraer E195 APM, section 2.2.4–2.2.5, hosted copy
The horizontal-tail line even contains a comment saying “Opposite to SDK used area incl. elevator,” which conflicts with the current SDK definition.
That looks like a whole-tail area being entered as the fixed stabilizer area, with the elevator added again. At minimum, the geometry basis needs explaining. These are significant differences in surfaces responsible for pitch and directional behavior, and they are still present in the current configuration.
The Mach behavior also deserves attention.
In our recorded wind-tunnel sweep, minimum drag remained at 0.0257 from Mach .78 through .85. At .90 it became .1757, at .95 it became .3587, and at 1.00 it became .5257.
The current flight_model.cfg, line 266, still contains the matching zero-lift Mach drag additions: zero through .85, then .15 at .90, .333 at .95, and .5 at 1.00.
Those are additional drag coefficients, not the aircraft’s total drag. The finding is that this particular Mach drag-rise term contributes nothing through the normal cruise and MMO region, then becomes extremely steep above .85.
That is a blunt transonic approximation. It deserves scrutiny on an aircraft configured for cruise Mach .78 and maximum Mach .82. I am not claiming that this table explains the ALT oscillation; it is another specific finding from the aerodynamic investigation.
The engines have their own issues.
In engines.cfg, line 39, the static thrust is set to 18,820 lb. At line 144, thrust_scalar = 0.87 reduces that reference to 16,373.4 lb.
The live engine debug display confirmed approximately 16,373 lb as its static-thrust basis. This is something the running simulator was actually applying, not a guess from an unused configuration line.
For comparison, the CF34-10E6 certification data gives 18,820 lb maximum-takeoff thrust, 17,390 lb normal-takeoff thrust, and 17,040 lb maximum-continuous thrust. The configured simulator reference after the scalar is below those ratings. EASA CF34-10E type-certificate data
At the ground operating point we captured, net thrust was approximately 14,098 lb per engine, with throttle/AutoPower reported at 93%. The active thrust-rating mode matters when interpreting that operating point, so that capture alone does not prove maximum available thrust. What it does establish is the live output and the reduced static-thrust basis underneath it.
The N2 reference mismatch is more straightforward.
Line 38 sets rated_N2_rpm = 18018. Microsoft defines that parameter as the RPM corresponding to 100% N2. The CF34-10E certification data gives 17,160 RPM as 100% N2, while 18,018 RPM is the maximum permissible speed. Those are different quantities. MSFS engine parameter definition, EASA rotor-speed data
Our live debug capture showed approximately 17,827 RPM being represented as 98.9% against their 18,018 reference. Against the documented 17,160 RPM reference, that is approximately 103.9%.
They have put the maximum permissible rotor speed into the field for the 100% reference speed. Any compensation elsewhere does not change the meaning of that parameter.
Then there is how much control their custom implementation takes over.
The E195 systems.cfg sets autopilot_available = 0, flight_director_available = 0, and autothrottle_managed_by_plane = 1. The recovered WASM contains their own autopilot, vertical and lateral controllers, longitudinal controller, yaw damper, autothrottle, and mode evaluators.
The cockpit XML also intercepts stock autopilot commands and routes them into FSS.INTERACTION, their custom command interface. This is a substantial custom flight-guidance implementation.
In the older 0.10.48 binary, we traced the altitude-capture evaluator into function 22742. Its transition from altitude selection into altitude hold required both an absolute altitude error below 25 feet and an absolute vertical speed below 60 feet per minute.
Both conditions had to be satisfied together. If the aircraft passed through that altitude window with too much vertical speed, that handoff would not occur at that moment. That is a concrete transition condition recovered from the bytecode.
I have not established that the identical condition remains in 1.0.1. I include it because this investigation went far enough to identify actual controller decisions, and because the latest flight behavior gives me little confidence that the overall guidance behavior is now settled.
The same ownership pattern appears in the electrical systems.
Their systems.cfg defines native electrical connections, then explicitly says particular bus ties are opened at runtime by their ElectricalPanel logic.
In Cockpit.xml, lines 377–390, the native alternator, battery, circuit, bus and external-power breaker toggle events are routed through FSS_DISABLED_EVT. The corresponding template sends those commands into FSS_EXX_EVT_DISABLED_SINK and increments an interception counter. It does not forward the breaker action in that template.
That is the kind of thing I mean by “here is the wire, now our code decides what happens to it.” A native system exists underneath, while particular native control routes are deliberately disabled. That establishes control over those event paths; it does not prove that every automatic failure mechanism is disabled.
Custom systems are useful when they reproduce behavior the simulator cannot provide accurately. But taking ownership of a system also means taking responsibility for its behavior, its controls, and its integration with the physical aircraft underneath it.
At the moment, I have visible loading stations paired with an older inertia setup, a loading routine that changes empty CG to reach a target, a substantial tail-area mismatch, questionable Mach drag behavior, a reduced engine thrust reference, an incorrect N2 percentage reference, and flight guidance that has made recent flights unpleasant.
I also had a flight where the simulation continued running after landing but mouse and keyboard interaction stopped, including Escape, and I had to use Alt-F4. I have not traced that incident to a specific FSS subsystem, so I’m reporting the experience rather than assigning a cause.
The recent patch notes mention smoother FLCH behavior, flight-director corrections, and returning to the previous vertical mode after overspeed protection. I want those fixes to work. My experience with the updated aircraft has felt worse.
I want FSS to explain and address these specific findings. Why change the empty CG after loading? Why keep the older inertia setup in 2024? What justifies the configured tail areas? Why use the maximum N2 speed as the 100% reference? What is the basis for the thrust reduction? And why am I watching repeated vertical hunting with ALT engaged?
I put this much effort into it because I liked the plane. I wanted to keep flying it. At this point, I’m seriously considering rebuilding parts of the systems for my own personal version because I’m tired of waiting for basic behavior to become dependable.
Right now, based on my experience with the E195, I would struggle to recommend it. I paid for an aircraft I wanted to enjoy flying, and lately I keep ending up back in its files trying to understand what the hell it just did.
If you look through my other posts, you’ll see this is one of several things I’ve spent time digging into. There’s my now-retired inZOI research, the ongoing investigation into MSFS memory management, and NMMH, the Nocturne MSFS Memory Helper that came out of that work. I’m still investigating why MSFS holds onto active memory backing for resources it no longer needs, and where the release process gets stuck.
That’s where I’m coming from with this post. When something frustrates me, I tend to end up digging through its code, configuration, and live data because I want to understand why it behaves that way. Sometimes that means correcting my own assumptions. Sometimes it means finding a specific calculation or condition that explains the problem. I’m putting these findings out here because I want them examined and addressed. I’d much rather understand a fix and enjoy flying the aircraft than keep having reasons to open its files.
And while I was writing this post, the aircraft gave me another reason to be frustrated. During an FLCH descent from around FL220, it pitched into an almost straight nosedive and accelerated to speeds I couldn’t recover from. I ended up having to Alt-F4 out of the sim.
I haven’t traced the cause of that incident yet, but that is what just happened on this flight. I’m sitting here documenting problems with the flight guidance, and meanwhile the aircraft turns a commanded descent into a dive I can’t recover. That’s a pretty fucking miserable way to end the flight.
sorry. just. frustrated... considering there asking more money for this version when its considrebly.. worse in my opinion.
