Lua File Limit

[ark1320]

I understand that currently the number of Lua files is limited to 128 (0 to 127).  I was wondering if in a future version of FSUIPC this limit could be extended by designating certain Lua files to be aircraft (profile) specific Lua files. Such files would then be listed under something like [LuaFiles.profile_name] in the FSUIPC ini file.

Thanks,

Al

[John Dowson]

Hi Al,

sorry, but I don't understand why you would need this. The [LauFiles] section just contains the lua files found, and will be those that can be assigned to via the controls drop-downs.

Its the activation or use of the files that is important, and this is already handled by the [Auto.xxx] profiles section (or profile-specific assignments).

Or are you saying that a limit of 128 lua files is restricting? I find that hard to believe....

And even if I did implement something like this, how would I know which lua file was for which profile? That would only be possible if using profiles in separate files (but even then problematic...would need profiles in separate folders!).

Sorry, but I don't see an issue here or how it can be improved.

John

[ark1320]

1 hour ago, John Dowson said:

Or are you saying that a limit of 128 lua files is restricting? I find that hard to believe....

Yes, I have run into the 128 Lua limit a number of times. When you have scripts for multiple planes the total can add up quickly.  If something like I described was to be implemented, you could add a prefix or postfix to the Lua scipt name to identify the profile. For example, Lear35_checklist.lua might become [L35]Lear35_checklist.lua where the profile name is L35, etc. Or perhaps profiles could be numbered or lettered with a single character,  and you would prefix the script name with the associated number or letter. Just a thought.

Thanks,

Al

[Pete Dowson]

20 minutes ago, ark1320 said:

Yes, I have run into the 128 Lua limit a number of times. When you have scripts for multiple planes the total can add up quickly. 

Usually many of the actions you have the Lua doing are similar, if not the same, across many or most aircraft. Even if they are different you can of course check in the Lua code which aircraft it is before determining what to do.

I am interested in what applications you have for plug-ins which need so many separate scripts. Can you explain so that we can understand, and possibly suggest more efficient ways of doing things?

The problem with expanding the number is the amount of error-prone work involved in changing the method of encoding the assignments. The limit is due to the number of bits available in the 32-bit value used -- 8 bits for selecting between 127 Lua plug-ins and 127 macro files. And any change in this encoding would render all existing FSUIPC configurations incompatible. There would have to be a conversion program or a complete restart for existing users, even if they don't use plug-ins or macros.

Such an upheaval is really not a good idea during a period of continual development needed for MSFS.

But, as I said, if we could understand how you are reaching this limit we could look at better ways.

Pete

 

[John Dowson]

Adding to what Pete has said, I think you just need to re-organise your luas. I would have thought that if this was really an issue, then it would have been asked for long ago by the LINDA developers. And this is not a simple change, for the reasons described by Pete.

John

[ark1320]

I try to avoid having to use the mouse and have lots of scripts for controlling switches and buttons in different airplanes and of course they all use different Lvars, and scripts for calling up different checklists which are aircraft specific, and also more general scripts (like moving an aircraft to a new location in the air) that apply to multiple aircraft.  And yes, there are ways to consolidate. Typically what I do now if necessary is to convert the separate scripts into functions which are then then combined into a single script and selected based on an assigned parameter ( ipcPARAM, flag, etc) value. So, for example , I now have a controls script for the Lear35 that has 47 different functions in it.

Given the difficulties of making a change in the Lua scripts limit as outlined above, I agree it does not seem like a reasonable course of action at this point, especially since apparently no one else has raised the issue.  The idea of tying scripts to an aircraft profile seemed like a nice organizational feature so I decided to ask to see what might be involved. As I said, it was just a thought.

Thanks very much for the responses and explanations.

Al

[Pete Dowson]

3 hours ago, ark1320 said:

The idea of tying scripts to an aircraft profile seemed like a nice organizational feature so I decided to ask to see what might be involved. As I said, it was just a thought.

Yes, thank you. If, when more time permits (stabilised MSFS? 😉 ), if an easier way can be worked out, such a change would be considered. It's one of those things that when you first implement something you don't see coming. And, in fact, the Lua and Macro facilities were bolted onto a previous design, so the original limitation dates back a long long time.

Talking of which, I assume you do also know that macros can be used to set L:Var values? Not read them though. See page 39 (or thereabouts) in the Advanced User's guide. There's the 127 limit on the number of macros too, of course, but they can be more efficient than plug-ins unless the latter are pre-loaded and operated by events.

And of course Mouse Macros are very useful for operating buttons and switches not accessible by normal (or <custom>) controls. The panel with the switch does not have to be visible at the time, and they are probably more efficient than both of the other two methods, not requiring any disk access or thread switching.

Pete

 

 

[ark1320]

6 hours ago, Pete Dowson said:

Talking of which, I assume you do also know that macros can be used to set L:Var values?

I do need to make more use of macros. Can a Name.mcro file have more than one Lvar listed in it, for example:

[Macros]
1=L:PITOT_L=Toggle
2=L:PITOT_R=Toggle

For some reason I only see the first Lvar listed in the P3Dv4.5+ FSUIPC6 keys drop down list.

Thanks,

Al

[Pete Dowson]

4 hours ago, ark1320 said:

I do need to make more use of macros. Can a Name.mcro file have more than one Lvar listed in it, for example:

[Macros]
1=L:PITOT_L=Toggle
2=L:PITOT_R=Toggle

