Jump to content

Archived

This topic is now archived and is closed to further replies.

KingGhidorah

Question about CPU priority of mce.exe

Recommended Posts

Hi,

 

I was having some problems where the F.O. was having these massive pauses in his flows, even though the "pause" in between commands in the script was set to 1 or 2.  Sometimes he would pause for a full minute or two before going on to the next thing, and it was really starting to impact the flight.

 

I changed the CPU Usage slider in the GUI around and didn't see any improvement.  I have no idea where to set it for optimal performance.

 

Finally, I went in and forced the processor priority of mce.exe to HIGH.  On my machine, FSX normally runs at ABOVE NORMAL.  I don't know if this will benefit anybody else by knowing this information, and I'm unclear if there is any downside to doing this.  It seems to improve things, and I don't have any more lags.  I have yet to do thorough tests to see if FSX itself will experience lags in certain situations as a result.  I guess it's a tradeoff.  For what it's worth, I had to do this with other programs such as Reality-XP and Ezdok as well, or otherwise those will experience lags and stutters, but I have no discernable ill effects from setting them to run one notch higher than FSX.

 

But then, what is the proper way of using the CPU usage slider in the GUI?  What does it do?  I have it set to the default value of about 1/3, but I can't find anything in the documentation that tells me any more about what it is doing.  Can you (FS++) explain this a little more, please?

 

Really excellent program, by the way, and certainly breathing a lot of new life into my sim, which had become rather stale as of late.

Share this post


Link to post
Share on other sites

Hi,

 

I was having some problems where the F.O. was having these massive pauses in his flows, even though the "pause" in between commands in the script was set to 1 or 2.  Sometimes he would pause for a full minute or two before going on to the next thing, and it was really starting to impact the flight.

 

I changed the CPU Usage slider in the GUI around and didn't see any improvement.  I have no idea where to set it for optimal performance.

 

Finally, I went in and forced the processor priority of mce.exe to HIGH.  On my machine, FSX normally runs at ABOVE NORMAL.  I don't know if this will benefit anybody else by knowing this information, and I'm unclear if there is any downside to doing this.  It seems to improve things, and I don't have any more lags.  I have yet to do thorough tests to see if FSX itself will experience lags in certain situations as a result.  I guess it's a tradeoff.  For what it's worth, I had to do this with other programs such as Reality-XP and Ezdok as well, or otherwise those will experience lags and stutters, but I have no discernable ill effects from setting them to run one notch higher than FSX.

 

But then, what is the proper way of using the CPU usage slider in the GUI?  What does it do?  I have it set to the default value of about 1/3, but I can't find anything in the documentation that tells me any more about what it is doing.  Can you (FS++) explain this a little more, please?

 

Really excellent program, by the way, and certainly breathing a lot of new life into my sim, which had become rather stale as of late.

 

Thanks for the accolade.

 

If you click the blue "?" icon and follow that with a click on any item on the user interface, you should hear an audio explanation about what the item does.

 

The CPU slider is the amount of CPU power you decide to allocate to the speech recognition engine. 

 

You may think the maximum value is the way to go, unfortunately it's not that simple. Based on years of experience with the speech engine, it appears the more resources you give it, the more probabilities it computes ending sometime with the speech engine hesitating between two possible recognitions and not returning success. Default values should work fine for the majority of users.

 

The scripted flows are executed on a low priority background thread. And yes, if FSX process priority is raised it may impact on those threads. Don't forget, when FSX runs in full screen mode, Windows will boost FSX thread priorities even if the process is in normal priority. I think you should leave FSX at normal priority.

 

Be aware, with option "Enable optimizations" switched on, MCE will set its affinity to avoid executing on specific cores depending on the CPU.

 

For a dual core CPU, MCE will stay clear of core 0

For a quad core CPU, it will stay clear of cores 0 and 1

 

If you have a heavily fine tuned sim with custom affinity mask, you may want to disable the MCE "optimizations" and let the OS decide where the MCE threads run. You may want to also make sure Hyperthreading is disabled so that all threads execute on physical cores rather than logical ones.

Share this post


Link to post
Share on other sites

I may have spoken too soon when I declared I had a workaround (with the high pri thing).  It seemed to have some promise on some less resource demanding aircraft, but it didn't work at all on the NGX, and it didn't work for anything tonight.  Still getting massive lags with all the crucial flows--flows that should take 30 seconds are taking up to 2 minutes, and that is really bad, especially for things like before-landing flows.

 

Therefore I'm back to square one. :( I'm no longer messing around with the processor priorities and have simply been trying to find the optimal position of the cpu usage slider, and also experimenting with the Optimizations tickbox on or off as you've suggested.  No luck.

 

I can't think of what kind of a problem this might be other than that the Flow Scripts are just getting starved of the cpu cycles they need to run in a timely manner, even though there appears to be resources to spare.  As much as I love having a copilot be able to set all the things by direct command, and it's working extraordinarily well, I also want to get the automated flow parts working just as well too. Has anybody else ever reported similar problems?  Any suggestions as to what the next step I might take?

 

