Question about CPU priority of mce.exe

[KingGhidorah 209]

Checked the box for Run FSX as Administrator.  Even though I had thought I had been correctly running FSX as administrator for literally years, I must not have been.  The results were dramatic, and unexpectedly good.  The After Start Flow that had previously taken 3 minutes, took only 40 seconds.  The Runway entry procedure which had taken at least a minute for him to flip 5 switches, now took only 10 seconds, as it should.  After Takeoff and Clean up flows went similarly quickly.  I took several short flights to confirm that is wasn't just a fluke.

 

It appears that the scripted flows are suddenly performing as advertised now, and all because of that stupid checkbox!  Were you expecting that this would make all the difference?  Also, should I also tick the Run as Administrator box for mce.exe, or better off just leaving it unchecked, as it is?

 

Thanks so much for your help!  Really glad to have gotten this all finally working, performance lags in the flows gone, reduced thrust takeoffs etc.  So glad that I got this program! 

 

 

I wish that Avsim would allow people to delete posts older than a few hours, when they turn out to misleading.    When I wrote the above several hours ago, I really thought I had the problem beat, and was exuberant about it.  I had flown 3 short flights in the PMDG 737, and the FO just breezed through the flows.  It worked great!  Now, it's not.  We're back to slow and virtually unusable again.  I really don't know why it worked so well before, but it could have something to do with the way I started MCE in those 3 flights.  In my haste to test I'm pretty sure I had started MCE before the NGX had initialized so that I wouldn't have to go back and forth between full screen and windowed.  The flows worked great, but I if I do it that way, the FO isn't able to set accurate speeds and altitudes on the MCP, so it's not a viable way to run MCE.  At least I think that is what must have happened because it sure isn't working well now, but I'm tired of looking for the solution.

 

I think I'm going to just give up on trying to use MCE for the NGX until I get a different or more powerful system.  MCE seems to work very well for a number of other planes, and I love it, but it certainly looks like there is just something my system doesn't like when MCE scripts and NGX are run at the same time.  I can still always use the FO to do things by direct command too, but the flow scripts are obviously not compatible.  Thanks a lot for your help though FS++, and sorry for the premature reports of success.

[WR269 367]

So your problem is only on the 737-600/700 or the 800/900 as well? This is very odd, I have no issues whatsoever.

 

What about in the MD-11? Same problem?

[KingGhidorah 209]

So your problem is only on the 737-600/700 or the 800/900 as well? This is very odd, I have no issues whatsoever.

 

What about in the MD-11? Same problem?

 

All the NGX variants are demonstrating these script lags.  The only difference between the 600/700 and the 800/900 was the unrelated issue of reduced thrust takeoffs and call outs, and that problem is now fully resolved as of the recently released 2.5.3.9 version of MCE.

 

The MD-11 was the first airplane I tried out when using MCE (first as a demo) and I was primarily concerned about making it compatible with words like "Autoflight" and "Profile".  I never ran through any of the major flows in a fully realistic flight, start to finish, and I would have to revisit it to tell whether they lagged or not, but I didn't notice anything previously that caught my attention.  I'm going to have to check that out further, and I'll do it right now............

 

Just checked it.  Didn't actually take off, but ran through all the major flows from pre-flight to shutdown.  I changed the Preflight to verbose, to be able to monitor better, and the FO ticked through the items exactly at the interval specificied in the script.  No lags on that flow or any other that I could see.  Performed much better on the MD-11 than the NGX, at least when running through the flows on the ground.  I would have to have many complete flights to be able to answer your question definitely about the MD-11, but I think the answer is no, I'm not having the same problem.  But then again, I thought earlier that I was out of the woods on the NGX too, and the next time around, it was back to square one, so I have to be careful about making premature assesments.

 

You guys have been more than helpful, and I really do appreciate it.  Even if I can't get to the bottom of it with the NGX, it's still quite nice to have an FO that can do non-scripted commands to work things like the flaps, gear, and radios.

