dazz

Thanks, John. Turns out I had an ipc.exit() somewhere that was responsible for the thread interruption. The range wasn't being entered again before the thread completed running The LuaRerunDelay parameter could be useful for some other application, good to know. I don't think i'll need it this time around. The script is working fine already. I really need to re-read the advanced guide again. It's been a while. Muchas gracias de nuevo 😃

I'm super rusty and I don't seem to remember if there's a way to do what I mention in the title. I need my script (it's tied to an axis range) to complete execution, but sometimes it doesn't, I suspect it's because another input is detected for the axis, but I'm not sure because the log doesn't print the lines I have at the beginning of the script after the interruption of the previous execution. Is there a way to get a "lock" or something like that? Thanks Using FSX and FSUPIC4 v4.977, I believe it's the latest one

Nevermind. I figured it out. All I needed to do is to ensure that the code was loaded and executed in the right order.

Hi there, long time no see! Hope you're doing great, Pete. So I'm planning to go back to doing some flight simming after a long hiatus. Got some new gear and I'm in the process of configuring everything in FSUIPC/LINDA. I have a Lua script to map the flaps, spoilers and gear lever to a single axis using ranges. The idea is to push the lever all the way up/down to retract/deploy the gear, while a smaller input to the lever increments or decrements the flaps. Then I use the global shift utility in LINDA to duplicate that for the spoilers. I have a Lua script to take care of all that called lindaDefault.lua, which works well for aircrafts that use default controls for the gear, flaps and spoilers. The plan is to then use specific scripts for planes that require some custom logic for some or all the controls. These scripts execute a require('lindaDefault') so that they have access to all the default functions there, and then I can (hopefully) override the functions that are needed to make the script work for that specific plane. For example, the NGX uses different controls for the spoilers, so I would be overrinding those functions while using the default ones for the flaps and gear. This is a snippet of lindaDefault.lua, containing one of the functions - spoilersDeploy() - that are meant to be overriden if necessary. [code] ------------------------------------------------------------------------------------------------------------------------------- ----------------------------------------------------- OVERRIDABLE FUNCTIONS --------------------------------------------------- ------------------------------------------------------------------------------------------------------------------------------- function spoilersDeploy() ipc.control(66064) -- Spoilers Deploy end ------------------------------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------------------------------------- function AXIS_GEAR_SPOILERS_100() if SHIFT_GLOB == 0 then ipc.control(66080) -- Gear down else spoilersDeploy() end ipc.set('LEVER_MAXED_OUT', true) end FUNCTIONS = { [1] = AXIS_PARKINGBRAKES_SPOILERS_OFF, [2] = AXIS_PARKINGBRAKES_SPOILERS_ON_ARM, [3] = VOID, [4] = AXIS_FLAPS_SPOILERS_DEC, [5] = AXIS_FLAPS_SPOILERS_INC, [6] = AXIS_GEAR_SPOILERS_0, [7] = AXIS_GEAR_SPOILERS_100, } func = FUNCTIONS[f] if (func) then func() else ipc.log('nope, no function here to be called') end [/code] Then I have this lindaNGX.lua that's supposed to override the spoiler functions like this: [code] require('lindaDefault') ------------------------------------------------------------------------------------------------------------------------------- ----------------------------------------------------- OVERRIDABLE FUNCTIONS --------------------------------------------------- ------------------------------------------------------------------------------------------------------------------------------- function spoilersDeploy() ipc.control(86637, 16384) -- Spoilers Deploy end function spoilersRetract() ipc.control(86637, -16384) -- Spoilers Retract end function spoilersArm() ipc.control(86637, -13100) -- Spoilers Arm end function spoilersDisarm() spoilersRetract() end ------------------------------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------------------------------------- [/code] This is not working. The functions in lindaDefault.lua are the ones being called. Any ideas, please? Thanks in advance.

Yeah, silly me. I haven't fired up my sim in ages and since all my assignments are in Lua - Linda, I just opened my NGX script and searched for "taxi" without even thinking. That parameter probably came from flipping switches in the cockpit while tracing control changes. Thanks for the clarifications

try this Ron: ipc.control(69749, 536870912)

Does that apply to loading, I don't know, the 900, then another NGX variant like the 800WL or 700 or whatever?

I use the path of the AIR file. function loadFunct() acPath = ipc.readSTR(0x3C00, 256) if (string.find(acPath, "00NGX") == null) then ... end end event.sim(FLIGHTLOAD, "loadFunct") [/CODE]

I'm testing with Fs2Crew after reloading the flight and it seems to be very wrong. Plenty of "are you sure about that" when the items are clearly correct, like anti-collision lights on, and I can't contact ground crew either, so yeah

Damn it! , it's also happening to me and I thought it was something in my code. I can force to restart my dll in the middle of a flight, but if I load a different flight it stops working

Project released, in case someone wants to check it out http://forum.avsim.net/topic/368674-a-little-project-of-mine-for-simpit-builders-ngxsdk2lua/

