Jump to content

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?

Edited by bigpak
  • Developer

@bigpak

Your workaround, as far as I can tell should be fine, As long as you end up with less than 200 locals in a compilation unit the compiler will be happy.

 

@seronis,

There is a limit on local variables in Lua. It could be upped but one really shouldn't need it.

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

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.

Edited by bigpak
  • 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)

 

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.

Edited by bigpak

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

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.

@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

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.

@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.

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

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.)

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.

Edited by bigpak

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...