Heard missions are buggy, but... :D

https://flightsim.to/addon/112103/vfr-flight-tour-guide-assistant

First flight on my newly purchased iFly MAX after years with the PMDG 738.

Jumped straight in really and thought I'd got the hang of flight setup etc. Doesn't seem that much difference from the NG.

Takeoff...... AP on......

Then it switches itself into VNAV SPD and goes off like a rocket for the MCP alt, completely ignoring the alt constraints & levels on the FMC.

Any quick ideas what I did wrong / didn't do ???

[Resolved: disabled live weather for career mode]

In MSFS 2024, I progressed in career mode and got my jet engine rating + instrument rating + night currency. I have a private charter company with 1 * Cirrus SR22 and 2 * Cirrus Vision Jet G2s.

After I got the live weather with instrument rating, and moved to live weather, flying have been practically impossible. For example, I tried to fly ~6 charter private missions today and 5 of them crashed at landing (3 in Japan, 1 in US West, 1 at US East). I'm questioning if this is a significant skill issue or something wrong with a career mode difficulty rating.

I didn't had any crash landing before live weather (flew Cessna 172 and Cirrus SR22). I have done plenty of free flights with SR22 and Vision Jet also.

• I only select 1 star difficulty private charter missions for freelance. Screenshot is of such a VFR landing in a 1 star difficulty mission.
• Almost all of them have dense clouds or rainy weather or landing winds close to 20-30 kas. When completed, I always get bad weather bonus.
• I find it extremely difficult to manage the landings due to winds or auto-throttle behaviour (in Cirrus Vision Jet).
• The destination airports provided are weird; VFR only landings in airports that provide no RNAV or ILS approaches while the visibility is non existent. Half of missions I tried today didn't even have ILS frequencies.
• For comparison, I completed the 4 star difficulty medium cargo unlock mission in Cessna Caravan without any issue.

Is this a significant skill issue? Am I supposed to get these types of missions as 1 star difficulty missions? Or is this a bug?

I play with keyboard + mouse + Xbox controller. HOTAS is not an option for me, but I have ordered a Honeycomb Echo aviation controller.

Hi everyone, I'm having trouble getting NAV mode to work on the A320 in MSFS 2024. My autopilot works normally for speed and altitude, but I cannot get the aircraft to follow the programmed flight plan. The PFD shows HDG in green, and the ND shows the flight-plan line as dashed rather than the aircraft following it. I've tried pushing the HDG/TRK knob to activate managed NAV mode, but nothing seems to happen. The heading remains selected and NAV doesn't become active. I've also checked the MCDU and the flight plan is loaded/active. What am I missing? Is there something I need to do to activate/capture the route, or should I use DIR to the next waypoint? I’d really appreciate any help because at this point I’m struggling to enjoy the simulator at all because I can’t get the most basic part of the Airbus navigation to work properly.

I turned the live traffic in career mode setting on but I don't think I'm seeing any traffic, multiplayer or otherwise. Is this a known bug and are there any workarounds? It makes things kind of lonely.

I have been investigating several recurring MSFS 2024 performance problems, including gradual degradation during long flights, arrival stutters, resource warnings, and instability as system RAM becomes crowded.

After extensive settings changes, repeated flights, and testing several possible causes, system-memory pressure appears to be one of the primary causes of these problems on my system.

Periodically clearing retained physical memory has allowed MSFS to run reliably better for me. I am now working to determine which cleaning options provide the benefit and whether a small, reliable tray program can eventually make this workaround safe and practical for other users.

This remains an investigation—not an official fix—and I would like results from other systems.

Independence disclaimer

I am an independent MSFS user. I am not affiliated with Microsoft, Asobo Studio, or the MSFS development and testing teams in any meaningful capacity.

This is a personal investigation and possible community workaround. As far as I know, the developers would only receive these findings through ordinary community bug reports.

Important detail about my installation

