Jump to content

main function has more than 200 local variables


bigpak

Recommended Posts

So, I am making one absolutely massive mod, and I have run into a bit of trouble apparently. I have more than 200 local variables for recipes and functions and whatnot in modmain.lua and it won't let me add anymore, but tell me if this is a proper workaround, if I add at the very end of my modmain.lua file

modimport "extension.lua"

and that can be an extension to modmain, so far it is working...

 

 

I know that no one should EVER hit this limit, but I have managed to, however this mod will not be released as it is just an absolute mess and is for private use aka me only.

 

Also, can someone explain modimport to me? does it literally just attach it to modmain as an extension or is it something else? so if there is things like local ing_1 = = Ingredient( "scrap_metal", 2) would I need to declare that again in extension.lua or having it once in modmain.lua will be fine?

Link to comment
Share on other sites

No clue why you think you have a limit on the number of local variables.  Your ram should be the only limit.

 

I got an error that literally said main function has more than 200 local variables, it doesn't matter what the 201nd variable is, it can be a simple print function, it will not accept more than 200 local variables and or local functions.

 

It was before the main menu, and before the I understand button, it crashed as soon as it loaded modmain.lua

Link to comment
Share on other sites

Thank you! I really appreciate the answer, however, do I need to declare something like local ing_1 = Ingredient etc in extension.lua again or will it be enough to just have it in modmain.lua and not needing to add it to extension.lua

 

The reason I have to do it through local ing_1 = ingredient........ is that if I do not, I cannot use a custom atlas for the item.

 

I would also like to add that the modding community has been most helpful and has made me see coding in a different light, and that it is actually possible for an average person to do it if they take the time to learn and ask questions.

 

I just wish I knew more about lua and coding in general to be a lot more productive as I usually spend about 6 hours a day messing about with it and drawing, I still think drawing is a lot harder, kudos to artists and people that can draw, mine looks like a preschoolers.

Link to comment
Share on other sites

  • Developer

@bigpak

 

Okay, I don't know exactly how modimport works. but it seems to behave like a require from a programmer's perspective. So in that case it wouldn't have access to the locals from the modmain, but I would just test it. Put a print with one of your locals in the import and if it doesn't complain it works.

 

Another solution is to put your locals in a local table.

 

local locals = {   local1 = 33,   local2 = "hello",   local3 = function() print("whatever") end,}print(locals.local2)

 

Link to comment
Share on other sites

To be honest, I am most likely going to stick with the modimport instead of tables as it would be quite a mess if I just had a big table, the way I organize my modmain.lua is in each section I add --nameofmodfunctiontypethinghere "<thecode> --nameofmodfunctiontypethinghere

 

However, if anyone know if its possible to easily collapse code in notepad++ I would appreciate telling me how, as the tutorials I have seen don't really give an easy way and or I don't understand them. Can sublime collapse code?

 

I'd also be interested to know if anyone else has ever run into this issue.

Link to comment
Share on other sites

well it only takes one line at the top of your code:

 

local _L = {}

 

and three letters in front of any variable name:

 

_L.blah = foo

 

To utterly circumvent the limit.  Tables are pretty trivial to use in lua.  You dont really need the curly bracket notation anywhere but the initial line

Link to comment
Share on other sites

I shall give it a try tomorrow actually, this could solve more issues, however, does this affect performance of the mod in any way? silly question I know, but I used to have about 99-100 individual mods installed, and my god that affected the performance awfully, however this is one mod, so silly question but just want to be sure.

Link to comment
Share on other sites

@bigpak If you're worried about organization, you could also make a table for each mod, instead of one large table. It would effectively reduce the number of your local variables to the number of mods you're combining.

-- Mod 1 Startlocal mod1_table = {    one = 1,    two = 2,}print(mod1_table.one)-- Mod 1 End-- Mod 2 Startlocal mod2_table = {    three = 3,    four = 4,}print(mod2_table.three)-- Mod 2 End
Link to comment
Share on other sites

Stupid question, but are you making a new variable for every recipe? I always make only one recipe variable to catch the reference, then tweak the recipe image, and catch a new recipe reference with the same variable. It works as far as I can tell, and it shouldn't interfere with the ingredient atlas stuff.

Link to comment
Share on other sites

@bigpak

I don't think it would make much of a difference if you kept it on one file or multiple files. From what I can tell, the reason multiple mods would reduce performance is because the game makes a new environment for each one.

I'm not sure how modimport works, but if it creates a new environment to load in, then it would probably be better to keep it all in one file.

 

Same goes for using tables instead of local variables, you're still storing that data either way, just in a different format. Even if one is slightly more efficient than the other, it certainly can't be the performance bottle neck of your code unless you have amazing code.

Link to comment
Share on other sites

Table lookups can be a bottleneck in code where you are navigating hundreds/thousands of elements in something because all those dereferences add up if you do it many times a second.  Most dont starve actions happen on callbacks that dont have that high of a throughput

Link to comment
Share on other sites

modimport is actually very straightforward. All it does is pass the mod name to kleiloadlua, which then checks to see if the appropriate files exist.  It then executes the code via RunInEnvironment and checks to see if it failed or not.

local status, r = RunInEnvironment(fn,env)
function RunInEnvironment(fn, fnenv)	setfenv(fn, fnenv)	return xpcall(fn, debug.traceback)end

If you want to be able to collapse code sections in notepad++, you can encapsulate them in a do...end block:

do     some codeend

This effectively tells the lua interpreter to consider all the code to be in one "block", which doesn't really have any consequences outside of using lua in interactive mode(in which case every line is normally its own block.)

Link to comment
Share on other sites

Alrighty, the most practical thing for me to do is use extension.lua it is a lot more simple and as far as I can tell from the tests I have done does not have a noticeable performance impact.

 

Atleast I have FINALLY learned how to collapse code, it's not fun to work with 4376 lines un-collapsed.

 

And yes, I am crazy.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

Please be aware that the content of this thread may be outdated and no longer applicable.

×
  • Create New...