Machine is: 990x, 4.3ghz, 6 core, 6g of fast memory, Win7x64.  Hyperthreading is disabled.  Machine is totally devoted to, and very optimized for FSX, and it runs it well under almost all circumstances.  Always run in full screen mode.  Also alongside FSX are Track-IR, Acufeel, and ezdok.  Weather program and other stuff is run on a networked machine, so that shouldn't be a problem. MCE is version 2.5.3.8, the latest.

Share this post


Link to post
Share on other sites

Not sure, I run quite a few program's in the background, inc,using MCE and have to fps impact whatsoever. Maybe reinstall or refresh?

Share this post


Link to post
Share on other sites

Not sure, I run quite a few program's in the background, inc,using MCE and have to fps impact whatsoever. Maybe reinstall or refresh?

 

I don't have any fps impact whatsoever either. Something like the NGX or the md-11 run at their normal 30 locked fps just like they normally do. The issue is that MCE will suffer massive pauses when it is running a VoxScript, and I'm pretty sure it is, as FS++ said, because those VoxScripts are set to run at a low priority background task.  They are not getting the CPU cycles they need, and the CPU Usage slider on the GUI is not helping.  I even tried something called Process Lasso, which is a third party CPU scheduler, and it didn't do anything better than the standard scheduler. If this is indeed what is going on, I'm not sure there is anything I can do about it, as my machine is already as well-tuned as I know how to make it.   Since I don't know anything about multi-threaded programming, I'm in no position to know whether something could be further optimized on the developer side or not, but I'm almost positive that there is little I can be doing better on my side.   I'm certainly open to all suggestions though as to what else could be going on, because I really like this program and want it to perform as good for me as it apparently does for most others. :P

Share this post


Link to post
Share on other sites

I don't have any fps impact whatsoever either. Something like the NGX or the md-11 run at their normal 30 locked fps just like they normally do. The issue is that MCE will suffer massive pauses when it is running a VoxScript, and I'm pretty sure it is, as FS++ said, because those VoxScripts are set to run at a low priority background task.  They are not getting the CPU cycles they need, and the CPU Usage slider on the GUI is not helping.  I even tried something called Process Lasso, which is a third party CPU scheduler, and it didn't do anything better than the standard scheduler. If this is indeed what is going on, I'm not sure there is anything I can do about it, as my machine is already as well-tuned as I know how to make it.   Since I don't know anything about multi-threaded programming, I'm in no position to know whether something could be further optimized on the developer side or not, but I'm almost positive that there is little I can be doing better on my side.   I'm certainly open to all suggestions though as to what else could be going on, because I really like this program and want it to perform as good for me as it apparently does for most others. :P

 

Agree, it’s very likely a case of a thread being starved of CPU time.  And it appears to be caused by the fact you are overriding all the various processes priorities.

 

Suggest you run everything at their native process priorities (including EZDock). See if you experience any of that.

 

If you become a registered user, we don’t mind giving you some options (via mce.ini) to increase the Voxscript thread priority in order to accommodate your specific usage scenario.

 

Multi-threading is extremely complex and is the main reason why even after 8 years of development, we always find something that needs to be improved on. Things aren’t happening in sequence, threads need to acquire and release locks. There is room for lockups and race conditions, something you don’t see on a single threaded application.

 

Now, you may wonder why we are running MCE as an external application, when we could have made it run inside the simulator, via our “fsInsider.dll”.

 

In early days we did so, but quickly realised it’s not a safe thing to do. The speech engine and the audio dlls alone will gobble-up about 500 MB of the precious virtual address space, whose 4 GB limit is often the cause of many CTDs (remember FSX is still a 32 Bit process).

 

We would have to heavily restrict what the user says, to avoid scenarios where a single unexpected voice command brings the whole simulator down, never mind the fact that over a long period of time, the speech engine might leak memory or become unresponsive leaving you with a crippled FO with no option but to restart the flight.

 

With the current design, should anything wrong happen with our app, the integrity of the flight, which is the most important thing, shall never be compromised as a result of MCE or the speech engine. It’s bad enough for FSX to deal with issues thrown at it by sceneries, weather and aircraft add-ons which don’t have the luxury to decide where they run.

Share this post


Link to post
Share on other sites

Thanks FS++.  At the start of this thread, I had said I was changing the process priority of several things.  Maybe I wasn't clear earlier, but since that time, however, I have reverted to running everything at their Native priorities, just as you had suggested--I am not running anything (not FSX, ezdok, TrackIR, or anything else) at any forced priority as of now, but the problem has persisted.   My product is payed for, licensed, and activated, so if there are unique solutions available within the mce.ini, it's definitely time for me to try them out.   I did encounter the problem during the demo period, but I went ahead and gambled on the purchase anyway, hoping that there is something I can still do.

 

Regarding deadlock conditions in CPU scheduling, I once heard someone use the analogy of an archaic law from the 1800's.  It said, "When two trains meet at a rail intersection, neither one shall move until the other one has left." :P

Share this post


Link to post
Share on other sites

