Jump to content
The simFlight Network Forums

adrem

Members
  • Content Count

    49
  • Joined

  • Last visited

Community Reputation

2 Neutral

About adrem

  • Rank
    Advanced Member

Profile Information

  • Gender
    Not Telling
  • Location
    Switzerland

Recent Profile Visitors

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

  1. 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.
  2. 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.
  3. I don't have the same problem, I was just pointing out that the default flaps controls work just fine with FSLabs.
  4. FSLabs does map the default flaps incr/decr controls to moving the flaps handle, so they should work.
  5. Hi John, It works perfectly now!
  6. 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.
  7. 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.
  8. 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.
  9. 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 😄
  10. 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.
  11. Actually, it's just the first byte that I can't write to. Writing to 4201 and beyond works just fine.
  12. Sorry, I should have worded it better. I meant that the value doesn't get written.
×
×
  • 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.