As far as I can tell you cannot access 'data' from control.lua, nor 'global' from data.lua. Currently my mod overrides the default water generation settings by editing data.water.autoplace; however I would like to make the particular behavior configurable. I use the 'global' variable (which I believe is the only variable whose value persists across saves) to save the mod's configuration settings so that it doesn't get messed up across saves (it would be very bad if the settings to control water generation changed when you loaded a saved game). Therefore I would like to do something like:
if global.foo then
data.water.autoplace = blah
end
but no part of the mod can access both global and data. Any suggestions?
Can you access data from control.lua?
Re: Can you access data from control.lua?
The data section of mod loading is executed once on program start up. The control.lua portion is excited for every game every time a map is created or loaded.
The data section of mod loading will always and ever be the same code that executes - it has no concept of a save file or settings.
The control section deals with new and existing saves but still shouldn't care about mod loading vs new game except in 3 specific functions: script.on_init, script.on_load, and script.on_configuration_changed.
You can read more about those 3 functions here: http://lua-api.factorio.com
The data section of mod loading will always and ever be the same code that executes - it has no concept of a save file or settings.
The control section deals with new and existing saves but still shouldn't care about mod loading vs new game except in 3 specific functions: script.on_init, script.on_load, and script.on_configuration_changed.
You can read more about those 3 functions here: http://lua-api.factorio.com
If you want to get ahold of me I'm almost always on Discord.
Re: Can you access data from control.lua?
I appreciate the response but I don't feel it answers my question (except implicitly in the negative). Is there no way for me to dynamically change the value of data.water.autoplace based on values in 'global' (presumably in a callback given to script.on_load)? This is important, for example, for me to avoid desync on multiplayer in case the host's config.lua is different from the players. I'm trying to think of any out-of-the-box way of accomplishing this goal but haven't found any (although I was able to get around the limitation of being unable to save closures to 'global' with some cleverness).
Re: Can you access data from control.lua?
There is currently no way to change autoplace controls outside the data loading phase when all of the autoplace controls are defined.swni wrote:I appreciate the response but I don't feel it answers my question (except implicitly in the negative). Is there no way for me to dynamically change the value of data.water.autoplace based on values in 'global' (presumably in a callback given to script.on_load)? This is important, for example, for me to avoid desync on multiplayer in case the host's config.lua is different from the players. I'm trying to think of any out-of-the-box way of accomplishing this goal but haven't found any (although I was able to get around the limitation of being unable to save closures to 'global' with some cleverness).
If 2 people changed the mod files (through a config file as you described) those two people for all intents and purposes would be running 2 different mods and would no longer be able to play multiplayer together.
We're working on a system that will be able to detect those types of changes for 0.13 and let you know when trying to join a game that either you or the person hosting the game has modified files over what you're running.
If you want to get ahold of me I'm almost always on Discord.
Re: Can you access data from control.lua?
Ok, thanks for letting me know. Currently I handle the problem of config.lua changing or being different on different machines by passing information around in 'global' to keep it synchronized. (I don't want each multiplayer session to start with exchanging config.lua files.) Unfortunately it looks like I can't do that for this particular detail, so I may have to split the mod up into two mods and have users enable/disable the parts instead of editing config.lua. (I'll print an alert to let the user know they should disable the mod and reload in case they forget to do so before loading an unmodded save.)
I assume the new system in 0.13 won't forbid you from entering a game where you have changed mod files? Just give an alert and call a script event or something?
I assume the new system in 0.13 won't forbid you from entering a game where you have changed mod files? Just give an alert and call a script event or something?
Re: Can you access data from control.lua?
If two people have different mod files they won't be able to connect as they are running two different mods at that point. Different mods are not compatible when connecting to other players.swni wrote:Ok, thanks for letting me know. Currently I handle the problem of config.lua changing or being different on different machines by passing information around in 'global' to keep it synchronized. (I don't want each multiplayer session to start with exchanging config.lua files.) Unfortunately it looks like I can't do that for this particular detail, so I may have to split the mod up into two mods and have users enable/disable the parts instead of editing config.lua. (I'll print an alert to let the user know they should disable the mod and reload in case they forget to do so before loading an unmodded save.)
I assume the new system in 0.13 won't forbid you from entering a game where you have changed mod files? Just give an alert and call a script event or something?
If you want to get ahold of me I'm almost always on Discord.
Re: Can you access data from control.lua?
I see, will there be some mechanism for users/mods to override these protections? Currently my mod automatically handles synchronizing differences in configuration across players in the same game. While the instances of the mod's files are not bytewise identical across the participants, the only differences are in configuration settings, which it can handle appropriately.
For instance, last week I hosted a game for five players to try out a bunch of different settings of the mod I wrote. Each time we wanted to try out a different variation I just changed the mod settings on the host machine and started a new game. If Factorio had refused to let people join because it detected a potential (but not actual) problem with inconsistent mod versions, I would have had to manually email new copies of config.lua to everyone playing and had them unzip the mod and install the new configuration before joining. As is, we only had to change settings on one machine and everything just worked.
The second benefit of this synchronization (and the reason I implemented it to begin with) is that in single player (or multiplayer) it allows the player to have multiple concurrent games progressing with different mod settings. The mod automatically remembers which settings go with which save file without the user having to manually change config.lua to the correct configuration everytime they load a save.
One approach that would retain the desired protections and allow mods to synchronize (and indeed make such synchronization trivial to implement) would be if Factorio had a notion of a type of mod configuration that was static over the course of a game. For example, if there were a designated file (maybe config-once.lua or config-start.lua) which was executed once at the beginning of the game and not accessible to the mod at any later point. This file would presumably populate the mod's 'global' table with the sorts of configuration information which it would not make sense to change in the middle of an ongoing game (in my case, terrain generation algorithm). There would be no need for that file to be consistent across machines because it would only ever get executed once, by the machine that created the new game. Synchronization would be trivial because 'global' is synchronized across machines in the same game.
I don't know how many other mods would benefit from such synchronization, or are as "configuration heavy" as mine. Only a handful (such as RSO) seem to also deal with world generation, and RSO is reasonably durable to having its settings changed mid-game (provided you don't mess with the square world settings).
For instance, last week I hosted a game for five players to try out a bunch of different settings of the mod I wrote. Each time we wanted to try out a different variation I just changed the mod settings on the host machine and started a new game. If Factorio had refused to let people join because it detected a potential (but not actual) problem with inconsistent mod versions, I would have had to manually email new copies of config.lua to everyone playing and had them unzip the mod and install the new configuration before joining. As is, we only had to change settings on one machine and everything just worked.
The second benefit of this synchronization (and the reason I implemented it to begin with) is that in single player (or multiplayer) it allows the player to have multiple concurrent games progressing with different mod settings. The mod automatically remembers which settings go with which save file without the user having to manually change config.lua to the correct configuration everytime they load a save.
One approach that would retain the desired protections and allow mods to synchronize (and indeed make such synchronization trivial to implement) would be if Factorio had a notion of a type of mod configuration that was static over the course of a game. For example, if there were a designated file (maybe config-once.lua or config-start.lua) which was executed once at the beginning of the game and not accessible to the mod at any later point. This file would presumably populate the mod's 'global' table with the sorts of configuration information which it would not make sense to change in the middle of an ongoing game (in my case, terrain generation algorithm). There would be no need for that file to be consistent across machines because it would only ever get executed once, by the machine that created the new game. Synchronization would be trivial because 'global' is synchronized across machines in the same game.
I don't know how many other mods would benefit from such synchronization, or are as "configuration heavy" as mine. Only a handful (such as RSO) seem to also deal with world generation, and RSO is reasonably durable to having its settings changed mid-game (provided you don't mess with the square world settings).