Thanks FS++.  At the start of this thread, I had said I was changing the process priority of several things.  Maybe I wasn't clear earlier, but since that time, however, I have reverted to running everything at their Native priorities, just as you had suggested--I am not running anything (not FSX, ezdok, TrackIR, or anything else) at any forced priority as of now, but the problem has persisted.   My product is payed for, licensed, and activated, so if there are unique solutions available within the mce.ini, it's definitely time for me to try them out.   I did encounter the problem during the demo period, but I went ahead and gambled on the purchase anyway, hoping that there is something I can still do.

 

Regarding deadlock conditions in CPU scheduling, I once heard someone use the analogy of an archaic law from the 1800's.  It said, "When two trains meet at a rail intersection, neither one shall move until the other one has left." :P

 

:lol:  :lol:

 

Nice one!

 

Apologies for wrongly assuming you were running the Demo.

 

You may well be onto something after all.

 

Ben has just confirmed there is something that may corroborate your observation.

 

It's more likely to affect scripts that have "reset trim" as part of the flow.

 

Hopefully a fix will follow before the week-end.

 

Thank you

Share this post


Link to post
Share on other sites

 

 

It's more likely to affect scripts that have "reset trim" as part of the flow.

 

Hopefully a fix will follow before the week-end.

 

 

 

This is good news!  One of the things I noticed on the NGX, and I don't know how much it helps, is that any script involving the Runway Turnoff Lights and/or Taxi Lights also tend to make the FO go temporarily dormant. I don't believe I've actually run any Voxscripts that had reset-trim as part of the flow.  I've done some initial run-throughs with the md-11 and the J-41, but not any complete flights from start to finish, so I can't identify any particular places that they have problems. 

Share this post


Link to post
Share on other sites

This is good news!  One of the things I noticed on the NGX, and I don't know how much it helps, is that any script involving the Runway Turnoff Lights and/or Taxi Lights also tend to make the FO go temporarily dormant. I don't believe I've actually run any Voxscripts that had reset-trim as part of the flow.  I've done some initial run-throughs with the md-11 and the J-41, but not any complete flights from start to finish, so I can't identify any particular places that they have problems. 

 

New package now ready for download.

 

 

http://www.multicrewxp.com/Downloads.html

Share this post


Link to post
Share on other sites

I'm sorry to have to report this FS++. but using the new version 2.5.3.9 causes the performance lags when executing flows to be signifigantly worse than even before.  For example, the NGX "After Start Flow", included with MCE, took a full 3 minutes to complete, with painful pauses between each item.  Before it was probably taking a minute and a half.  If the Flow was going at the pace it should, it really shouldn't take more than 30 seconds, as it's just a couple of items.  Other flows also took much more time than they even were before in the previous version.  It will actually be difficult using the scripted flow capability at all now, but continuing to use this new version is a tradeoff with the good fixes made to the derated takeoff problem discussed in the other thread.  So what do we do now?

Share this post


Link to post
Share on other sites

I'm sorry to have to report this FS++. but using the new version 2.5.3.9 causes the performance lags when executing flows to be signifigantly worse than even before.  For example, the NGX "After Start Flow", included with MCE, took a full 3 minutes to complete, with painful pauses between each item.  Before it was probably taking a minute and a half.  If the Flow was going at the pace it should, it really shouldn't take more than 30 seconds, as it's just a couple of items.  Other flows also took much more time than they even were before in the previous version.  It will actually be difficult using the scripted flow capability at all now, but continuing to use this new version is a tradeoff with the good fixes made to the derated takeoff problem discussed in the other thread.  So what do we do now?

 

It’s very strange. I can assure you we’re not getting those pauses with any aircraft even with a dual core processor.

 

Would appreciate if other users could chime in.

 

As suggested earlier, in case the optimisations aren’t working as expected, disable option “Enable optimisations” in UI and restart MCE.

 

Can you confirm the following?

 

Right-click “fsx.exe”, select properties, compatibility tab and check if “Run this program as admin” option is ticked.

 

What is the FSX installation path?

 

What is MCE installation path?

 

I just want to make sure MCE is able to communicate with the sim as expected.

 

I must admit, not using a 6 core CPU over here (only dual and quad core). Would it be possible to disable 2 cores via the Windows 7 "Run" command, and msconfig and see how MCE behaves?

 

 

Thank you.

Share this post


Link to post
Share on other sites

I always run FSX through a batch file created by the utility program "fps_limiter_0.2" which limits my frames to 30 but allows FSX to be internally unlimited.  Frames are all over the place if I don't, and the Nvidia frame limiter is a poor substitute.  I always run that batch file by right clicking on the Run As Administrator, and I've always assumed that would make the children of the batch file also inherit admin priveledges.  However, as I look the fsx.exe properties, the box is NOT checked.  Neither is it checked on mce.exe.

 

All of my programs were definitely at least installed by explicitely running as adminstrator.  And UAC is definitely disabled.

 

Before I mess around with disabling cores or Affinity Mask, I'll see what happens when i check the Administrator boxes, first with FSX, and then with MCE.  I'll try the disabling of cores thing as a next step if I have to.

Share this post


Link to post
Share on other sites

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! 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

 

 


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.

Share this post


Link to post
Share on other sites

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..

Share this post


Link to post
Share on other sites

 

 


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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

 

 


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?

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

×
×
  • Create New...