[FS++ 707]

 

 

I think I'm going to just give up on trying to use MCE for the NGX until I get a different or more powerful system.  MCE seems to work very well for a number of other planes, and I love it, but it certainly looks like there is just something my system doesn't like when MCE scripts and NGX are run at the same time.  I can still always use the FO to do things by direct command too, but the flow scripts are obviously not compatible.  Thanks a lot for your help though FS++, and sorry for the premature reports of success.

 

It works very well with the NGX too. You may need to start MCE after the NGX has initialized.

 

Apart from that here are a couple of things you could try...

 

If you don't want to go back and forth between full screen and Desktop, set MCE to automatically startup when FSX starts. And to prevent the UI from drawing in the background and all, suggest you set the options in "mce.ini" (C:\Users\your_user_name\AppData\Roaming\Multi Crew Experience\) as follows

 

[Window]

NoFullScreenDraw=1

NoActivate=1

StartToTray=1

 

Don't forget to save the file.

 

If still having the issue with the NGX, you will probably need to un-install MCE and re-install to the default :\Progra Files...\ folder.

 

Part of the issue is that recently (since version 2.5.3.8) we are trying to understand Windows UAC better, and decided to give users the option to keep UAC enabled.

 

However, since we set "mce.exe" ourselves to require administrative privileges, it is very important that any simulator (FSX, P3D, FS9) MCE communicates with must be set to run as admin.

[KingGhidorah 209]

It works very well with the NGX too. You may need to start MCE after the NGX has initialized.

 

Apart from that here are a couple of things you could try...

 

If you don't want to go back and forth between full screen and Desktop, set MCE to automatically startup when FSX starts. And to prevent the UI from drawing in the background and all, suggest you set the options in "mce.ini" (C:\Users\your_user_name\AppData\Roaming\Multi Crew Experience\) as follows

 

[Window]

NoFullScreenDraw=1

NoActivate=1

StartToTray=1

 

Don't forget to save the file.

 

If still having the issue with the NGX, you will probably need to un-install MCE and re-install to the default :\Progra Files...\ folder.

 

Part of the issue is that recently (since version 2.5.3.8) we are trying to understand Windows UAC better, and decided to give users the option to keep UAC enabled.

 

However, since we set "mce.exe" ourselves to require administrative privileges, it is very important that any simulator (FSX, P3D, FS9) MCE communicates with must be set to run as admin.

 

I think I was always running FSX as Admin, but FSX is now set to Run As Admin in the properties window tick box, and despite my reports of inital success, I think the scripts only ran smoothly because mce wasn't fully connected somehow to the NGX, due to the order I started them...the MCP altitude and speed were not being set correctly.  Like I would ask for 120 and get 230, or ask for 5000 and get 10000.  When I do it the "right way", starting MCE only after NGX has gone through its 20 second initialization countdown, those long pauses in the scripts were back with a vengeance, whether explicitly set to run as Admin or not.

 

My FSX is installed in a custom folder on the D drive, which is an SSD.  My MCE installation is also on the D drive, in D:\Program Files (x86).  I can't easily change where FSX is, but I can reinstall MCE onto the default C:\Program Files (x86), if you think it will make a difference. Since I don't have UAC enabled anyway, I don't understand how these non-default directories would be causing a problem..

[FS++ 707]

 

 

My FSX is installed in a custom folder on the D drive, which is an SSD.  My MCE installation is also on the D drive, in D:\Program Files (x86).  I can't easily change where FSX is, but I can reinstall MCE onto the default C:\Program Files (x86), if you think it will make a difference. Since I don't have UAC enabled anyway, I don't understand how these non-default directories would be causing a problem.

 

MCE interfaces the PMDG MD-11, J41, 747, Aerosoft AXE, and many others directly, whereas with the NGX it uses the PMDG SDK. That means the NGX needs to be fully initialised before MCE can talk to it.

 

