Sub Folder to hold Lua Files

[Glenn Weston]

Hi Pete,

I would just like to ask the question if it is possible to have a sub folder under the Modules folder that gets scanned by FSUIPC for Lua file registration to the [LuaFiles] Section of the INI file.

Either a pre defined folder, such as "Luafiles" for example or possibly a user definable one (or many would be better) that could be set in the INI file to host lua files, similar to the way one can define a Sound Files Path in the [Sounds] section of the INI file.

The reason I ask is that I have quite a collection of Lua files in my modules folder and I would like to have them separated from the other files that are required to be in the modules folder.

In the documentation it does say that you can have up to 256 Lua files registered , this would be rather messy if it were the case, I currently have a 112 on one of my systems so I am getting there....

So it would make sense if we could put them into cubby holes and keep it tidy. 

With many of the modern aircraft models it is becoming more necessary to run Lua Files to control things these days, so I could see this being useful for many users, not just myself.

Cheers Glenn. 

 

[Pete Dowson]

On 5/14/2018 at 4:41 PM, Glenn Weston said:

I would just like to ask the question if it is possible to have a sub folder under the Modules folder that gets scanned by FSUIPC for Lua file registration to the [LuaFiles] Section of the INI file.

Well, possible, yes. eeded? Debatable.

On 5/14/2018 at 4:41 PM, Glenn Weston said:

The reason I ask is that I have quite a collection of Lua files in my modules folder and I would like to have them separated from the other files that are required to be in the modules folder.

...

I currently have a 112 on one of my systems

How do you build up such a number? What do these actually do for you? I cannot imagine why you would ever get so many!

On 5/14/2018 at 4:41 PM, Glenn Weston said:

In the documentation it does say that you can have up to 256 Lua files registered

Actually, as for Macro Files, the limit is 127. Maybe this part confuses you?FSUIPC allows up to 256 simultaneously running Lua programs, each independently running ...
You can get to 256 running plug-ins by having plug-ins started by other plug-ins, much like the way LINDA works. In that case your plug-ins can be anywhere as you can give a path. The 127 limit is only on the ability to assign to them in the assignment drop-downs.

On 5/14/2018 at 4:41 PM, Glenn Weston said:

With many of the modern aircraft models it is becoming more necessary to run Lua Files to control things these days

