Jump to content
The simFlight Network Forums


  • Content Count

  • Joined

  • Last visited

Community Reputation

2 Neutral

About adrem

  • Rank
    Advanced Member

Profile Information

  • Gender
    Not Telling
  • Location

Recent Profile Visitors

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

  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
  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_EXTL
  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
  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" d
  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
  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.