For some reason I only see the first Lvar listed in the P3Dv4.5+ FSUIPC6 keys drop down list.

That's odd. I don't know of any reason off-hand why you can't have multiple entries. I get the same. The documentation isn't explicit n this, but then it doesn't say it's any different from other macro files. The only restriction should be that, whilst you can have multi-line macros, you can't mix L:Var actions with other types. The L:Var name is the macro name (preceded as usual by the .mcro file name).

{LATER]

I experimented and found a workaround.  Strangely, if you have just one non-LVar macro included in the Macro file, all the LVar entries are listed too. So you could add a real non-LVar macro, or just invent one you'd never use and does nothing (eg 3=XXXX=C0000).

What is strange is that this oddity has not been reported before.  So I tried it in FSX with FSUIPC4: it works fine there! So it's a relatively new bug! Though it is the same in FSUIPC5, so the bug has presumably existed since P3D4 was released.

Pete

 

 

[John Dowson]

This is rather odd! I will look into this when time permits.

John

[Pete Dowson]

2 hours ago, John Dowson said:

This is rather odd!

Yes, it is very odd! Turned out to be a bad return from a standard Windows function. The 32-bit version (used in FSUIPC4) returns a different result to the 64-bit version (in FSUIPC5, 6 and 7) for exactly the same file and same parameters. There is an alternative way of doing the same thing so we will implement that.

Pete

 

[John Dowson]

This has now been corrected in FSUIPC6 v6.0.11 and FSUIPC7 v7.0.2, both to be released shortly.

John

[ark1320]

 

4 hours ago, Pete Dowson said:

Yes, it is very odd! Turned out to be a bad return from a standard Windows function. The 32-bit version (used in FSUIPC4) returns a different result to the 64-bit version (in FSUIPC5, 6 and 7) for exactly the same file and same parameters. There is an alternative way of doing the same thing so we will implement that.

 

3 hours ago, John Dowson said:

This has now been corrected in FSUIPC6 v6.0.11 and FSUIPC7 v7.0.2, both to be released shortly.

John

Thanks to both of you for the great support once again!!

Al

[Donovan]

On 11/27/2020 at 10:58 AM, ark1320 said:

Given the difficulties of making a change in the Lua scripts limit as outlined above, I agree it does not seem like a reasonable course of action at this point, especially since apparently no one else has raised the issue. 

Sorry to make a late addendum to the thread, the limit to the max number of lua files has come up before, but in a different context, but I suspect you were already aware of it.  You've probably already worked out a solution, but you might want to also look over the thread:

It might be useful for you...  Or not...

[ark1320]

4 hours ago, Donovan said:

It might be useful for you...  Or not...

An interesting thread -- thanks!

Al

[aua668]

Hi Al,

As my solution was mentioned: I had a similar problem like you with coupling several aircraft types to my GoFlight hardware. But by moving the necessary routines to sub directories per aircraft and by having a generic startup routine, which starts the necessary modules depending on the aircraft type loaded out of the respective subdirectory, the limit was no problem anymore. So I can definitely recommend to go for that approach.

Rgds
Reinhard

 

[aua668]

Hi,

 

Just to add: In the meanwhile I make it much easier: I have the LUA files per aircraft in a separate directory:

<FSUIPC folder>\LUA\A320
<FSUIPC folder>\LUA\DH8D
:

In my master start routine I first determine the aircraft type out of the name read out of the FSUIPC offset. Then I start the necessary modules directly out of the subdirectory:

ipc.runlua ( "LUA\\A320\\A320_GF_EmergLt" )

Attention: use the double \\ for subdirectories !

In fact I have a LUA table defined in a profile module and run each module out of a loop:

-- init all GF functions defined in the AC profile

local k=0
local j=0
local v=""

for  k in pairs(AC.GF) do

	for j,v in ipairs(AC.GF[k]) do
		ipc.runlua ( v )
		ipc.sleep(500)
		ipc.log (v.." initialized")
	end

end

Profile:

-- init GF tables
AC.GF = {}

-- GF-RP48 Unit 0
AC.GF.RP48_0 = {
	"LUA\\A320\\A320_GF_TOConf" ,
	"LUA\\A320\\A320_GF_ASkid" ,
	"LUA\\A320\\A320_GF_ECAM" ,
	"LUA\\A320\\A320_GF_EmergLt" ,
	"LUA\\A320\\A320_GF_SeatBelt" ,
	"LUA\\A320\\A320_GF_NoSmoke" ,
	"LUA\\A320\\A320_GF_WxrBright" ,
	"LUA\\A320\\A320_GF_WxrTilt" ,
}

-- GF-RP48 Unit 1
AC.GF.RP48_1 = {
	"LUA\\A320\\A320_GF_Bat" ,
	"LUA\\A320\\A320_GF_Altern" ,
	"LUA\\A320\\A320_GF_Avionics" ,
	"LUA\\A320\\A320_GF_BusTie" ,
	"LUA\\A320\\A320_GF_FuelPump" ,
	"LUA\\P3D\\P3D_GF_ParkB" ,
	"LUA\\A320\\A320_GF_APU" ,
	"LUA\\A320\\A320_GF_IGN" ,
	"LUA\\A320\\A320_GF_ABRK" ,
}

Rgds
Reinhard

 

[ark1320]

15 hours ago, aua668 said:

Just to add: In the meanwhile I make it much easier: I have the LUA files per aircraft in a separate directory:

Reinhard,

Thanks for the detailed info -- very nice.

Al