Roger that. And please Pete, don't let the FSUIPC4.dll crash steal too much of your time. It really takes a bunch of restarts to crash the sim.

Here's the log in the event viewer with version 4.812f Exception code: 0xc0000005 Fault offset: 0x0004f590 Faulting process id: 0x1bbc Faulting application start time: 0x01cd119264c5fc9a Faulting application path: C:\Program Files (x86)\Microsoft Games\Microsoft Flight Simulator X\fsx.exe Faulting module path: C:\Program Files (x86)\Microsoft Games\Microsoft Flight Simulator X\Modules\FSUIPC4.dll And I tried the event.terminate thing (this is the script I use to start & restart the dll, calling it from ipcReady with ipc.runlua, so that it runs in it's own thread): require "ngxSDK2Lua" function restartNGXSDK2Lua() acName = ipc.readSTR(0x3D00, 100) if (string.find(acName, "NGX") == null) then return end resp = ngxSDK2Lua.start(); if (resp ~= nil) then ipc.log(resp) end end function kill() ipc.log("Killing ngxSDK2Lua ...............") resp = ngxSDK2Lua.kill(); if (resp ~= nil) then ipc.log(resp) end end event.offset(0x3D00, "STR" , "restartNGXSDK2Lua") event.terminate("kill") [/CODE] ...but I don't see the "Killing ngxSDK2Lua ..............." trace printed in the log, not sure it's working

Ok, I'll try that version of FSUIPC. It's a very rare occurrence really so it doesn't worry me much. I need to keep restarting the dll over and over again to trigger the error, so it's not that big of a deal I think. As for the event.terminate part, I'll try that, but I'm not creating a new thread in the dll in the end. It was crashing like mad when I tried it and couldn't figure out why, but will see if event.terminate helps Thanks for the suggestions

Pete maybe you can give me some guidelines on how to proceed to debug this: When I restart the dll in the middle of a flight, I can do it in two ways: 1.- Call the Lua script that starts the dll. It calls a function in the dll that starts the SimConnect communication. When I do that the previous instance seems to vanish on it's own, and the new one starts just fine. Problem is that after a number of restarts I get a CTD in FSUIPC4.dll (different fault offsets, here's two examples): Exception code: 0xc0000005 Fault offset: 0x0004afc2 Faulting process id: 0x1944 Faulting application start time: 0x01cd118cc82d9b4b Faulting application path: C:\Program Files (x86)\Microsoft Games\Microsoft Flight Simulator X\fsx.exe Faulting module path: C:\Program Files (x86)\Microsoft Games\Microsoft Flight Simulator X\Modules\FSUIPC4.dll Exception code: 0xc0000005 Fault offset: 0x0004dbaa Faulting process id: 0x1ab4 Faulting application start time: 0x01cd118f381ebe6b Faulting application path: C:\Program Files (x86)\Microsoft Games\Microsoft Flight Simulator X\fsx.exe Faulting module path: C:\Program Files (x86)\Microsoft Games\Microsoft Flight Simulator X\Modules\FSUIPC4.dll 2.- If I do a Lua KillAll I get an instant CTD in ntdll.dll: Exception code: 0xc0000029 Fault offset: 0x000907b6 Faulting process id: 0xc84 Faulting application start time: 0x01cd118ba3ba321e Faulting application path: C:\Program Files (x86)\Microsoft Games\Microsoft Flight Simulator X\fsx.exe Faulting module path: C:\Windows\SysWOW64\ntdll.dll what tools can I use to figure out where the problem is please?

There's a note in my Readme warning about that, and advising to check your forums here for possible news before doing anything with my dll. I still think this could end up being a useful Lua script installer, even if it doesn't use my dll at all.

Damn, it's true!, it's not what I said. I'm trying with a release version of the dll with some traces in the log and the loop is running in the new thread. It's doing some weird things but it's running for sure and the creator thread is back to running the Lua script that launched the dll. The module runs but every now and then, randomly, a call to Lua fails (this is the FSUIPC log, where I print what comes from the dll. Every log line is a switch/knob I clicked): IRS_DisplaySelector: 1 IRS_SysDisplay_R: 0 IRS_DisplaySelector: 2 IRS_DisplaySelector: 3 IRS_DisplaySelector: 4 IRS_DisplaySelector: 3 IRS_DisplaySelector: 2 IRS_DisplaySelector: 1 [E] *** LUA Error: ...ht Simulator X\modules\linda/system/handlers-mcp.lua:168: attempt to perform arithmetic on a nil value IRS_DisplaySelector: 0 IRS_DisplaySelector: 1 IRS_DisplaySelector: 2 IRS_DisplaySelector: 1 IRS_DisplaySelector: 2 [E] *** LUA Error: (null) IRS_DisplaySelector: 1 IRS_DisplaySelector: 2 [E] *** LUA Error: attempt to call a number value [/CODE] ...and finally crashes: Unhandled exception at 0x773015ee in fsx.exe: 0xC0000005: Access violation reading location 0x56085da3. I'll see what I can do. By the way, I'm doing this thing modular, so one will only need to drop a script in a folder and the dll will do the rest, and if you add a supported panel in the future, you just add the script (or run the installer again) and off you go. I plan on including some module(s) with the installer ready to use, maybe some GoFlight & Opencockpits panels

