Terminating or killing LUAs in other folders

[ckovoor]

Hello John and Pete,

I'm (still) running FSX-SP2 and Win 7 x64 with registered FSUIPC4.974b. I have lots of hardware (MCP's, throttle quadrants, radio consoles) containing Arduino Mega's, and hence numerous LUA scripts to manage them.

So a few days ago, I reached and breached the upper limit of 127 LUA files in the Modules folder. So I created sub-folders for each aircraft within the Modules folder, as for example Modules\LuaB747v3 containing all the Lua files pertaining to that particular aircraft. These LUAs are then started automatically from the Modules\Profiles\B747v3.ini file, thus:

[Auto]
1=Lua LuaB747v3\\B747v3inputsL

One negative fallout of the this arrangement is that if I need to start or kill a LUA on the fly using a button press (as I often need to do when testing hardware controlled by the Arduinos) I cannot do it as easily as when the LUAs were located in the Modules folder. For in that case I could assign a Lua (run) or LuaKIll to a particular button press and have it run or stop a chosen LUA on the fly.

In the new arrangement, in order to run a LUA using a button press, I have to create a LUA file within the Modules folder, say called runLUA.lua containing the command, as for example: ipc.runlua(LuaB747v3\\B747v3inputsL), and then run the LUA by assigning it to a button press. It's cumbersome, but still worthwhile, especially while testing/debugging Arduino-related programs.

I see no way of terminating such a LUA externally.

So, my question: is there any way of terminating/kiling a Lua file located in a folder other than Modules? Something like an ipc.killLua() command?

Thanks and Regards,

Chakko.

 

[Pete Dowson]

41 minutes ago, ckovoor said:

I'm (still) running FSX-SP2 and Win 7 x64 with registered FSUIPC4.974b. I have lots of hardware (MCP's, throttle quadrants, radio consoles) containing Arduino Mega's, and hence numerous LUA scripts to manage them.

So a few days ago, I reached and breached the upper limit of 127 LUA files in the Modules folder.

I cannot imagine a scenario where so many Lua plug-ins are required. It sounds like you have separate plug-ins for lots of little things which would be more efficiently dealt with in fewer larger ones. Can you explain what sorts of functions these >127 plug-ins are actually performing?

43 minutes ago, ckovoor said:

So I created sub-folders for each aircraft within the Modules folder, as for example Modules\LuaB747v3 containing all the Lua files pertaining to that particular aircraft. These LUAs are then started automatically from the Modules\Profiles\B747v3.ini file thus:

I'm actually surprised that works. There was no designed intention of allowing plug-ins to be run from other folders.

46 minutes ago, ckovoor said:

So, my quesition is there any way of terminating/kiling a Lua file located in a folder other than Modules? Something like an ipc.killLua() command?

No, sorry. At least not easily. You'd need to build the termination into the plug-in's code, with it instigated by an event on a key or button press.

I would seriously look at rationalising the way you have coded the plug-ins so that their numbers can be substantially reduced.

Pete

 

[ckovoor]

14 hours ago, Pete Dowson said:

I cannot imagine a scenario where so many Lua plug-ins are required. It sounds like you have separate plug-ins for lots of little things which would be more efficiently dealt with in fewer larger ones. Can you explain what sorts of functions these >127 plug-ins are actually performing?

I plead "Not Guilty" to the charge of profligacy in spawning Lua plugins.

I operate a touchscreen-based system with 6 monitors on a Server PC, and 10 monitors and 7 additional PC's on a WidevieW/WideFS network. A video of its operation in the case of the PMDG 747-400 (QOTS II v3) can be seen here: https://www.youtube.com/watch?v=saFJ_xGBDTs and should give you an idea of it's complexity.

In the case of the PMDG 747-400 v3  here is the [Auto] section of the 747v3.ini file located in Modules\Profiles with a justification for each Lua plugin:

[Auto]
1=Lua LuaB747v3\\b747v3inputsL
2=Lua LuaB747v3\\b747v3inputsR
3=Lua LuaB747v3\\B747v3outputs1
4=Lua LuaB747v3\\B747v3outputs2
5=Lua LuaB747v3\\B747v3Overhead
6=Lua LuaB747v3\\B747v3Captain
7=Lua LuaB747v3\\B747v3Copilot
8=Lua LuaB747v3\\B747v3Centre
9=Lua LuaB747v3\\B747v3Quadrant
10=Lua LuaB747v3\\B747v3RearPedstl
11=Lua LuaB747v3\\B747v3_RN1
12=Lua LuaB747v3\\B747v3_RN2
13=Lua LuaB747v3\\B747v3_RNinputs
14=Lua LuaB747v3\\B747v3lights
15=Lua LuaB747v3\\B747v3Panels
16=Lua LuaB747v3\\B747v3MotorQuad1
17=Lua LuaB747v3\\B747v3MotorQuad2
18=Lua LuaB747v3\\B747v3ATstate