Please go ahead and install MCE to the default folder, and make sure you start “fsx.exe” directly.

 

If that works as expected, we can then concentrate on the batch file and what it does.

 

Just setting the batch file to run as admin isn’t a guarantee that “fsx.exe” will run as admin.

 

In the long run, both of us will benefit from this mishap.

 

We are seeing the implications (side effects) of changing things to allow people to keep UAC enabled.

 

You could probably discover that “EzDock” and the other utility that were exhibiting some stutters could have been the victims of the same thing.

 

In any case, it’s no longer a multi-threading issue, or hardware related issue.

 

No need to modify any of your FSX settings either.

 

I believe it’s an issue with two applications, MCE and FSX, running at different privilege levels. And Windows security hates that. I agree with you, I would assume it doesn’t matter when UAC is disabled. It appears, it’s not the case when both applications are installed outside the default C:\Program Files…\ folder

 

Would appreciate more info about the batch file and the process it triggers.

[KingGhidorah 209]

Limiting the frames within FSX is a terrible performance drain for me and others.  Good results have been obtained by setting FSX to run "unlimited", but then using an external program to limit the fps to 30 fps.  The frame limiter is simply called FPS_limiter_0.2, that was once pretty commonly used, but maybe not so much now that Nvidia Inspector includes an option to externally limit frames.  I continue to use this one, because it works better. 

 

My batch file for fps_limiter contains only: start E:\"AdminDesktop\FPS Limiter FSX 30\"FPS_Limiter.exe /r:D3D9 /f:30 /x:OFF /l:OFF "D:\Microsoft Games\Microsoft Flight Simulator X\fsx.exe. 

 

Here is a link to the fps_limiter_0.2: http://aussiex.org/forum/index.php?/topic/7488-utilities-fps-limiter-02/  in case somebody wants to understand how it works.   The package creates a small directory, containing a couple of .dlls which are activated by the batch file, but beyond that I have no idea of how it works with dx9.

 

Meantime, I will do some test flights with my new installation of MCE on C Drive and also see how mce scripts behave when fsx.exe is run directly.

[KingGhidorah 209]

I have some results.  MCE is in the default location on C drive.  UAC was of course verified to be off, as it always is.  Realtime virus protection was turned off.  FSX was run directly as administrator, no frame limiting or batch files.  Ezdock and Trackir were also running alongside, at their native priorities.  MCE was started correctly after the NGX had fully initialized.

 

Starting out with the engines already running, my first flight was a really short one, and it went exceptionally well,aside from some erratic fps, due to the lack of frame limiting.  Flows had some tiny lags, but I was on the verge of calling it a success.  I then rebooted and flew another flight, also engines already running.  I immediately stalled on the After Start Flow.  It took close to 3 minutes, although I've seen it run in less than a minute on a good day.  Runway Entry Procedure only took ten seconds, so it was as it should be.  The After Takeoff Flow took a full 30 seconds to start and the first couple of items there were massive pauses.  The whole flow ended up taking close to 2 minutes.  At this point I terminated the flight because the problem, whatever the heck it is, had been demonstrated to still exist.  

 

Other than the differing complexity of terrain, or the amount of third party aircraft scheduled to be taxying at the start of any given flight, I really am completely stumped why some flights go really well, and some don't.  I apologize for taking so much of your time, because it appears that no one else has ever encountered such problems, or if they have they just haven't reported them.   It's starting to appear that this might just be one of those things that can't be fixed, or maybe the NGX just uses up too much of my system.

[FS++ 707]

 

 

I apologize for taking so much of your time, because it appears that no one else has ever encountered such problems, or if they have they just haven't reported them. It's starting to appear that this might just be one of those things that can't be fixed, or maybe the NGX just uses up too much of my system.

 

You can take the NGX out of the equation.

 

If using Ultimate traffic, you may want to avoid running at very high traffic settings.

 

I guess, you could return to using the FPS Limiter, provided you set "FPS_Limiter.exe" to run as administrator.

 

