With the NGX loaded, and your script running, tried changing to a different aircraft first before exiting FSX. I get a hang again, as soon as the other aircraft loads. The MCPPro does "turn off', that is go blank, and it seems that is just when I get the FSX hang.So, It seems that this occurs just as the LUA script terminates itself.In the details tab of the force close dialog, it shows the Event as AppHangB1, and the application is FSX.So near to perfection, but still so far. :(* Orest

The event logs are found by:

• Right click the "My Computer" icon (Windows 7 sees it as just "Computer" and is in your start menu).
• Choose "Manage".
• In the far left window pane, click the little arrow next to "Event Viewer".
• Now, click the little arrow next to "Windows Logs".
• Highlight "Application".

That's it. Give it a few seconds and you will see several windows application events. These events happen and are recorded all the time so when an app crashes it's often a good idea to look here. It can sometimes spell out the exact issue and be a great thing (other times, it's pretty vague).Another thing that you could try, especially with it hanging. Is to run in windowed mode so you can have "Task manager" open and monitor it during the hang. Be ready for the hang prior by doing these simple steps:

• (Win7) - Right click the task bar, choose "Start Task Manager" from the list.
• Click on the processes tab.
• You should have a column for "CPU", if not goto "View>Select Columns" and then check "CPU".
• Click "CPU" when viewing the processes page. This should put them in order of CPU usage.
• Monitor this closely. If another application is interfering at some point, you may easily catch it. It will appear second from the top of this list (second to "System Idle Process").

Hope that helps. Even if it doesn't with this particular issue, it can be a lifesaver when finding and fixing FSX issues (actually any Windows issues).

With the NGX loaded, and your script running, tried changing to a different aircraft first before exiting FSX. I get a hang again, as soon as the other aircraft loads. The MCPPro does "turn off', that is go blank, and it seems that is just when I get the FSX hang.So, It seems that this occurs just as the LUA script terminates itself.In the details tab of the force close dialog, it shows the Event as AppHangB1, and the application is FSX.So near to perfection, but still so far. :(* Orest

Hi Orest,I'm assuming this problem started when you installed the script? If so, can you ensure that you have the latest version of FSUIPC (currently 4.754) which you can get here http://forum.simflight.com/topic/66139-updated-modules/ The later versions from 4.70 added LUA facilities that I make use of.Can you also confirm if you have any other LUA scripts running and which NGX SP are you using?Can you also enable LUA logging in FSUIPC (its one of the tabs in the FSUIPC interface), use the NGX and then exit. In the modules directory, you should now see a file called NGX_AUTO.log which you can open in notepad and it will detail any errors that are occurring. Let me know if anything is shown.Finally, you could also try disabling the termination routines in the LUA script by opening the file in notepad, going to the very end and looking for the following code:-- Setup cleanup events for when FSX changes occurif DISABLEMCP == 0 or DISABLEEFIS == 0 then event.sim(CLOSE, "GFQuit") event.sim(AIRCRAFTCHANGE, "GFQuit") event.terminate("GFQuit")endYou can then add two minus symbols to each line so it looks like-- Setup cleanup events for when FSX changes occur--if DISABLEMCP == 0 or DISABLEEFIS == 0 then-- event.sim(CLOSE, "GFQuit")-- event.sim(AIRCRAFTCHANGE, "GFQuit")-- event.terminate("GFQuit")--endSave the LUA script and try again. Let me know if this changes anything.Best wishesSteve

Hi Steve,Mad the same prob.With the lua script running, FSX hung on exit and had to kill with task manager.This occured after installing the SP1b of NGX.I noticed that other lua script didn't affect the FSX closing, only the mcp script.After some fiddling I found a workaround by starting abut especially ending the mcp script mahually by assigning a button and then FSX closed properly.Now I tried your suggestion to dissable the closing lines in script as mentioned above and this also does the job.With those Changes FSX closes propely.I hope this helps you .Regards ...Marc

Thanks Marc, I'll look at the closure routine and see if I can spot what is causing it.Best wishesSteve

FSUIPC 4.751a, it was the latest at the time, will update.No other LUA scripts.NGX SP1a.Will enable the logging (and post the log here), and try remming out the termination routine. It looks like removing the termination routine will work, from the above post.But, standing by to help you sort this out. Will monitor this thread.One other thing, should the EFIS be disabled in the routine, if you don't have one?* Orest

OK, updated to 4.754. Same behaviour. Here is the log with the term procedure active ...********* LUA: "NGX_AUTO" Log [from FSUIPC version 4.754] ********* 55303 System time = 24/12/2011 11:44:48, Simulator time = 11:44:00 (16:44Z) 55303 LUA: beginning "D:FlightSimulatorXModulesNGX_AUTO.lua" 119762 >>> Thread forced exit <<< 119762 System time = 24/12/2011 11:45:53, Simulator time = 11:44:58 (16:44Z)********* LUA execution terminated: Log Closed *********

OK, with the remmed out term routine, no hang, and the routine continues until FSX shutdown. Here is that log ...********* LUA: "NGX_AUTO" Log [from FSUIPC version 4.754] ********* 65988 System time = 24/12/2011 11:53:32, Simulator time = 11:52:33 (16:52Z) 65988 LUA: beginning "D:FlightSimulatorXModulesNGX_AUTO.lua" 168372 LUA: ended "D:FlightSimulatorXModulesNGX_AUTO.lua" 168372 System time = 24/12/2011 11:55:14, Simulator time = 11:53:56 (16:53Z)********* LUA execution terminated: Log Closed *********BTW, small point, I presume that the following line should be:EFIS640 = 0 -- Set to 0 for EFIS Range 5 to 320 or set to 1 for Range 10 to 640Let me also take a moment to sincerely thank you for the outstanding contribution you have made to our community, by developing and supporting this script. The GoFlight folks are seriously lagging in getting support out -- a lump of coal to them. :(* Orest

You can then add two minus symbols to each line so it looks like-- Setup cleanup events for when FSX changes occur--if DISABLEMCP == 0 or DISABLEEFIS == 0 then-- event.sim(CLOSE, "GFQuit")-- event.sim(AIRCRAFTCHANGE, "GFQuit")-- event.terminate("GFQuit")--endSave the LUA script and try again. Let me know if this changes anything.Best wishesSteve

Bravo! This fixed my hanging when closing out of FSX.Nice work Steve. Everything seems to be working well at this point.

Gents,I have had a quick look at the code (xmas calls) and can see a slight problem if you are using STAGEDPOLLTYPE = 0 since that calls a different routine which is not cancelled, but it is a trivial issue.The code in the closure routine does not interact with the NGX in any way, its just shutting down LUA/FSUIPC routines and clearing the Goflight displays so I'm a little confused that the new service pack has caused problems. Anyway I'll take another look in a couple of days and if I'm still struggling I'll check with Pete Dowson to see if anything odd is going on with LUA and FSUIPC.Thanks for your kind words and Merry Christmas to you all.Best wishesSteve

MCPPRO/Script LockupsOk, if the MCPPRO locked up before, when not using this LUA script, power cycling it would wake it back up. It seems if this script locks up, this doesn't help.I have tried unplugging/plugging back in the MCPPRO combined with killing LUA scripts, and restarting the MCPPRO script (by assigning hotkeys), but it isn't working. Perhaps I have just not hit the right combo.Any suggestions?I did try backing off on the polling intervals, to see if this helps. This occurs maybe once every two or three flights. But once it does, the MCPPRO is offline for the session until you restart FSX. Oddly it still displays the values in the windows, but none of the buttons/switches work.* Orest

Edited January 1, 201214 yr by oskrypuch

MCPPRO/Script LockupsOk, if the MCPPRO locked up before, when not using this LUA script, power cycling it would wake it back up. It seems if this script locks up, this doesn't help.I have tried unplugging/plugging back in the MCPPRO combined with killing LUA scripts, and restarting the MCPPRO script (by assigning hotkeys), but it isn't working. Perhaps I have just not hit the right combo.Any suggestions?I did try backing off on the polling intervals, to see if this helps. This occurs maybe once every two or three flights. But once it does, the MCPPRO is offline for the session until you restart FSX. Oddly it still displays the values in the windows, but none of the buttons/switches work.* Orest

Hi Orest,The general view about resolving MCP PRO lock ups (nothing to do with my script) is to either use USB1.1 or get the latest firmware which is A25 if memory serves me correctly. The goflight forums have info on all of this.In relation to my script, the lockup during flight is due to the above hardware issues but sometimes it can be recovered. There are several areas you will need to check. After the power re-cycle, make sure GFConfig see's the MCP PRO ok. After that go into FSUIPC and reload the configuration this will ensure that FSUIPC can see the MCP PRO although sometimes it doesn't work. Pete thinks it might be something at the goflight driver level. Finally restart the script, you do this by assigning a button or key command to execute an FS Control of "lua NGX_AUTO". If that doesn't work, you can terminate GfDevFSX.EXE in task manager, then restart it and try the above again.Best wishesSteve

Looks like I have A22, dang it. A22 and older are the problems. Being outside of the US, that really complicates the return/repair, as in $$ for shipping and border charges. Will try to sort out which is a 1.1 controller, if any,I do have an old 1.1 powered hub, will that work, even if plugged into a 2.0 system port?Thanks for the tips, in case.* Orest

Edited January 2, 201214 yr by oskrypuch

I also had this lock-up issue (A22 version, W7 x64) and send the device to GF. It tooks ~6 weeks and cost me approx. 25 USD total. Worth it. USB 1.0 is a no go for me (too many devices, no place inside the case for additional card)

Looks like I have A22, dang it. A22 and older are the problems. Being outside of the US, that really complicates the return/repair, as in $$ for shipping and border charges. Will try to sort out which is a 1.1 controller, if any,I do have an old 1.1 powered hub, will that work, even if plugged into a 2.0 system port?Thanks for the tips, in case.* Orest

Hi Orest,I suspect the problem is a buffer overflow in the MCP hardware which is why either slowing things down (using USB 1.1 or turning the dials slowly) resolves the problem.I'm using A22 and don't have the problem anymore because using similiar logic I decided to "clear a path" so to speak for the MCP. I have it connected directly to my PC on its own USB2 controller with nothing else attached to it. I also have GFDevFSX.exe priortised to High in task manager along with ensuring FSX only runs on 3 cores leaving one core mainly free for hardware interrupts and other programs such as GFDevFSX.exe. Its not 100% perfect but its now very rare that I get a lock up.I also recall that it seems to be overly sensitive to the manufacturer of the USB chip in the controller, so if you decide to buy anything, search the goflight and fsuipc forums as I recall a post stating which one was more compatiable.Best wishesSteve