It doesn't even get to the loop. The child dies because the parent dies (the function above returns). When the function extern "C" __declspec(dllexport) int luaopen_ngxSDK2Lua(lua_State *L) [/CODE] exits, the thread that created the child that runs the SimConnect part (startThread above) dies, and with it dies the "startThread" child. So the timeline would be like... Lua: require "ngxSDK2Lua" dll: extern "C" __declspec(dllexport) int luaopen_ngxSDK2Lua(lua_State *L) dll: spawns the "initCommunication" thread that should start the SimConnect part dll: the function luaopen_ngxSDK2Lua exits, execution back to Lua. Parent thread dies dll: child thread dies at some point while configuring SimConnect because the parent just died, FSX crashes to desktop. I would need some sort of Linux "fork" like function maybe? not sure, but I've reverted back to the old version with an init Lua script that I'll start with ipc.runlua so that the SimConnect stuff runs on it's own thread.

One question please. I'm trying to spawn a thread to run the communication with the NGX void startThread() { initCommunication(); } extern "C" __declspec(dllexport) int luaopen_ngxSDK2Lua(lua_State *L){ // register Lua functions static const luaL_Reg functs [] = { {"registerOffsetMap", cpp_registerOffsetMap}, {"registerLuaFile", cpp_registerLuaFile}, ... {NULL,NULL} }; luaL_register(L,"ngxSDK2Lua", functs); LuaGlobal = L; if (active) { return 0; } // run installed modules ... boost::thread thrd(startThread); thrd.detach(); return 0; } [/CODE] this runs the first time I do a require "ngxSDK2Lua" in Lua. The idea is that control returns to the Lua script while the dll does it's stuff, but as soon as the the function returns, the child thread that starts the SimConnect communication dies. Until now I was starting the module using an independent Lua thread with ipc.runlua, but this would be better. Is it even possible please?

Thanks Paul. I'll keep you posted

I finished my module and sent a copy of the installer to PMDG for revision. Robert's been so kind to consider checking it out. If they say it's ok, I could use some help to beta test it if someone's interested, especially for the offset part (opencockpits panels)

I have no idea what's going on. All of a sudden I don't get any PMDG events detected in the dispatch method. I haven't changed anything in the Simconnect initialization and RequestClientData part. I get an event dwID 15, then a 2 and nothing else. Have commented out everything except for what's in the example provided by PMDG and still no go. I know it's not too much info, but maybe it rings a bell... or maybe I could upload the VS project So frustrating cause it's finished I'm sure I'm missing something stupid somewhere

Pete, this is almost ready, but I'm geting random crashes if I run FSUIPC_Process(&dwResult); right after writing an offset: FSUIPC_Write(dwOffset, 1, pSrce, &dwResult); FSUIPC_Process(&dwResult); If I process the read/writes once after the entire dispatch loop is done, it works fine (probably a better way to go about it anyway) Not sure how to debug this

I also sent a ticket asking them if they would mind checking an installer and giving it the OK. Thay was 4 days ago and still no answer either. My module should be ready for testing in a few days. I think I'll just release it and see what happens

I'm doing something I think should address the offset "issues", being those 1.- I had no way to set offsets in the dll 2.- setting offsets from lua via ipc lib is too slow. 500 iterations take some 20 seconds, so this module would be colmpletely useless for devices that listen to offsets that are being updated from Lua So I implemented a way to register items to be stored in any offset. An example: ngxSDK2Lua.registerOffset("IRS_DisplaySelector", 0x6CCC, "writeUB") [/CODE] this would instruct the dll to store any new data in the item "IRS_SysDisplay_R" to the offset 0x6CCC as an unsigned byte. Or.. [CODE] ngxSDK2Lua.registerOffset("IRS_SysDisplay_R", 0x6DCC, "setbitsUB", 1) -- last param is the mask for setbitsUB [/CODE] to assign the IRS_SysDisplay_R boolean to the first bit (least significant) of the offset 0x6DCC I'll be using a hash map (I think it has direct access to the members) to speed things up [CODE] static std::hash_map<std::string, OffsetCall> offsetMappings; [/CODE] to retrieve a struct for each mapped item [CODE] struct OffsetCall { void (*offsetFunction)(DWORD dwOffset, void* valueOrMask); DWORD dwOffset; DWORD mask; }; [/CODE] then call the offsetFunction with the new value of the item (or the mask for functions like setbitsXX or clearbitsXX) should be pretty fast me thinks, and it's 100% configurable