Jump to content
The simFlight Network Forums

Chrilith

Members
  • Posts

    45
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by Chrilith

  1. Hello, A new Passerelle version is coming with a window capture feature. Passerelle is a module to control Saitek devices that can be used with the FSUIPC Lua engine. You can now stream an instrument window to your Saitek Flight Panel Instrument with a very simple script: require "passerelle" passerelle.addPage("SFIP", 1, 1, true); function capture() local bitmap = passerelle.captureWindow("FS98FLOAT", "PFD", 0, 0, 100, 100); passerelle.setImage('SFIP', 1, 1, 0, bitmap); collectgarbage(); end while true do capture(); ipc.sleep(50); end To test this script in FSUIPC: - Select a Cessna with a G1000 GPS - Start the flight - Open the PFD window - Undock it (window must be in non-minimized state) - Run the script And voilà! Your are streaming your PFD to your FIP! Check the installation procedure here: https://github.com/chrilith/Passerelle/wiki/Installing-the-Module#with-flight-simulator This preview version can be downloaded from here: https://github.com/chrilith/Passerelle/releases The documentation is here: https://github.com/chrilith/Passerelle/wiki Chris
  2. Just released the new module version. it can be downloaded here: https://github.com/chrilith/Passerelle/releases
  3. Great news Claude! Thank you very much for your time! I will release the new version to the public soon then, just some doc to write :) Chris
  4. Yes one byte is enough. I'm just changing the value on a modulo 2 to force update after each raised event. It is basically used as a notification. Thanks
  5. @Claude, I just sent you a new DLL with FSUIPC offset support! @Pete: it was incredibly easy to implement your API :D Thanks!
  6. Makes sense, thank you for your answer. :) I'll implement different modes for different use cases. Thank you again!
  7. Hi again, It seems that I have a working version, without using FSUIPC offset for now. I have a quick question regarding Lua execution in FSUIPC. As my code is now polling for events, I'm using something like this in my test script: event.offset(...Some offset to check...); while true do passerelle.poll(); -- polling for events related to the callbacks and auto-execute them ipc.sleep(50); end Here, I receive all my events properly but the function used for offset() seems to never be called. Is this the intented behavior when an "event" loop is used? I see in your Lua samples that you use this kind of loop but read each data directly from the offset, without using the event object. Is this because we cannot mix them? Thanks, now, I'll do some BIG cleanup and implement the FSUIPC SDK :)
  8. Thanks Pete. Regarding your question, I have an internal script management based on the Lua state address. I think I'll add some kind of internal event queuing and a function to process the message from Lua to be sure the callback is executed in the correct context. Like this, the data is limited to an event index or address. Will see if this can work. I'll first add this queing system decoupling it from FSUIPC so that it can be used in any Lua script, then add the FSUIPC layer. Thx
  9. Hi Pete, So, we did some tests with Claude using lua_newthread() API function and even if it seems a bit more stable with FSUIPC it really seems that I cannot properly sync access to Lua with it. Also, event.offset() will, in most cases, take precedence over the DLL Lua calls. So, as you proposed, an offset should do the trick as FSUIPC will be responsible for the synchronization and thread access. Are you still OK to provide one specifically for my module? In the meantime, can I use the 0x8001 used in your SDK sample code for testing purpose? Thank you!
  10. Hum... unless I implement lua_lock/unlock, this will be the same problem since the callback is raised from an external thread, no? I mean, changing the state of a variable in the global space need access synchonization on the Lua state to prevent corruption, without the lock, an external thread may corrupt the state (as it is currently using lua_pcall() from the callback). Or I didn't get the point?
  11. Thanks Pete, but yes, the DLL can be used simultaneously by multiple scripts. Your event.offset is still one of the solution, will check more deeply your documentation. Reading posts here and there, even if I use coroutine, I'm not guaranteed to not corrupt something... but will try this anyway with lua_newthread() and locking. Other solutions are: - Add some kind of queueing: may lead to some synching problem in reg/unreg of callbacks - Add socket-based communication I'l study these 4 options! Thanks
  12. OK, finally remembered my password! :) I put the Saitek DLL source code on GitHub: https://github.com/chrilith/Passerelle I'll do some cleanup and doc (so that anyone can compile it easily), and start working on this specific crash problem. Pete pointed the problem: this module is using classic Windows callbacks. So, I'll look at this event stuff and see if I can prevent race conditions. Should not be too difficult (hopefully). Claude, can you tell me what version of the Saitek FIP driver you are currently using? Thanks!
  13. Just test and the __gc are still not called with this version. If I let the script ends by itself, I mean not adding a blocking event.offset(...), the __gc are properly called. I'll change my moduleso that people can handle script interruption with your event.terminate() method. Anyway, thank you very much Pete.
  14. I'll check this. thank you very much Pete!
  15. Sounds good Pete. Thank you. I'll will test as soon as this new version is available. Thanks again
  16. Not only allocated memory, some Lua objects (either from a Lua script or user data from a C module) have a defined __gc function which should be called upon garbage collection to free resources. Yes, there are lots of functions related to GB but really don't know what to call right now. Of course! :)
  17. Makes more sense indeed, sorry :) Yes, this is more a resource related problem and everything is related to the garbage collector. I think that the only thing to do is to force garbage collection before killing the thread so that allocated resources can be freed. If this helps, I can try to compile Lua and see how it operates on script interruption. Thanks!
  18. Ok, I answeredyour questions before you post this message. Again, no rush on this of course :)
  19. I not so expert too :) Would be interesting indeed if there is no other way to kindly terminate the script. I understand that but I'm not sure that a script can voluntary perform an exit when the script is killed unless it receive some kind of event. I'll take an example related to my module. Hopefully this will help. When my module is initialized, it creates a user data using lua_createuserdata() and store it in the LUA_REGISTRYINDEX using lua_ref(). Like this, the "memory" will not be collected unless the script ends. The user data is linked to a meta table so that a __gc function can be associated with it which will be called upon garbage collection. The function is pushed to the stack using lua_pushcfunction(). Now, with Lua, even if you don't explicitly end your script (let's say you have an infinite loop and the script is interrupted with CTRL+C), the garbage collector (seems) to do its job and then call all required __gc function of allocated objects. Does this help?
  20. Hi Pete, I think this is the only remaing problem. Here is the case: In FSUIPC when you press the key to launch a Lua script again, the previous thread is killed and the script relaunched. The problem is that you don't call the finalizers so that the script can quit properly releasing any allocated ressource from an external module and so, in some modules, the ref counter should become unreliable. The common Lua engine calls finalizers(let's say pressing CTRL+C in command line) and the __gc functions are all properly called on interruption. The SciTE editor does this too. Could you please check this? Thanks!
  21. Hi Puffmac, Most instruments come with a driver to control and interface it with FS2004 or FSX. If you want to do your own instruments or display your own data and don't want to go the C/C++ way, you can use the Lua engine built in FSUIPC. If you look at the 'Modules' folder of your FS installation you'll see the FSUIPC Documentation folder where you'll find information about what can be done using LUA. There is also a LUA API to control GoFlight instruments. Also, I recently released a module to control Saitek FIP or X52 Pro panels from FSUIPC using LUA. You'll find it in the User Contrubutions section of this forum. Hope this help Chris
  22. Hi, I'm developing a LUA module to enable control of Saitek Flight Instruments and I need some beta testers for this. An early beta including a quick dummy example is available and attached to this thread. Please feel free to give feedback. The full documentation is also included (also, feel free to correct the documentation :)). You can also download it from my web site http://www.super-hornet.com/. Best, Chris DIST.zip
  23. Ok, just tested my previous test module and no crash! Great job! Now, I'll continue the development of my Saitek module and let you know whether I have an issue. Thank you again Pete.
  24. Wow, things are really getting better and better! Quite cool! Thank you for your hard work on this Pete!
×
×
  • 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.