Jump to content
The simFlight Network Forums

adrem

Members
  • Posts

    58
  • Joined

  • Last visited

Profile Information

  • Gender
    Not Telling
  • Location
    Switzerland

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

adrem's Achievements

Newbie

Newbie (1/14)

  • Dedicated Rare
  • Week One Done Rare
  • One Month Later Rare
  • One Year In Rare

Recent Badges

2

Reputation

  1. 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?
  2. 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.
  3. 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); ... }
  4. 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.
  5. 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/.
  6. 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)
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. I don't have the same problem, I was just pointing out that the default flaps controls work just fine with FSLabs.
  12. FSLabs does map the default flaps incr/decr controls to moving the flaps handle, so they should work.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.