What about temporarily removing the custom FSX affinity mask?

[KingGhidorah 209]

FS++, on 17 Jun 2013 - 10:54 AM, said:

 

You can take the NGX out of the equation.

 

If using Ultimate traffic, you may want to avoid running at very high traffic settings.

 

I guess, you could return to using the FPS Limiter, provided you set "FPS_Limiter.exe" to run as administrator.

 

What about temporarily removing the custom FSX affinity mask?

I use My Traffic at very low levels of traffic and low poly models, but depending on where and what time of day the flight is, there obviously might be more stuff at the gate. The amount of AI flying around is so low that I really don't think that is the problem, but I just threw that out there because I don't know why it works well on occasion, but most of the time it doesn't. I don't use Affinity Mask tweaks, all 6 cores are in action. I tried the suggestion where I temporarily disabled 2 cores with msconfig, and it didn't make any difference that I could see.

 

When you say take the NGX out of the equation, that's hard to do, because it's the primary plane I use. But I agree, that it looks like there is little else to be done, and I guess I can still get some use out of MCE on the MD-11 and maybe the Jetstream. If the Flows can't be made to work for me, FS2Crew is probably the better option for the NGX, but I must admit, I don't like the strictly scripted flight phases and unforgiving phrasing that I've experienced on the FS2Crew Jetstream.  I do prefer the flexibility that MCE provides.

 

Do you anticipate that there might be any changes in the future to MCE in the way voxscripts demand attention from the cpu, or is it truly time to give up on NGX+MCE Flows?

[FS++ 707]

When you say take the NGX out of the equation, that's hard to do, because it's the primary plane I use

 

Sorry for the confusion.

 

What I meant by that, I don’t see the NGX as being the source of the issue, so that one can be ruled out. Except maybe for third party liveries

 

And to rule that one out too, could you do a test with stock PMDG livery, just to see?

 

A lot of MCE users fly the NGX exclusively. And because MCE runs outside the FSX process, you won’t even need to reduce aircraft or scenery (and weather) quality settings in order to give room to the speech engine.

 

 

It’s possible the changes made recently to allow MCE to run with UAC enabled, may have had unexpected results. At the very least, will send you a replacement “mce.exe” compiled differently (same source code).

 

Would it be possible to temporarily run at stock CPU speed without the overclock.

 

I know you could argue it was running fine before. Don’t forget, now you have the sound device running at higher stress levels. With FSX it’s only sound OUT in action. Here it’s constantly IN and OUT.

 

If using a USB headset, ensure it’s connected straight to the back of the PC and not to the front connectors (which sometimes don’t deliver the required power output the built-in USB sound device needs) nor via a USB hub.

 

If using a conventional headset (3.5 mm jacks), thus using the built-in sound device, under Windows 64 Bit, I strongly recommend you use the Windows certified sound drivers instead of the third party ones, especially with Realtek HD audio.

 

We could eventually give you the option to raise the priority level of the script manager thread, at least to try out. But first, try the suggestions above.

 

Just need more feedback until it’s nailed down

[FS++ 707]

I use My Traffic at very low levels of traffic and low poly models, but depending on where and what time of day the flight is, there obviously might be more stuff at the gate. The amount of AI flying around is so low that I really don't think that is the problem, but I just threw that out there because I don't know why it works well on occasion, but most of the time it doesn't. I don't use Affinity Mask tweaks, all 6 cores are in action. I tried the suggestion where I temporarily disabled 2 cores with msconfig, and it didn't make any difference that I could see.

 

When you say take the NGX out of the equation, that's hard to do, because it's the primary plane I use. But I agree, that it looks like there is little else to be done, and I guess I can still get some use out of MCE on the MD-11 and maybe the Jetstream. If the Flows can't be made to work for me, FS2Crew is probably the better option for the NGX, but I must admit, I don't like the strictly scripted flight phases and unforgiving phrasing that I've experienced on the FS2Crew Jetstream.  I do prefer the flexibility that MCE provides.

 