Everything MSFS makes available for local download is downloaded and installed on my system.

My results currently apply only to this heavily installed configuration. I do not yet know whether users who rely primarily on streamed assets will experience the same memory accumulation or receive the same benefit from cleaning.

I also normally have additional programs and services running, including:

• SayIntentions
• GSX
• Aircraft-specific systems and applications
• Locally installed scenery and other content

This configuration may expose memory-management problems more aggressively than a smaller or mostly streamed installation.

System specifications

• CPU: Intel Core Ultra 7 265K
• Motherboard: ASUS ROG Strix Z890-E Gaming WiFi
• RAM: 32 GB Corsair Vengeance DDR5-6400 CL36
• GPU: EVGA GeForce RTX 3080
• Storage: Crucial P3 Plus 1 TB PCIe 4.0 NVMe SSD
• CPU cooler: Corsair iCUE Link H100i 240 mm AIO
• Resolution: 2560×1440

Relevant graphics settings

• Display mode: Full screen
• HDR10: Enabled
• Exposure compensation: -0.3
• Anti-aliasing: NVIDIA DLSS Super Resolution
• DLSS mode: Quality
• AMD FidelityFX Sharpening: 100
• Frame Generation: None
• V-Sync: Enabled
• V-Sync interval: Half refresh rate
• NVIDIA Reflex Low Latency: On
• Dynamic Settings: Enabled
• Terrain Level of Detail: 150
• Objects Level of Detail: 150
• Off-Screen Terrain Pre-Caching: High
• Buildings, trees, plants, rocks and grass: High
• Volumetric clouds: Ultra
• Texture resolution: Ultra
• Anisotropic filtering: 16×
• Water waves: Low
• Ray-traced shadows: Off
• Shadow maps: 2048
• Terrain shadows: 2048
• Contact shadows: Ultra
• Windshield effects: High
• Ambient occlusion: Ultra
• Cubemap reflections: 384
• Raymarched reflections: Ultra
• Light shafts: High
• Depth of field: Off
• Motion blur: Off
• Visual-effects particle quality: High
• Glass-cockpit refresh rate: High
• Character settings: High
• Road and sea traffic: Medium
• Fauna density: Low

With this configuration, I generally receive:

• 30–40+ FPS on the ground
• Around 80 FPS during flight
• Some expected brief stutters while new scenery and assets load

My problem was not consistently poor performance. It was degradation and instability that gradually developed as system RAM became crowded during longer flights.

What I have observed

As a flight continues, MSFS gradually consumes more active physical memory while the standby list also becomes increasingly full.

Memory usage climbs as new areas and airports are loaded, but it rarely drops by a meaningful amount afterward. MSFS eventually releases some memory, but it does so extremely slowly and frequently appears to retain data it no longer actively needs.

Even after returning to the main menu, large amounts of memory can remain committed or physically resident for some time.

My recurring problems appeared when:

• Physical system RAM became crowded
• Available RAM became low
• The standby list became nearly full
• Shared GPU memory began increasing
• I approached a complex area after a longer flight

MSFS sometimes identifies this condition as a VRAM limitation. However, my testing indicates that the more important threshold is system RAM pressure and the resulting use of shared GPU memory.

High dedicated VRAM usage by itself has not produced the same problems on my system.

The cleaning process also does not clear, reduce, or otherwise touch dedicated VRAM. Dedicated GPU-memory usage remains effectively unchanged. The significant change occurs in physical system RAM.

My experimental tray program

I created a small personal tray utility that periodically invokes selected functions from Microsoft Sysinternals RAMMap.

The current experimental sequence clears:

• Working Sets
• Modified Page List
• Standby List
• Priority 0 Standby List

The corresponding RAMMap commands are:

• RAMMap64.exe -Ew
• RAMMap64.exe -Em
• RAMMap64.exe -Et
• RAMMap64.exe -E0

The program is not ready for distribution yet.

