putting things out of modmain ?

[Lumina]

Hello,

I'm trying to make a mod, and between the speech, recipe, food recipe and other stuff, my modmain is a little big for me.

I was wondering : could i put things outside of the modmain and just tell in the modmain something like "load this" ?
For example, i would like to put all the food recipe in one file, and all the speech in another. I know the game is doing this, and it will help me organize things a little, but i don't know how to do and i don't know if it's a good idea. Could it create problems ?

[rezecib]

@Lumina This is the intended use case for modimport. If you have a file right next to your modmain, such as "announcestrings.lua", you can use:

modimport("announcestrings.lua")

It just runs all the code in that file, so you can take sections of your current modmain, paste them into another file, and replace them with a modimport.

[CarlZalph]

1 hour ago, rezecib said:

@Lumina This is the intended use case for modimport. If you have a file right next to your modmain, such as "announcestrings.lua", you can use:

modimport("announcestrings.lua")

It just runs all the code in that file, so you can take sections of your current modmain, paste them into another file, and replace them with a modimport.

If I recall the modimport won't take your modmain's local variables into scope when running the file and is pretty equal to a require in terms of programming.

So chopping up the files that use local variables like say a local function or constant would need to be restated in each file.

Might be a gotcha to look out for if you do this, @Lumina

[rezecib]

@CarlZalph Good point, I was only thinking about information flow in the reverse direction.

In case that didn't make sense to you Lumina, that means that if you have a variable in the modmain, or in one file, it won't be there in later modimports. But if you do a modimport, the local variables from that file can be accessed within the modmain.

[Lumina]

Ok, thanks, i'll try some things and see how it works. I think i get the idea, if i have more questions i'll put it here

[Serpens]

9 hours ago, rezecib said:

@CarlZalph Good point, I was only thinking about information flow in the reverse direction.

In case that didn't make sense to you Lumina, that means that if you have a variable in the modmain, or in one file, it won't be there in later modimports. But if you do a modimport, the local variables from that file can be accessed within the modmain.

Offtopic:
and that's exactly the reason why I always write one really big script
There is no advantage splitting it in hundred files.It only complicates everything... But still all professional programmers do this.. and I hate it...

Edited August 28, 2016 by Serpens

[Lumina]

Oh, i'm far far away for anything professional, but i'm just a little overwhelmed by different stuff, i feel like it's better to separate things a little.

I guess everyone has a personal way to do thing and it's ok, if you work better this way

[DarkXero]

6 hours ago, Serpens said:

There is no advantage splitting it in hundred files.It only complicates everything... But still all professional programmers do this.. and I hate it...

http://www.informationisbeautiful.net/visualizations/million-lines-of-code/

You are going to get carpal tunnel scrolling for some of these projects if you dump them all in a single file.

[Maris]

If you use modimport:

x = 555 --will be accessible in modmain
local y = 777 --wont be accessible in modmain

Also you can use AddPrefabPostInit and any stuff from modmain like GLOBAL variable. Ofs you can't use "local" variables (like Y in my example) but you can define them without "local" so you can use them in any modimport file.

In other words modimport uses name space of the mod.

If you use require:

x = 555 --Will be accessible from the modmain using GLOBAL.x
local y = 777 --wont be accessible

In this case you can't use AddPrefabPostInit. Actually you can but it's not easy.

In other words, require uses global name space of the game. In this file you can remove all "GLOBAL." prefixes. For example, you can use STRINGS without GLOBAL prefix.

Edited August 28, 2016 by Maris