adrem

That can be fixed by reversing it in the code: ipc.control(STEERING_SET, -value)

I forgot about the first parameter, it should be function onGroundFlag(_, value) instead.

There are offsets that allow you to disconnect the main FSUIPC axis assignments. It should be possible to assign the axis to the aileron control in FSUIPC and then, while on ground, disconnect and redirect it to the STEERING_SET control instead. STEERING_SET = 66818 function onAileronAxis(_, value) ipc.control(STEERING_SET, value) end function disconnectAileronAxis() ipc.setbitsUB(0x310A, 2) end function reconnectAileronAxis() ipc.clearbitsUB(0x310A, 2) end function onGroundFlag(value) local onGround = value == 1 if onGround then event.timer(5000, "disconnectAileronAxis") event.offset(0x3328, "SW", "onAileronAxis") else event.cancel("disconnectAileronAxis") event.cancel("onAileronAxis") reconnectAileronAxis() end end event.offset(0x0366, "UB", "onGroundFlag")

This is exactly the opposite of the truth 🙂 Let me give you a bit more context. My addon comprises two things: a copilot add-on for the FSLabs A320 and a library for interacting with the cockpit controls that I've primarily made for the copilot thingy but can also be imported standalone in a regular FSUIPC Lua script (for example, to make keyboard and joystick bindings, as I've shown above). I've already uploaded it to the FSLabs forum a few months ago and there are people using it. The majority of the code is written in Lua, with C++ only being used for parts where I can't use Lua (mainly the Windows Speech and HID APIs). The copilot add-on can be extended with the user's own lua code. I know one real world pilot who has programmed his airline's procedures, including checklists. There are a lot of useful functions in the FSUIPC Lua library that people might want to use and they aren't going to be there if I move my add-on outside of FSUIPC. I would also have to make my own facility for launching Lua scripts, when there's already a perfectly working one provided by FSUIPC. Seriously, it can't be that much work to mark a few dozen functions for export, what am I missing?

And what would be the difference from FSUIPC's point of view if people were able to call them direclty rather than through lua code? With all due respect, I think it's you who is missing the point. In my opinion, the question should be "what would be the justification to prevent people from using a standard lua feature (importing C modules)" rather than the other way round.

Not really. My 'program' is a simple library for interacting with cockpit controls of FSLabs aircraft. All it does iternally is invoke mouse macros, which would be my first problem if I tried to do it outside of FSUIPC - I wouldn't know how to implement the mouse macro functionality myself (I tried the FireMouseRectClick function from the PDK, but it crashes my sim for some reason). I intend to freely share it with other people to provide them a very easy to use keyboard and joystick binding interface; here are a couple of examples: Bind {key = "F", onPress = Bind.cycleSwitch(FSL.OVHD_EXTLT_Strobe_Switch)} myJoystick = Joystick.new(0x06A3, 0x0C2D) myJoystick:onPress(5, FSL.OVHD_EXTLT_Land_L_Switch, "ON", FSL.OVHD_EXTLT_Land_R_Switch, "ON") myJoystick:onPress(6, function() print "hello" end) myJoystick:onAxis("Y", FSL.GSLD_FCU_DimLt_Knob) It makes perfect sense to launch it inside the FSUIPC environment which already provides facilities for launching Lua scripts both manually and automatically - why would I want to reinvent the wheel? Now, the Bind function is just a wrapper around event.key and I tried to make Joystick a wrapper around the com library functions first, but I encountered the exact same problem that is described here in the opening post: https://forum.simflight.com/topic/68512-hid-devices-in-lua/, so I wrote my own HID library as a C module. Well, the lua API which comprises all the "lua_"' functions should theoretically be enough to write a self-contained lua application. Lauxlib.c says " This file uses only the official API of Lua. ** Any function declared here could be written as an application function." I just thought you would be more inclined to do it if there would be less functions 😄 That said, an application using lua would usually export all the "lua_" and "luaL_" functions. I actually don't know which functions I would need exactly as I don't call them directly (I use a library called sol2), but I don't understand your reluctance to just export all of the "lua_" and "luaL_" functions to enable anyone to make a dll Lua module and import it into the FSUIPC environment - it's not just about me. By the way, why reimplement the error function to catch errors inside of it instead of using the existing interface: if (luaL_dofile(L, "script.lua")) { const char* errMsg = lua_tostring(L, 1); ... }

Sorry, I'm not sure I'm following. How can I link to both the core I'm including and to FSUIPC6.dll and why? The only reason that I'm including a lua core in my dll module is because I can't link to the Lua API functions (the ones starting with "lua_") inside FSUIPC6.dll because FSUIPC6.dll doesn't export them.

Sorry to bring this up again, but while I've found an ugly workaround for the error function crashing, I've started to experience crashes under normal operation that stem from the same cause which is me having to statically link lua with my dll module. No, my code doesn't create a new lua state. It's the lua state that is created by the FSUIPC interpreter. My dll is just a library. It can be imported from a lua script using the require function. The crashes happen when the lua core inside my dll tries to run the garbage collector. The problem, ultimately, is that Lua has a static variable 'dummynode_' in ltable.c, and when I include a lua core in my dll instead of linking dynamically to the lua API functions inside FSUIPC6.dll, that results in two Lua cores with their own static variables that operate on the same Lua state. Again, you can find a lot of posts about this on the internet. The only way for dll libraries imported from lua to work properly is for those libraries to dynamically link to the same lua API functions that created the lua state. I will be very grateful if you will allow that. For now, I have to resort to forcibly running the garbage collector from lua to prevent my C code from doing it and that consumes a lot of CPU cycles. I didn't want to tell that because I basically made my own HID library instead of using the FSUIPC one 😄 I tried the FSUIPC one first, but then I encountered the same issue as described here: https://forum.simflight.com/topic/68512-hid-devices-in-lua/.