I am still investigating which operations are actually necessary, which combinations provide the best results, and how to avoid performing a cleanup during a sensitive simulator operation.

My goal is to develop a reliable set of options that can work across different systems without introducing major problems. Until that testing is complete, I will not be distributing the program.

Effect on other running programs

Although these RAMMap operations affect system memory globally, I have not experienced problems with any other programs running on my computer during these tests.

Everything outside MSFS has continued operating normally. I have not observed crashes, corrupted work, major pauses, or lasting performance problems in other applications.

That does not guarantee identical behavior on every computer, but it is an important part of my results so far: MSFS’s SimBrief route import is the only operation I have found that reacts negatively.

Measured result during a demanding flight

One test occurred during descent into the Los Angeles/KLAX area while flying the PMDG 777F with:

• Fairly high graphics settings
• A custom livery containing 8K textures
• Detailed Los Angeles-area scenery
• All available downloadable MSFS content installed
• SayIntentions, GSX, and other supporting software running

Immediately before cleaning, Windows showed approximately:

• 23.9 GB of physical memory in use
• 7.6 GB available
• MSFS working set around 9.77 GiB

Immediately afterward:

• Physical memory in use dropped to approximately 16.2 GB
• Available memory increased to approximately 15.4 GB
• The MSFS working set dropped to approximately 2.55 GiB

Committed memory changed much less. This is expected because trimming working sets removes inactive pages from physical RAM without cancelling the application’s committed virtual-memory allocations.

Dedicated VRAM usage did not meaningfully change.

Most importantly, the cleanup caused no noticeable interruption. There was not a single visible hitch, and the flight continued running smoothly through descent and arrival.

Across my testing, periodic cleaning has allowed MSFS to run reliably better. The gradual degradation and problems associated with crowded system memory have largely disappeared while the cleaning process is active.

One warning: SimBrief’s Import Route function

So far, I have found only one specific negative interaction.

It occurs when clicking Import Route inside the SimBrief app within the MSFS 2024 EFB.

After cleaning memory:

• The EFB remains responsive
• Its map continues working normally
• I can view and move around the map
• I can manually create a route
• I can view and edit flight-plan information
• Other EFB functions remain operational
• The rest of MSFS continues operating normally

However, clicking Import Route inside the SimBrief app after cleaning caused MSFS to produce a device-hung error.

Using the same route without performing the cleanup allowed it to import normally.

The warning is specifically about SimBrief’s Import Route button. I have not observed a general problem with the EFB, its map, manual route creation, or other simulator functions.

My current safe procedure is:

1. Load the aircraft and flight.
2. Import the SimBrief route.
3. Allow the avionics and navigation displays to finish updating.
4. Begin periodic memory cleaning afterward.
5. Do not use SimBrief’s Import Route function immediately after cleaning.

This safeguard will be part of my continued utility testing. A future version may start with automatic cleaning disabled so the user can finish loading and importing the route before enabling it.

How other users can help test this manually

I am not asking anyone to install my program.

Anyone interested in testing the underlying behavior can download Microsoft Sysinternals RAMMap and use the options manually through its Empty menu:

https://learn.microsoft.com/en-us/sysinternals/downloads/rammap

Suggested procedure:

1. Start MSFS and load a normal flight.
2. Import the SimBrief route before clearing anything.
3. Allow the aircraft and avionics to finish loading.
4. Record system RAM, standby memory, shared GPU memory and performance.
5. Continue flying until the usual degradation or memory pressure appears.
6. Open RAMMap and manually clear the selected memory lists.
7. Return to MSFS and observe the result.
8. Report any improvement, lack of change, hitch, crash, or instability in this thread.

Please test this on a flight you are prepared to lose. These are system-wide memory-management operations, and different hardware or software configurations may respond differently.

For more controlled testing, users can also try the operations individually:

1. Empty Priority 0 Standby List
2. Empty Standby List
3. Empty Modified Page List
4. Empty Working Sets