Do you anticipate that there might be any changes in the future to MCE in the way voxscripts demand attention from the cpu, or is it truly time to give up on NGX+MCE Flows?

 

UPDATE: Please postpone implementing the suggestions above and wait for an updated package coming out tomorrow.

 

Ben (my colleague) decided to do a stress test on the Voxscript flow, using as many clues you provided, and for the first time he was able to see the lag. It has to do with freeing some SAPI resources. And it's quite random. Sometimes no lag, other times up to 10 seconds lag.

 

Part of the issue is that we alternate development platform between Windows 7 64 Bit, Windows 8 64 Bit and Windows XP 32.

 

It's something you can't see under XP, or Windows 7 when debugging with UAC disabled for example.

 

A change will be made, and we'll see how it behaves next.

[FS++ 707]

 

 

Do you anticipate that there might be any changes in the future to MCE in the way voxscripts demand attention from the cpu

 

 

Hopefully this will address the issue. Download, unzip and replace "mce.exe" inside \Multi Crew Experience\ installation folder.

 

http://www.multicrewxp.com/mce2540.zip

 

Waiting for feedback.

[KingGhidorah 209]

Hopefully this will address the issue. Download, unzip and replace "mce.exe" inside \Multi Crew Experience\ installation folder.

 

http://www.multicrewxp.com/mce2540.zip

 

Waiting for feedback.

 

Thanks, I'll try it out as soon as I can and let you know as soon as I do.  Excellent support, and I really appreciate that!

[KingGhidorah 209]

I checked 2.5.40 out with thoroughness, and I have some mixed results.

 

First, I ran it in the normal way (with fps_limiter) after a clean system reboot.  It ran very well.  Then the phone rang, and I had the simulation on pause for a half hour.  When I returned, I re-ran the after takeoff flow.  The resulting flow took about 2 minutes, and it should be about 30 seconds.

 

Then I restarted FSX and repeated the same flight, but experienced lags right from the beginning.  I tried it again running straight from the fsx.exe, and had bad results.  I contined, in subsequent flights, a number of combinations of things we've previously discussed, with generally no difference noticed from the behavior of the last version, 2.5.39.  One thing I did notice was that mce always performed better after a clean reboot of the machine, and got worse after each subsequent run of FSX.

 

Then I rebooted and decided to change the way I started MCE, just on a theory.  Because the NGX requires a 20 second initialization, and I run in full screen mode, I was starting it like this--  Start NGX, let it initialize, hit alt-enter to go to windowed, start MCE and wait for it to fully initialize, then alt-enter to go back full screen with the NGX.

 

I changed to doing this--  Start NGX and let it initialize, alt-enter to windowed mode, start MCE, and very quickly, immediately, go back FSX in full screen before MCE has initialized.  I started to notice that if I can get FSX back in full-screen before I see "looking for changes to current aircraft...please wait" that the mce voxscript flows were noticeable less laggy.  I found there was no difference in this improved performance of the mce flows, whether I ran with fps-limiter or not, or if I did a system reboot in between FSX flights.  I flew the same short haul flight 5 times in a row, restarting FSX each time and experienced good performance.  Not perfect performance.  There were some minor lags, but none of the "40 second flows" (such as the after start flow) stretched over a minute and I could generally get Clyde back on track by saying "are you there" or "are you done with your flow?"  I even had good results after letting the sim sit in Pause for an hour before the Shutdown procedure on the 5th flight, just to test if there was some sort of leak going on.

 

Does this sound crazy?  I mean, could there be a difference in the quality of the communications between FSX and MCE depending on whether FSX is in full screen or windowed mode when MCE first comes on line?  I know it sounds unlikely that this makes any difference, but this is what I saw.

 

I'm not drawing a conclusion. Just reporting what I saw with this new version over the course of several flights.  B)