FMC change in flight

[TXGrunt]

Hello all! I know this issue has been stickied already. I just ask that you hear me out first. 

I am currently running XP11.11 and fired up the 73. Shortly after takeoff, I had to make a small change to my route. It was going to be a simple replacement to my leg. When I clicked to make a change, the simulators performance dropped dramatically. I was getting 1 FPS stutters and the response was extremely slow. 

With that being said, I am not currently running any kind of anti-virus program such as norton, etc. The only thing I have on is windows-defender. Thats it. 

So, I am just curious, if there is a fix and if anybody else has had this problem.

Log.txt

[Cameron]

Windows Defender is precisely what we address in these forums and is what's causing your issue.

You need to make an exclusion as outlined in the sticky post.

[mmerelles]

Windows defender is and was always the main problem. Despite antivirus issues having same behavior than windows defender.

 

You need to go to windows defender configuration and set a FOLDER exemption for the entire /xplane 11/ root folder.

note: it is a folder exemption for the entire xlpane root folder, not a file exemption.

[TXGrunt]

Man oh man... Thank you....

[Ben Russell]

For what it's worth I personally _hate_ that this "Defender exclusion" is the solution we have to recommend.

 

The main reasons we recommend this are;

 

1. The FMC code is still a work in progress. Tom is mostly responsible for this part of the project.

It's a complicated beast and subject to major reworks as he learns more and fixes bugs.

I could get in there and optimize all this away, breaking the code down from something an engineer has created to be "as correct as possible" into something that would run "as fast as possible".

This might take me a few days or weeks depending on how long it takes me to understand the system and then re-verify that it works correctly through either automated tests or team playtesting. 

Then Tom might decide that the FMC code is all wrong and throw it away so that he can add more features or correct some critical flaw. ('cause lets be honest, the FMC has had more than its fair share of "Gizmo Errors" over the last year or so...)

The end result is that we'd be back to another "engineers version" that's correct but probably slow again.

Teaching Tom the depth of knowledge required to understand the requirements of a fast gaming loop and how to shard the work is also not really an option for either of us at this time. We have other commitments meaning that our time is genuinely better spent elsewhere.

So, for now, I have to sit back and let him focus on the "as correct as possible" unti the point that the IXEG team decides that it's functionally complete.

If they were to make this call tomorrow I would look at optimization immediately as this issue stinks from both a user experience perspective and a system security(placing an exclusion on the X-Plane folder means other plugins for other products will be ignored by Defender*) perspective.

 

2. Lua JIT.

We use Lua JIT to run our systems code as fast as possible. The JIT engine marks a large block of RAM as write+exec.... it _must_ do this to be able to do it's job, that of translating Script into Machine Code on the fly. 

We could move to straight Lua and this issue would go away but frame rates would likely plummet. Something no one wants.

 

Sometime in the future this will no longer be an issue.

Thanks for using our products.