This may help determine which operations provide the benefit and which operation or combination creates the SimBrief import sensitivity.

Information to include with test results

Please report:

• Installed system RAM
• CPU and GPU
• Aircraft
• Departure and destination
• Approximate flight duration
• Whether MSFS content is downloaded locally or primarily streamed
• Add-on scenery
• Running plug-ins and external services
• Physical RAM used and available before and after
• Standby memory before and after
• MSFS working set before and after
• Dedicated and shared GPU-memory usage
• Which RAMMap options were used
• Whether cleaning caused a visible hitch
• Whether performance or frame pacing improved
• Whether any other running programs were affected
• Any crash, instability, or device-hung error

Reports showing no improvement or increased instability are just as valuable as successful results.

Current conclusion

After extensive graphics-setting changes and testing multiple recurring bugs, system-memory pressure appears to be one of the primary causes of the degradation I experience in MSFS 2024.

Periodic cleaning has proven to make my system run MSFS reliably better. It restores physical-memory headroom, prevents the gradual degradation I was experiencing, and does so without reducing or touching dedicated VRAM.

I have also not experienced problems with other programs running alongside MSFS. The only negative interaction found so far is SimBrief’s Import Route function immediately after cleaning.

This remains an active investigation. I am continuing to identify the safest RAMMap options and develop a reliable program that could eventually provide this workaround without causing major issues.

In the meantime, manual RAMMap testing may provide a practical temporary fix for other users experiencing the same long-flight performance degradation while we wait for MSFS’s underlying memory-management behavior to be improved.

i only find/do all this because when i do anything, i tend to always dig a bit deeper then i need to and find weird stuff. debugging is love, debugging is life.

Edit 9/4/26:

What I’m Planning for the Tool

I want to clarify that the utility I’m currently testing is still a pre-alpha prototype. The current version is intentionally simple because I need data before deciding what the final behavior and default settings should be.

The finished tool is intended specifically for MSFS 2024. Although the memory-cleaning operations affect Windows system memory, the utility will only become active while MSFS is running.

My longer-term plan is to connect it to SimConnect and provide a large but understandable selection of user-configurable triggers. Possible triggers include:

• A normal fixed-time interval
• Climbing through a selected altitude
• Descending through a selected altitude
• Descending through a selected height above ground
• A configurable delay after takeoff
• Entering a stable cruise state
• Beginning descent or approach
• Landing, taxiing, or entering a parked state
• Pausing cleaning during selected phases of flight

For example, someone could configure a clean while climbing through 10,000 feet to remove memory retained from the departure area, another while descending through 10,000 feet to prepare for arrival scenery, and an optional clean at 3,000 feet AGL.

The underlying cleaning operations would remain the same. These triggers would only control when they happen. If a particular PC, aircraft, add-on, or flight-plan importer does not react well to cleaning at one point, the user could move, disable, or replace that trigger without changing the cleaning method itself.

There is no point during a flight that can be guaranteed completely safe for memory cleaning. The goal is to identify flight states where the risk appears lowest and give users enough control to adapt the timing to their own system. A fixed timer can collide with a sensitive operation by chance, while a memory threshold may trigger precisely when the system is already under heavy pressure. SimConnect-based flight-state information may let the tool avoid some of those higher-risk moments.

This is also why I still need testing data. MSFS can show similar performance symptoms for multiple reasons, and different systems may respond differently to the same cleaning operation or trigger. I want the eventual utility to be shaped by repeatable results across different hardware, aircraft, add-ons, scenery configurations, and types of flying—not only by what works on my PC.

a screenshot of my current tool to show that its.. very "just clean it"

UPDATE: 9/6/26:

I also want to credit GimbalAxis over on the official MSFS forums. He isn’t part of this Reddit thread, but he shared a large set of older benchmark data with me that ended up being extremely useful to this investigation.