I'm not making a C program, just a small library to be able to access some Windows API functionality from my lua script (that is started by the FSUIPC lua interpreter). Something like this: int divide(lua_State* L) { if (lua_tonumber(L, 2) == 0) luaL_error(L, "The divisor must not be 0"); lua_pushnumber(L, lua_tonumber(L, 1) / lua_tonumber(L, 2)); return 1; } extern "C" __declspec(dllexport) int luaopen_mylualib(lua_State* L) { lua_pushcfunction(L, divide); lua_setglobal(L, "divide"); return 0; } Then I can import the dll and use it from lua like this: require "mylualib" divide(2, 0)

There seems to be a misunderstanding here - I just want to use the luaL_error function 😄 I'm not doing anything super complex. Whenever I call luaL_error, the plugin crashes because of the dual lua issue.

Hi Pete and John, I was trying to make lua dll library that I could import from the FSUIPC lua environment and it crashes under certain circumstances (Crash C0000005 in the FSUIPC log). For example, it always crashes if I throw a lua error or try to call the lua print function from C code. From my understanding, the issue is that I'm linking my library statically to lua instead of linking to the lua inside FSUIPC. You can find several posts on the internet related to this, for example here. Now, of course, I can't link to the FSUIPC lua because FSUIPC doesn't expose the lua functions, so my question is: would it be too much to ask you to do that? I can also reproduce this crash without FSUIPC if I compile a program with statically linked lua and a dll with statically linked lua that exports a single function that throws a lua error. If I instead link both the exe and the lua module to the same lua dll, everything works fine.

I've never used LINDA myself, but I would guess that it's much easier to use than you imagine. When used with one of their modules for addon aircraft, such as the one for FSLabs that John has linked above, it is to custom cockpit controls what FSUIPC is to default sim controls. You just select a joystick button in a drop-down menu and the cockpit control in another dropdown and you've created an assignment. You don't have to worry about macros, Lvars, rotor brake codes and other nonsense - the aircraft modules take care of that under the hood.

Perhaps you've assigned a macro with the same id that is being detected to one of your switches in a way that continuously invokes the macro? I'd suggest you open your macro file(s) in a text editor and look for entries with the id 400001c6.

I don't have the same problem, I was just pointing out that the default flaps controls work just fine with FSLabs.

Yep, they do.

FSLabs does map the default flaps incr/decr controls to moving the flaps handle, so they should work.

Hi John, It works perfectly now!

Great, thanks 🙂

Don't know how it ran on my PC back then, but the original script makes my PC sluggish now too. I've amended the script in my initial post to include sleep statements in the for loops. With it, I got the following output: 40234 -------------------- Starting everything now ---------------------- 41437 Advanced Weather Interface Enabled 158484 LUA.0: you're not supposed to see this 158812 LUA.0: you're not supposed to see this 160343 LUA.0: you're not supposed to see this 162312 LUA.0: you're not supposed to see this 164171 LUA.0: you're not supposed to see this 165265 LUA.0: you're not supposed to see this 171500 LUA.0: you're not supposed to see this 172703 LUA.0: you're not supposed to see this 177187 LUA.0: you're not supposed to see this 178390 LUA.0: you're not supposed to see this 182109 LUA.0: you're not supposed to see this 185500 LUA.0: you're not supposed to see this 192609 LUA.0: you're not supposed to see this 197312 LUA.0: you're not supposed to see this 198078 LUA.0: you're not supposed to see this 203593 LUA.1: Crash C0000005 at 7FFD48FD7BA3: "C:\Prepar3D v4\Modules\__TEST__\test1.lua" 204000 LUA.2: Crash C0000005 at 7FFD48FD7BA3: "C:\Prepar3D v4\Modules\__TEST__\test2.lua" 207000 LUA.3: Crash C0000005 at 7FFD48FD7BA3: "C:\Prepar3D v4\Modules\__TEST__\test3.lua" Then P3D crashed with an access violation in ntdll.dll You can reduce the number of threads but then you'll have to wait longer. In the setup where I encountered this first, I only had 3 threads with a dozen of these 'global' variables and eventually I had the variables being mixed up after about 30 minutes.

Lua is designed to run in a single thread so they are no-op in a vanilla distribution. lua_lock and lua_unlock are supposed to be implemented by the user if needed.

I looked up the binary code at the address that crashed in my own program that uses lua. It's the ltable.c file from the lua source. FSUIPC 6.08. P3D itself didn't crash because FSUIPC catches these exceptions in the lua threads and displays the address in the console. The only way to prevent this is to lock the shared lua VM with a mutex on each read and write. Maybe you shouldn't do anything at all 🙂 I personally don't even use ipc.get and ipc.set anymore and it appears that I'm the only one who ever complained.

But how can you know that? You said yourself that you don't know what the Lua code is doing. By the way, this is the exact line that causes the access violations: I just randomly remembered this for some reason 😄

Sorry for the stupid question, but could it simply be the case that the code isn't thread safe? If I understand correctly, ipc.get and ipc.set are implemented through a dedicated lua state where you store the shared variables. Lua isn't thread safe, so if you aren't locking the state in your own code, ipc.get and ipc.set aren't thread-safe either.

It's 6.0.8

Actually, it's just the first byte that I can't write to. Writing to 4201 and beyond works just fine.