Chrilith

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

Just released the new module version. it can be downloaded here: https://github.com/chrilith/Passerelle/releases

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

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

@Claude, I just sent you a new DLL with FSUIPC offset support! @Pete: it was incredibly easy to implement your API :D Thanks!

Makes sense, thank you for your answer. :) I'll implement different modes for different use cases. Thank you again!

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

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

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!

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?

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

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!

Works great! Thanks Pete.

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.

I'll check this. thank you very much Pete!