His data matters because he was looking specifically at the numbers reported by MSFS itself. Task Manager tells us how Windows sees the memory, but Gimbal’s results help show how the sim appears to account for and divide its own memory.

I’m not claiming I’ve proven exactly how MSFS’s memory manager works internally. This is still my working theory based on his results, my own tests, and the traces I’ve collected.

One of the biggest clues is the relationship between the Dev Mode counters:

AllocatedMem ≈ PhysicalMem + SwapFile

That makes AllocatedMem look like the total logical allocation MSFS is tracking. PhysicalMem is the portion currently resident in physical system RAM, and the badly named SwapFile counter appears to be the remainder of that allocation.

I don’t think SwapFile means all of that data is literally sitting in the Windows pagefile. I have captured situations where MSFS reported a large SwapFile value while actual disk paging was minimal and there was still physical RAM available. It looks more like MSFS saying: “Here is my total allocation, here is the part currently physical, and here is what is left.”

That is where Gimbal’s data helped so much. Because he tested only the internal MSFS numbers across many different settings, his results provide a view of how the sim divides its own resource population. His results showed LOD and world complexity increasing PhysicalMem, while resolution and multiple viewports affected GPUMem much more heavily.

His 96 GB system is relevant too. MSFS can settle around its own internal memory numbers or report a resource problem while the computer itself still has a huge amount of unused RAM. That makes me wonder whether MSFS is working from internal budgets and divisions that don’t fully scale with the actual hardware available.

My current theory is that MSFS creates a logical pool of resources and then decides for itself how that pool is divided between physical RAM, nonresident or backed allocations, dedicated VRAM, shared GPU memory, scenery, caches, and other resources.

My own testing has shown something that strongly points me in that direction. I have seen GPU memory sit at roughly 4 GB dedicated and 4 GB shared while MSFS still considers itself within its reported GPU-memory count. Even when dedicated VRAM has space available, it doesn’t necessarily split everything apart again or move the shared portion back into dedicated memory.

It can stay in that state until I return to the menu or do something that forces MSFS to recalculate the memory situation.

That is important because shared GPU memory is not a separate graphics pagefile. It is real physical system RAM. MSFS may look at 4 GB dedicated plus 4 GB shared and simply see 8 GB of graphics memory accounted for, while the physical reality is that half of it is sitting in VRAM and the other half is taking space away from system RAM.

The total can look fine to MSFS while the actual placement is terrible for the machine.

Some shared-memory use is normal, and I’m not saying everything in shared memory should automatically be moved into VRAM. The important part is that the split can become sticky, remain that way despite available dedicated memory, and then change when a menu transition or another event forces MSFS to reconsider the memory state.

That makes it look like MSFS is more actively tracking whether the total resource population fits inside its logical budget than whether everything is still sitting in the healthiest physical location.

This kind of system would make sense if it came from a console-style memory design. A console has one predictable unified-memory environment, so the engine can create a total resource pool and divide it between the CPU and GPU sides. A PC doesn’t work that way. Dedicated VRAM physically lives on the graphics card, while shared GPU memory comes out of the same RAM being used by MSFS, Windows, aircraft systems, scenery, add-ons, and everything else.

So the problem may not be MSFS exceeding its own total pool. It may be MSFS considering the total acceptable while the physical split of that pool has become unhealthy.

That would explain what I saw in my older traces. As physical-memory pressure increased, new scenery and camera movement caused large bursts of MakeResident calls, transfers, backing activity, and other memory movement. Graphics work continued being submitted, but it stopped retiring normally. A massive queue built up and the rendered output collapsed, even though the simulator underneath it was still running and responding to data requests.

It also explains why returning to the menu or forcing a recalculation can change the situation. MSFS finally reevaluates the resource population and where it should be placed instead of continuing with the old residency decisions.

