Jump to content
The simFlight Network Forums

LuaStartStop


Recommended Posts

Hi Pete,

Sometimes you have the need to run or kill a LUA program by a button in your cockpit. You can either implement the Lua or the LuaKill function for this button. It would be useful to have also a LuaStartStop function for a given LUA program. This function should start the LUA prorgam, if it is not running and should kill the LUA, if it is currently running. This would allow, to activate and deactivate certain functionality with one single button. Of course there are some other methods, which can be coded, but I think, this would make it easier, to activate/deactivate functions in a cockpit by a single button press. How are you thinking about such a function ?

Rgds

Reinhard

Link to comment
Share on other sites

Sometimes you have the need to run or kill a LUA program by a button in your cockpit. You can either implement the Lua or the LuaKill function for this button. It would be useful to have also a LuaStartStop function for a given LUA program. This function should start the LUA prorgam, if it is not running and should kill the LUA, if it is currently running. This would allow, to activate and deactivate certain functionality with one single button. Of course there are some other methods, which can be coded, but I think, this would make it easier, to activate/deactivate functions in a cockpit by a single button press. How are you thinking about such a function ?

Actually I am not really in favour of making the "killing" of Lua threads more easily usable than now. I know it is necessary to be able to kill them, usually when developing them so that changes and fixes can be made. But in general it is not good practice -- killing threads forcibly is a brutal process, and whilst I've taken lots of steps in FSUIPC to avoid this causing access violations, memory leaks and dangling handles, it is difficult to actualy guarantee this.

The better way it for the Lua plugin to terminate itself when it gets a user signal -- the Lua flags are ideal for this, and can be set, cleared and toggled. You'd only need to do this for those Lua plug-ins you realy want to otherwise 'kill' easily.

If you still feel that your idea is better, could you perhaps give examples of what you'd actually be using it for -- i.e. what plugin functions need such handling?

Regards

Pete

Link to comment
Share on other sites

Pete,

I understand your argument and killing of course is a hard measurement. The function might be useful in a home cockpit, where you have several hardware components (like GF modules), which you want to enable / disable with a single button. For the GF radios for example there exists a known bug, that under WIN 7 64bit they freeze from time to time. No solution was presented by GF so far despite several reports in their forum. And if this happens during a flight, you lose some important functionality. Then it would be fine to terminate the LUA script monitoring these devices. Then you can unplug/plug them (which solves typically the freeze) and you could enable the LUA controlling of these devices again with one single button. And buttons typically are rare in a cockpit, as you have to cover so many functions.

So following your hint I will implement this handling into my routines by using flags. And I will use seperate buttons via my WideFS client to start/stop the hardware LUAs. I think your argument about stability is stronger. Therefore I will add coding to realize the disabling of my LUA routines.

Rgds

Reinhard

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • 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.