But why Lua plug-ins? And do you really have 112 different types of aircraft (I don't mean different liveries or minor variations)? And wouldn't most needs for controls come down to macros for L:Vars or Mouse Macros or (for the PMDG Boeings, for example) custom controls? What are the Lua plug-ins, which really prove a way of programming rather than assignment, doing for you?

Incidentally, if you are using P3D4 and FSUIPC5, then such an enhancement is more reasonable as it is still being developed. But there, with the release of FSUIPC 5.13 you have a Mouse Macro facility which will work for all switches and knobs on all aircraft (courtesy of nice new facilities provided by L-M).

Pete

 

[Glenn Weston]

Thanks for your reply Pete, Yes I can understand why you would ask how I could build up so many Lua's.They are all for one Aircraft.

I have a very complex suite of Lua files that allow a full interface to the VRS FA/18E Superbug, The aircraft panels are completely built using Lvars.I cannot utilise any standard FSUIPC Controls to interact with any of the panels to control switches, knobs and rotary's, The Annunciator data for the lamps are also ALL Lvars.To interface my pit to this aircraft I have 68 Individual Lua Files, the other 44 Lua's are just ones that I have been fiddling and experimenting with and are just residual and can be removed, but they build up quickly when playing around.

All the INPUT Lua's need to be assigned directly in FSUIPC pull downs  to Axes for discrete knob control, Others handle Rotary Encoders, there is one main one that handles all the Toggle switches and push buttons for the aircraft. I need to be able to assign to all those  via the FSUIPC Pull downs, The Annunciators are fine and certainly could be moved to a sub directory right now as they do not require any assignments but that is only 12 of them, that leaves 56 Lua's that are required to be in the MODULES Folder but I wanted to keep them all together in one place if possible, simply to keep things tidy, otherwise they function perfectly as is.

I certainly understand that 32Bit (FSUIPC4) has come to a halt and can live with that, I could even Live with 64Bit (FSUIPC5) the way it is but it would be nice to have them separated, even if it was a SET folder that is hard coded in FSUIPC that could be scanned as well as the MODULES Folder. I know that many people these days are using Lua's more an more so it just might be a good idea to separate them and a logical step in the right direction, that's all.

So if it is possible to have this as a requested feature in 64Bit and it is not too difficult to implement, I think it would be a great Idea. Mouse Macros are not the way I want to go as this is for pit building mouseless operation and definitely a NIL Virtual Cockpit environment.

Regards Glenn.    

 

[Pete Dowson]

2 hours ago, Glenn Weston said:

So if it is possible to have this as a requested feature in 64Bit and it is not too difficult to implement, I think it would be a great Idea.

Well, I don't really think your use of Lua plug-ins is likely to be the best way to go (especially if, as it sounds, each of those is loaded, compiled and executed each time an assigned button, switch or axis movement occurs, which it sounds like), but I'll certainly seriously consider doing what you ask in FSUIPC5.

Mostly, especially for specific aircraft, most plug-ins can be compiled and pre-loaded, using the event system. that way there is the one extra thread ready and waiting for the signals it needs to operate. Also, macros can operate L:Vars with variable parameters allowing axis use. However, since you're obviously happy enough with what you've already implemented, I can understand your need. I just think it isn't such a widespread a need as you suggest.

3 hours ago, Glenn Weston said:

Mouse Macros are not the way I want to go as this is for pit building mouseless operation and definitely a NIL Virtual Cockpit environment.

Well, Mouse Macros don't use the mouse at all except for their initial creation. That's the point -- to do without needing the mouse!  I would have thought you needed to use the mouse to determine the way to use L:Vars in the first place? Or not?

Anyway, I'll put yor request on my list.

Pete

 

 

[Glenn Weston]

Thankyou Pete, I appreciate your consideration.

All my Lua's are Pre-compiled and All are event driven and written so they are pretty efficient and never get called re-entrantly. For example all the Axes assignments are done via the luavalue assignment, so the Axes value gets passed to the module that is already running..... Otherwise as you say it would not be very good and more than likely  cause something to crash, especially if had many Lua's being re-run over and over every time there was some axes jitter or something.

The suite has been well tested by the community, not just myself. I have certainly used macros and attempted to interface using them but found them too restrictive. The Lua environment allows much better integration to control things and the Luas that may not be required by certain users can be disabled by the way of a configuration file. These are fairly complex and not just a basic routine, they include selectable on screen user diagnostic utilities, pre-scaling for axes modules, all of them read from a configuration file to get required variables and some  pass variables  to each other macro's just cannot do these sorts of things. So it is very much a Lua suite for a particular aircraft that is user configurable. 

So you can see why I would like to have them in there own folder.

Thanks Pete for your great support as always.

Regards Glenn.

[Pete Dowson]

Okay. Thanks for the explanation. I understand more now,

Seems you have really got into Lua in a big way!. I'm not anywhere near as sophisticated in my efforts, but then I have a dedicated 738 cockpit and Prosim737 does most of the heavy lifting, and my own C/C++ drivers handle the hardware itself (I'm a far better C programmer than a Lua one).

I''m actually very pleased that the Plug-in system has proved so useful for the more ambitious users! 

I'll certainly see about adding a path scanning ability in the next update, but it might be an interim (DLL only) release.

Pete

 

[Pete Dowson]

1 hour ago, Pete Dowson said:

I'll certainly see about adding a path scanning ability in the next update, but it might be an interim (DLL only) release.

I've had a look at the implementation, and to keep it easy and not involve quite a hefty rewrite in order to expand the tables to accommodate more encoding information (something I'm not willing to contemplate as it would compromise stability), I will only be implementing an "either/or" setup. i.e. you either have all the Lua files in the Modules folder, or in another. The limit will still be 127 and the numbering in the [Luafiles] section of the INI will still be based on the order of the Luas in the folder, as discovered initially (i.e when they first appeared).

The numbering will stay the same if you merely copy all the Lua files out of the Modules folder and into the new one.

The path will be specified by a "LuaPath" parameter in the [LuaFiles] section, and can be a subpath of Modules (in which case just give the subpath), or a full path anywhere elsewhere on the same PC (determined by seeing a ':' character in the path, denoting a drive spec).

If this is not sufficient to meet your needs, please say so. I don't think I can offer more, at least not until there's a lot more time to spare to do a re-design of assignment encoding internally and plan the subsequent weeks or months of re-testing. This is really not likely to happen before I retire and hand over ongoing development.

Pete

 

[Glenn Weston]

Thankyou Pete, that is definately quite sufficient and would be fantastic.

Thankyou once again.

Cheers Glenn.

[aua668]

Hi,

Just to provide some information about LUA modules. I have a similar setup with around 80-90 LUA modules running fully event driven to connect my GoFlight Hardware to some complex airplanes. I wrote them for being able to run them independent per function. So one module is for transponder, one for COM1 etc.

I can start and stop them independently, which is good during development phase.