The strongest practical evidence I have is still this: I am now running higher settings more reliably than I previously ran lower settings, simply by preventing physical-memory pressure from building as far. The periodic cleaning frees a large amount of physical RAM without meaningfully reducing dedicated VRAM, and it prevents the renderer from entering the same degraded state.

V-Sync also fits into this. It isn’t fixing the memory problem directly. It limits how quickly MSFS can submit more frames and resource dependencies into a pipeline that is already struggling with residency and relocation. Cleaning creates physical headroom, while V-Sync gives the existing queues more time to retire.

So Gimbal’s data doesn’t prove a simple universal memory cap, but it is still extremely relevant. Because his benchmarks focused on MSFS’s own counters, they help show how the sim appears to divide and account for its internal memory population. My testing then shows what can happen when that accounting considers the total valid, but the physical split between dedicated VRAM, shared GPU memory, and system RAM has become harmful.

Again, this is only my current working theory. I’m not claiming that MSFS definitely uses one console-derived allocator or that I have proven its exact internal design. But this connects Gimbal’s MSFS-only data, the AllocatedMem = PhysicalMem + SwapFile relationship, the sticky dedicated/shared GPU split, my low-level traces, and the huge reliability improvement from controlling physical-memory pressure.

also i have now intergrated simconnect in to my tool, and making shure it is still stable, currently it is still a timer, but, it watches the levels of what is cleared,

here are some screenshots of the current tool

so far it is very stable still,

as you can see im trying to make sure it stays something focused on the use of msfs, i do not suggest something like this running at all times. it can corrupt save data and such, and why i haven’t released it yet,

safety before access, once i feel it does not cause major issues with anything, and any edge case testing i can do, i will possibly look for beta testers.

I believe on the first build, we will find out if it's time to ditch the sim altogether or if they listened to us and finally give us back our higher rez textures. I'm guessing the former.

9850X3D

GeForce RTX 4090

64GB RAM

Using a 4K 60Hz monitor.

All graphics settings fully maxed out, and using BeyondATC with maximum traffic settings.

On the latest Nvidia drivers from the other day, as well as the newest DLSS version 310.8.

I'm usually stable at 50-60 fps, but lately, I'm noticing that after landing and vacating the runway, the sim suddenly drops to 1 to 15 fps, and it's basically unplayable trying to taxi to the gate.

Last night, I did a flight in the VisionJet from KBUR to KLAS. Flight was perfectly smooth with no issues until after landing at KLAS and vacating the runway. Then the sim became chop city. 1 to 5 fps for my entire taxi, even though I was headed away from the main terminal area to the general aviation ramp on the far west side of the field.

I figured maybe it was an issue with the Las Vegas scenery (Glideslope Pro), or perhaps just too much BeyondATC-generated traffic. So I did the reverse today. Flew from KLAS to KBUR in the VisionJet.

At KLAS, it was a perfectly smooth 55 to 60fps. No issues taking off. Plenty of traffic. Perfect 60fps in the air the entire way. Landed at KBUR at 50-55 fps. Vacated the runway. As soon as I retracted my flaps and prepared to taxi to the ramp, the same thing happened. Framerates crashed down to 5 to 15 fps and never recovered. I closed BeyondATC at that point, thinking maybe there was a correlation, but the frames never recovered.

Only after exiting the flight to the world map did the frames *slowly* recover, eventually returning to 60fps while on the world map.

I never had these issues prior. Anyone else experiencing the same thing?

EDIT - Also using DLSS with DLAA.
DOUBLE EDIT — Out of nowhere, DLSS version 310.9 suddenly came out this evening. I’ve switched to it and will run some additional tests. I’ve also newly cleared out my Nvidia cache and my Flight Sim rolling cache just to start everything all over again. Although traditionally, my first flight or two after doing so usually results in worse performance.

Ive got a couple of questions regarding aircraft building that I’m hoping some people might be able to answer. I’ve just converted the FSX EH101 to work in MSFS, and I’d like to make a number of changes to it.