(1) For the B744 MCP-EFIS-DSP hardware unit I used 4 distinct Arduino Mega 2560 units, each on a dedicated COM port, hence Lua's 1 through 4.

(2) I created my own 2-D panel set for the PMDG 747-400 v3, because it did not come with native 2-d panels. I wrote individual .XML Gauge files for the Captain's Panel, Centre Panel, Co-Pilots Panel, Throttle Quadrant, Rear Pedestal, Forward Overhead and Rear Overhead. Each of these gauge files write to custom LVars which are then communicated to the sim via distinct Lua plugins. Hence Lua's 5 through 10.

(3) I built a universal radio-navigation hardware console containing 3 Arduino Megas, each on a dedicated COM port. However, as the B747v3 interfaces with this console in a unique way, the 3 associated Lua plugins are unique to this aircraft. Hence Lua's 11 through 13.

(4) B747v3lights.lua  collects information about external lighting from my Server (cockpit) PC for transmission to the networked external view PC's (using WidevieW) to create coordinated ground illumination effects.

(5) B747v3 Panels.lua is there to start the various panel windows of the B747 in specific locations and sizes to overcome certain graphics card issues I face on my system.

(6) I recently built a Universal Motorized throttle quadrant (which you can see in development here: https://youtu.be/xM2Jp8nfjdA ) which requires a unique set of Lua's to interface with each particular aircraft that it is being used with. It contains 2 Arduino Mega's, hence Lua's 16 and 17. I also had to write another Lua to determine the Autothrottle state, in order to know when to power the stepper motors. This Lua communicates with an autoit script which extracts this information by pixel detection (method I described here:   https://forum.simflight.com/topic/78417-lua-for-pixel-analysis/ and the basic issue is brought up here:  https://forum.simflight.com/topic/92628-programmatically-discovering-whether-the-autothrottle-is-active-in-the-pmdg-747-400-v3/ )

 

Now, when I reveal that I also operate the PMDG B777-200, PMDG MD-11, PMDG 737-800, Level-D B767-300, FSLabs A320, SimCheck A300B4-203, Digital Aviation Fokker 100, Majestic Dash 8 Q400, Flight One ATR 72-500, and Aerosoft CRJ 700, and that I have built dedicated MCP's for each of them, and each of them interfaces with the other hardware/software (radio-nav console, throttle quadrant, gauge files, CIVA INS units, Wide View lighting effects) in unique ways, one might wonder how I didn't breach the maximum number of 127 earlier.

I should add that apart from the aircraft-specific Lua's that I have mentioned, I also have some common Lua's that I use for all aircraft, and these remain in the Modules folder: like for manipulating scenery on my external-view monitors (refer to this post on network panning:  https://forum.simflight.com/topic/81979-wideview-fsx-network-panning-using-fsuipc4-and-widefs/ ).

 

14 hours ago, Pete Dowson said:

I'm actually surprised that works. There was no designed intention of allowing plug-ins to be run from other folders.

As a matter of fact, I was led to this solution by your own comments in this thread:

https://forum.simflight.com/topic/74784-lua-files-are-not-shown-in-fsuipc-gui/

in which you state that "a maximum of 127 Lua files can be assigned -- the first 127 in the list in the INI file. You can have other Lua files, preferably in other folders, which can be called by any of those, or directly in [Auto] sections."

 

14 hours ago, Pete Dowson said:

No, sorry. At least not easily. You'd need to build the termination into the plug-in's code, with it instigated by an event on a key or button press.

Fair enough, I'll try to work with that.

To conclude, I have to say that "it is all your fault", Pete, for having brought this extremely powerful programming tool within the ambit of FSUIPC4, which was brilliant enough to start with. I believe I have built a uniquely versatile simulation system, and none of it was achievable without FSUIPC4 and LUA.

Thanks and Regards,

Chakko.

 

[spokes2112]

Chakko & Pete,
I wonder if this would work, using a lua & offset 0x0D70.. It may be worth a test 😉 to see.
The premise is that if the [Auto] section accepts an included folder within the name string than maybe, just maybe, 0x0D70 will too.

A possible test lua to kill all the 747 luas is below, OFC not tested. Use the command window logging. Could've, but didn't, add a display to inform you what's going on. 

If this works you could then run a single lua under [Auto] and within that lua are  the commands to start your specialized luas. OFC if this works you could also make a fully automated setup for each of your specialized folders using ipc.ask to select the specialty folder to use. It could become very easy to start/stop specialized luas that are within a folder group.

Fingers crossed for you,
Roman

-- Kill [Auto] #1
ipc.writeSTR(0x0D70,"LuaKill LuaB747v3\\b747v3inputsL")
ipc.sleep(150)

-- Kill [Auto] #2
ipc.writeSTR(0x0D70,"LuaKill LuaB747v3\\b747v3inputsR")
ipc.sleep(150)

-- Kill [Auto] #3
ipc.writeSTR(0x0D70,"LuaKill LuaB747v3\\b747v3outputs1")
ipc.sleep(150)

-- Kill [Auto] #4
ipc.writeSTR(0x0D70,"LuaKill LuaB747v3\\b747v3outputs2")
ipc.sleep(150)

-- Kill [Auto] #5
ipc.writeSTR(0x0D70,"LuaKill LuaB747v3\\b747v3Overhead")
ipc.sleep(150)

-- Kill [Auto] #6
ipc.writeSTR(0x0D70,"LuaKill LuaB747v3\\b747v3Captain")
ipc.sleep(150)

-- Kill [Auto] #7
ipc.writeSTR(0x0D70,"LuaKill LuaB747v3\\b747v3Copilot")
ipc.sleep(150)

-- Kill [Auto] #8
ipc.writeSTR(0x0D70,"LuaKill LuaB747v3\\b747v3Centre")
ipc.sleep(150)

-- Kill [Auto] #9
ipc.writeSTR(0x0D70,"LuaKill LuaB747v3\\b747v3Quadrant")
ipc.sleep(150)

-- Kill [Auto] #10
ipc.writeSTR(0x0D70,"LuaKill LuaB747v3\\b747v3RearPedstl")
ipc.sleep(150)

-- Kill [Auto] #11
ipc.writeSTR(0x0D70,"LuaKill LuaB747v3\\b747v3_RN1")
ipc.sleep(150)

-- Kill [Auto] #12
ipc.writeSTR(0x0D70,"LuaKill LuaB747v3\\b747v3_RN2")
ipc.sleep(150)

-- Kill [Auto] #13
ipc.writeSTR(0x0D70,"LuaKill LuaB747v3\\b747v3RNinputs")
ipc.sleep(150)

-- Kill [Auto] #14
ipc.writeSTR(0x0D70,"LuaKill LuaB747v3\\b747v3lights")
ipc.sleep(150)

-- Kill [Auto] #15
ipc.writeSTR(0x0D70,"LuaKill LuaB747v3\\b747v3Panels")
ipc.sleep(150)

-- Kill [Auto] #16
ipc.writeSTR(0x0D70,"LuaKill LuaB747v3\\b747v3MotorQuad1")
ipc.sleep(150)

-- Kill [Auto] #17
ipc.writeSTR(0x0D70,"LuaKill LuaB747v3\\b747v3MotorQuad2")
ipc.sleep(150)

-- Kill [Auto] #18
ipc.writeSTR(0x0D70,"LuaKill LuaB747v3\\b747v3ATstate")
ipc.sleep(150)


--[[ 
THE [AUTO] ENTRIES JUST FOR MY REFERENCE
1=Lua LuaB747v3\\b747v3inputsL
2=Lua LuaB747v3\\b747v3inputsR
3=Lua LuaB747v3\\B747v3outputs1
4=Lua LuaB747v3\\B747v3outputs2
5=Lua LuaB747v3\\B747v3Overhead
6=Lua LuaB747v3\\B747v3Captain
7=Lua LuaB747v3\\B747v3Copilot
8=Lua LuaB747v3\\B747v3Centre
9=Lua LuaB747v3\\B747v3Quadrant
10=Lua LuaB747v3\\B747v3RearPedstl
11=Lua LuaB747v3\\B747v3_RN1
12=Lua LuaB747v3\\B747v3_RN2
13=Lua LuaB747v3\\B747v3_RNinputs
14=Lua LuaB747v3\\B747v3lights
15=Lua LuaB747v3\\B747v3Panels
16=Lua LuaB747v3\\B747v3MotorQuad1
17=Lua LuaB747v3\\B747v3MotorQuad2
18=Lua LuaB747v3\\B747v3ATstate
]]--

 

[Pete Dowson]

2 hours ago, ckovoor said:

(5) B747v3 Panels.lua is there to start the various panel windows of the B747 in specific locations and sizes to overcome certain graphics card issues I face on my system.

I don't understand why you need so many separate plug-ins, all in their own threads, for the same aircraft. Better with a single Lua per aircraft, loaded via [Auto.<profile>] statements. /that /Panels one is an easy exampe -- why not sort out the panel windows as the first action in such a plug-in?

2 hours ago, ckovoor said:

As a matter of fact, I was led to this solution by your own comments in this thread:

https://forum.simflight.com/topic/74784-lua-files-are-not-shown-in-fsuipc-gui/

in which you state that "a maximum of 127 Lua files can be assigned -- the first 127 in the list in the INI file. You can have other Lua files, preferably in other folders, which can be called by any of those, or directly in [Auto] sections."

Sorry, I plead memory loss through old age.

Roman's ideas look good too.

Pete

 

[ckovoor]

Hi Roman,

Many thanks for your suggestion.

To test your idea quickly, I wrote a Lua entitled killLua.lua containing the instruction, in the first instance: ipc.writeSTR(0x0D70, "LuaKill LuaB747v3\\B747v3RearPedstl"), and ran it after assigning it to a button press, but to no effect. I also tried, in the second instance: ipc.macro("LuaKill LuaB747v3\\B747v3RearPedstl"), again, to no effect. So maybe this will not work for Lua files located outside the Modules folder.

.........

Dear Pete,

Most of the Lua files which make up the initial 127 are, in fact, files communicating with Arduinos on dedicated COM ports, and for that reason, as far as I know, they cannot be combined. In this set of 18 Lua files for the PMDG 747, 10 of these are files are communicating with 9 distinct Arduinos on 9 distinct COM ports. And that is pretty much the same for all the other aircraft I fly. With some aircraft using INS units, there are more COM channels involved. I agree that with the Lua 's dealing with Gauge files and Panels, I might be able to combine some of them, but that is going to result in some massively long files, and experience with this has taught me to keep things modular. In any case I'd still go over 127 because of the Arduino-related files.

...........

Thanks and Regards,

Chakko.

 

[spokes2112]

39 minutes ago, ckovoor said:

To test your idea quickly, I wrote a Lua entitled killLua.lua containing the instruction, ..... and ran it after assigning it to a button press, but to no effect.

Bummer 😢 , was really hoping it would work for you... Oh Well.

Good Luck,
Roman

[Pete Dowson]

2 hours ago, ckovoor said:

Most of the Lua files which make up the initial 127 are, in fact, files communicating with Arduinos on dedicated COM ports, and for that reason, as far as I know, they cannot be combined.

There's no rule stating that you can only open one COM device per plug-in. Just use different handles.

Pete

 

[Pete Dowson]

2 hours ago, spokes2112 said:

Bummer 😢 , was really hoping it would work for you... Oh Well.

Good Luck,
Roman

I'm not sure that the whole pathname is needed for LuaKill. It isn't as if it needed to locate it on disk. Try it just with the Lua name only.

Pete

 

[Pete Dowson]

There is one other thought I've had.

The limit of 127 Lua files in the Modules folder is only because in the assignments encoding only 7 bits are available to encode the Lua index from the [LuaFiles] list.  Those you are starting without assignment don't need to be indexed, so aren't confined to 127.

By placing them all in the Modules folder you should be able to use LuaKill via the 0D70 method (though I've not tried that).

Pete

 

 

[ckovoor]

Dear Pete,

I spent the last few hours consolidating all the Lua files for the PMDG B747v3:

(1) all the files communicating with the XML Gauge files into a single Lua file (2250 lines of code).

(2) all the files on both input and output sides of the hardware MCP-EFIS-DSP into a single Lua file (about 750 lines of code). I used different handles for distinct COM channels as you advised.

(3) all the files on both input and output sides of the hardware radio-nav console into a single Lua file (again, different handles).

And then I ran them, and it all worked perfectly, and the performance, is, if anything, better than before! I mean the displays, and the controls appear more rapidly responsive than before.

So I shall be following your initial advice to consolidate/rationalize all the LUA files across my system, and return them (in their much smaller numbers 😉) to the Modules folder which is their ideal home. And in this way stay far away from the 127 file limit.

I'll look into the other suggestions/points also, over the next few days.

Thanks for your help and support!

Regards,

Chakko.

 

[Pete Dowson]

2 hours ago, ckovoor said:

And then I ran them, and it all worked perfectly, and the performance, is, if anything, better than before! I mean the displays, and the controls appear more rapidly responsive than before.

Great news!

Pete

 

[aua668]

Hi,

One observation from my setup: I tried once to combine my dedicated modules in a single LUA file. If they use a lot of event triggers (radio knobs with GoFlight hardware typically produce 8 different button actions) the performance was worse compared to the single LUA modules. Therefore I stayed with smaller modules with fewer event.button triggers.

Rgds

Reinhard