I once tried to combine them in one single LUA module. As I use naming conventions in my code, which didn't create conflicts, this was quite easily done. Interestingly the modules have been working but the responsiveness to events have been worse compared to the single modules.

You typically won't see this with single switches, but if you have radio knobs creating a lot of fast repeating events you could see, that they are reacting much slower. So my experience out of this experiment was, that it's better to have more small and independent LUA modules compared to have only a few big ones with a lot of event triggered functions. And of course the code can easier be maintained.

Rgds

Reinhard

 

[aua668]

Hi,

Just one idea for the LUA path as planned. It would be great, if this could be combined with the profiles implementation. If we could get the active LUA path and the LUA modules out of the profiles INI file instead out of the FSUIPC INI file (if profiles are used) like you do this for buttons, axes etc., this would allow to have several setups dependent on the plane used. This would be really great!

Rgds

Reinhard

 

[Pete Dowson]

2 hours ago, aua668 said:

Just one idea for the LUA path as planned. It would be great, if this could be combined with the profiles implementation. If we could get the active LUA path and the LUA modules out of the profiles INI file instead out of the FSUIPC INI file (if profiles are used) like you do this for buttons, axes etc., this would allow to have several setups dependent on the plane used. This would be really great!

That's as maybe, but that would definitely be a lot more work than I can contemplate at present. I would, in any case, have to start by having profile-specific LuaFiles index sections in the main INI ... [LuaFiles.<ProfileName>]. If I'm doing that it should probably also apply to the MacroFiles section. Once that is implemented it would fall naturally into the Profile Files path system.

This isn't related the the simple LuaPath facility I've now implemented and which is in test.

Anyway, I'll think about it when I've got more time to spare (and am bored flying for a change and want to get back to programming!). Sorry, but I've not actually managed to fly my gorgeous 737 cockpit now for weeks!

Pete

 

[Glenn Weston]

Hi Reinhard, Good to see somebody else can see the benefit here, it sounds like you have done a similar thing to me.

I can also independently disable particular modules that may not be required, by way of a CFG file, that also is in the Modules folder too under the current system. It is just a simple text file that all the Lua's read from to load variables etc.

And I too experienced what you say about things getting slower as the Lua's get bigger and that also lead me to breaking it all up into smaller separate chunks. The Encoder modules that I have written require very fast sampling and cannot tolerate any other activity within the routine. Axes type modules also perform beautifully but again I require a separate Lua for each knob, so the files add up quickly. My Main Switch module has over 1700 functions, this includes cycle as well as commanded switch positioning that are otherwise not available for ALL multi position rotaries. As you say they can tolerate being all in a single Lua because it sits dormant most of the time and only event triggers when a switch is flicked, a human can't flick switches fast enough to see any real delay so as for a switch routine you can certainly get away with a single Lua.

It is definitely when you want to be able to cater for ALL cockpit Knobs/Encoders that you really need to start breaking it up and the Lua count rises proportionately. And of coarse the Aircraft is ALL Lvars. There really is not any other way to do it.

Profile support would be Awesome Pete, but your initial plan certainly will help me for sure and to keep it tidy.

I imagine the profile support would also help with the limit of having only 127 Lua's Registered to the Pull Downs.

I can tell you Pete that when developing I have hit the 127 Limit a few times and found myself scratching my head wondering why I could not find the Assignment in the pulldown, But I am well aware of that now and always keep a close eye on my number of Lua's in the Modules folder.

I have to say the  Lua system is very very stable and reliable, It is a great extension to the FSUIPC system. Any trouble that I have had with it is usually more my coding...LOL! 

Cheers Glenn.     

 

 

 

 

     

[aua668]

Hi Glenn,

I solved my problem with the limit of 127 LUA files very pragmatic: I made a sub-directory per plane type with all my necessary plane-specific LUA modules and one with the generic LUA modules.

I start P3D with a CMD file. In this file I delete all *.LUA files in the FSUIPC directory. Then I copy the generic modules and the plane specific modules into the FSUIPC directory. In the FSUIPC.INI file I delete the LUA files section and add a plane specific section to the INI file.

Then I start P3D. So I simulate something like profiles for LUA files. By that simple method I can use the maximum number of possible LUA files per plane without breaking the limits if I use different planes. I also decide out of a config file, which LUA modules I have to start for a specific plane type.

@Pete: As I have a solution, for me there is no immediate need for the profile based version, if it's complicated. But It would be very elegant, as the profile specific setting are a really good way to define things differently per plane. So if this comes in future versions, this would be a nice enhancement of this already great piece of software.

Rgds
Reinhard

 

 

[Glenn Weston]

Very Clever Reinhard, I will keep that one up my sleeve....

 Cheers Glenn.