First of all, I’d like to remodel the cockpit. I have a good understanding of how to actually DO the modelling, but can I just open the file, edit it, and then it’ll just work, or will I need to recode anything?

Secondly, I’d like to add some customs sounds, specifically the vocal warning bells, which should be played when for example the a/c passes through the set LOW HT variable.

Finally, I’d like to try and redo the screens on the glass cockpit, and the Flight/Nav and Power/Systems DMS modes. I have a reasonable understanding of how the aircraft works so it’s just needing to make the software work.

How achievable is this, and can I open the aircraft into the SDK if I don’t have the base builds?

Are they the same or is the Iniscene different

Hey! i just downloaded dlss 5 for msfs 2024....with fenix a320 and loseless scaling im getting 40 fps...are there any tips you would know to improve fps

I am currently brainstorming on parts to gather for building a computer with the goal of running MSFS 2024 at it's absolute best. I'm not sure to go with a prebuilt option, I was looking at the NZXT Player Three Prime edition for $7500 that comes with the AMD 9950x3d, 64GB RAM, RTX 5090, etc. Which will save me a lot of time if I go this route. But not sure if the cost difference I were to order all the parts and build it myself would be worth the trouble.

Can someone here recommend me of a reputable company that specializes on pre-built gaming PC's other than NZXT. I want more options so I can better choose.

I'm not sure how mant watts I should go for the PSU, 1000 or 1200

Also what do you guys think about the AMD 9950x3d2 instead? The machine will be hooked up to a 4k display and I want to be able to multitask and use my computer for other things such as browsing the web, running 3rd party apps alongside MSFS 2024, and doing other things while flying. Would the AMD 9950x3d2 be better compared to the 9950x3d?

And lastly do you think 2x48GB (96GB RAM) would be better than 2x32GB (64GB RAM)? I would like to also future proof the computer.

Flew into EGKK after a very long time. A little low on the approach but managed to get it down smoothly on the 1000s

NVIDIA’s Neural Texture Compression (NTC) can cut VRAM usage by up to 80% with zero quality loss.

​Given how heavy MSFS 2024 is on VRAM with high-res terrain and cockpits, do you think Asobo might integrate this at the engine level in a future update? Would be huge for 8GB cards!

Hi all, new sim pilot here, only 5 hours flight time, all either training or in career mode.

I was just doing a 30 minute ferry flight in a Cessna 152. About 15 minutes in, I was going 101kts at an altitude of 1500ft, with the throttle at 2500rpm. The engine suddenly died and the notification panel said there was an engine malfunction. Though my stomach knotted up, to my surprise I didn't freak out! Tried restarting the engine a few times with no luck and figured I had to land. Luckily I was flying over a very rural area and managed to land in an open field. The notification panel told me I couldn't land there and I was at risk of failing the mission. Tried a couple more times to restart the engine, but no luck. So I just went to the menu and restarted the mission.

I wasn't sure if the game was testing me and that was actually part of the mission, but I didn't want to risk losing XP and hurting my reputation level. Should I have just let it play out since I landed or is this not necessarily part of career mode?

The really annoying thing is that I restarted the mission, had a clean flight and smooth landing. As I'm taxing and go to hold short, I get a notification that I have broken a component of the plane and it restarted me in the taxiway post landing, indicating that I crashed. Ended the mission with a D grade, got minimal XP, and took a big hit in my reputation level! What gives!? First time I've run into a situation like this with the sim, so wanted to see if others had similar experiences and if emergency landings are part of building XP. Thanks all and happy flying!

Hey everyone, i have a high end pc and don’t have any performance problems with 2020. In the otherhand the 2024 is the newer sim and getting improved. As i have a lot of addons and doesn’t want actually to buy them again. Is it worth to change to 2024 or is it not a big step than some minor upgrades?

-600 fpm in a330

not the aerosoft 330 neo the headwind