Jump to content
The simFlight Network Forums

adrem

Members
 View Profile  See their activity

  • Posts

    61

  • Joined

  • Last visited

 Content Type 

Posts posted by adrem

  3. Dynamic Axis assignment

    in FSUIPC Support Pete Dowson Modules

    Posted

    6 hours ago, Pete Dowson said:

    The only drawback is that you wouldn't be able to use FSUIPC's calibration.

    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")

     

  4. Problem with loading dll lua modules

    in FSUIPC Support Pete Dowson Modules

    Posted

    1 hour ago, Pete Dowson said:

    It would be more efficient and more flexible for the users, including your good self.

    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?

  5. Problem with loading dll lua modules

    in FSUIPC Support Pete Dowson Modules

    Posted

    1 hour ago, Pete Dowson said:

    Mainly because many of these have been changed to suit the internal machinations in FSUIPC

    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?

    1 hour ago, Pete Dowson said:

    But also I don't see any justification

    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.

  6. Problem with loading dll lua modules

    in FSUIPC Support Pete Dowson Modules

    Posted

    5 hours ago, Pete Dowson said:

    This would be free of the constraints you are complaining about, and be easier to start, control and amend in any way you wanted

    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.

    6 hours ago, Pete Dowson said:

    BTW I note contradictions in what you are asking for -- "lua_" functions and "LuaL_", or just "Lua_"? And precisely which ones and why?

    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);
  ...
}

     

  7. Problem with loading dll lua modules

    in FSUIPC Support Pete Dowson Modules

    Posted

    24 minutes ago, John Dowson said:

    Can you not include the lua core in your dll and just dynamically link to the one in the FSUIPC6.dll?

    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.

  8. Problem with loading dll lua modules

    in FSUIPC Support Pete Dowson Modules

    Posted

    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.

    On 1/25/2021 at 11:28 AM, Pete Dowson said:

    Doesn't the 'L' in your LuaL_error call (and the others) refers to a structure created in your loaded Lua interpreter.

    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.

    On 1/25/2021 at 11:28 AM, Pete Dowson said:

    Which Windows functions do you need? You don't show any there.

    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/.

     

  9. Problem with loading dll lua modules

    in FSUIPC Support Pete Dowson Modules

    Posted

    5 hours ago, Pete Dowson said:

    Why not implement your own error reporting function since you are making a C program?

    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)

     

  11. Problem with loading dll lua modules

    in FSUIPC Support Pete Dowson Modules

    Posted

    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.

  12. FSUIPC6 Macro Making Stuck

    in FSUIPC Support Pete Dowson Modules

    Posted

    2 hours ago, Ross McDonagh said:

    LINDA stuff just seemed way over my head

    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.

    • Thanks 1

  13. FSUIPC6 Macro Making Stuck

    in FSUIPC Support Pete Dowson Modules

    Posted

    2 hours ago, Ross McDonagh said:

    So with everything else I have completely disabled, this macro making still sticks.  Just as in the video.  I tested a default airplane it didn’t stick, I tested a different livery/engined FSLabs A320 and it did it again same click spot.  Finally I tested the TFDI 717 and it worked fine.   So it’s only with the FSLabs A320.  What should I do from here?

    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.

  19. issue with ipc.get/set

    in FSUIPC Support Pete Dowson Modules

    Posted

    2 hours ago, Pete Dowson said:

    It got to having the  100 test Luas running but my PC (a 7700 running at 5GHz) was by then so sluggish with so many threads running that I turfed it off. How many did you get to before it failed, typically? And what do you expect the loop at the end to do (the loop forever reading a global called "myvar" which was never written)?

    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.

  21. issue with ipc.get/set

    in FSUIPC Support Pete Dowson Modules

    Posted

    20 hours ago, Pete Dowson said:

    If that source reconstructed (in a debugger?) from our binary or located some other way?

    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.

    20 hours ago, Pete Dowson said:

    Do you have the Windows crash information? Version 6.08 of FSUIPC? Or WideClient?

    FSUIPC 6.08. P3D itself didn't crash because FSUIPC catches these exceptions in the lua threads and displays the address in the console.

    20 hours ago, Pete Dowson said:

    I'm still not sure what I can do about it.

    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.

  22. issue with ipc.get/set

    in FSUIPC Support Pete Dowson Modules

    Posted

    1 hour ago, Pete Dowson said:

    I don't really see how any such problems could cause access violation crashes.

    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:

     Capture.PNG.eef424d3f2e808f3f13b1ecfcaefa9b4.PNG

    1 hour ago, Pete Dowson said:

    BTW what happened between the 8th January and now? Been on a long holiday?  🙂

    I just randomly remembered this for some reason 😄

  23. issue with ipc.get/set

    in FSUIPC Support Pete Dowson Modules

    Posted

    On 1/9/2020 at 1:55 PM, Pete Dowson said:

    The set and get functions are really simple, using basic calls into the Lua code which is not mine,

    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.

×
×
  • 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.