What's the difference between data.lua and data-updates.lua?

[Nicksaurus]

Some mods (and the base game data) have an extra file called data-updates.lua. What's it for? Does it get read after all the other mods' data.lua files have been loaded or something?

Also, are there any other file names that the game looks for besides those two?

Edit: Actually, I just found information about it in the changelog for 0.11:

Added phases to the mod loading. data.lua of all mods is loaded first, then the data-updates.lua and the data-final-fixes.lua as last.
This allows mods to change the data of other mods without the need to be last. This is used even in the base game, to add the
dust effect when a building is created, so the effect is added to mod buildings as well.

[Degraine]

That's a handy bit of knowledge, it should be documented on the wiki, if it isn't already.

[Jon8RFC]

Thank you for posting this. Your post is the useful google result.

[Bilka]

What's wrong with https://lua-api.factorio.com/latest/Data-Lifecycle.html ?

[Jon8RFC]

I see that is linked to on this page, and I probably skimmed through it and decided it wasn't what I needed.

I've been wondering what the difference is while reading through the following pages in recent days:
https://wiki.factorio.com/Tutorial:Mod_structure
https://wiki.factorio.com/Tutorial:Mod_settings
https://wiki.factorio.com/User:Gangsir

But there's no helpful information out in front for a beginner without tribal knowledge, and the data-lifecycle also doesn't explain the practical application like this tiny, concise bit of text:

Added phases to the mod loading. data.lua of all mods is loaded first, then the data-updates.lua and the data-final-fixes.lua as last.
This allows mods to change the data of other mods without the need to be last.

Which would be helpful to learn upfront and then learn the technical side. Because of that, I now infer that the multiple settings files are there for the same reason, which also made no sense to me beforehand.

The way I've interpreted it, from everything I've read including the data-lifecycle page, is that it's just dividing data.lua into three parts. Instead of setting x=1 (data.lua), it was so that you could say x=1 (data.lua), actually x=2 (data-update.lua), I've changed my mind again and x=1 (data-final-fixes.lua). I was pretty sure that wasn't correct, but there was no explanation about the practical application. NOW...if I read data-lifecycle, the "first, next, finally" makes perfect sense. It's similar to showing the Factorio tutorial/campaign to people who have never played it versus those who have played Factorio or a similar game. I can't go back to not knowing it now, so of course it is a helpful page to me, now.

There's the technical part, which is always great to have especially for more complicated functionality and troubleshooting, but there's no practical application part or introduction, which is what's helpful to have before explaining the inner workings.

It's like if a developer was giving a presentation on a surprise and brand new Factorio feature, and their first sentences to the other devs were:

Code: Select all

this code checks which technology has been researched
this code checks if the player is driving
if they're driving, this checks how fast they're moving every tick
if theyr'e moving faster than x/tick (as referenced by technology researched), do the next part...
this checks if they've moved a distance greater x/tick between x1,y1 (previous tick) and x2,y2 (current tick)

A better start would've probably been

This new feature checks if construction bots can keep up with a fast-moving player and whether the playing just driving fast in a tiny circle or actually driving away, because bots will get left behind if they go to build/repair stuff nearby and aren't as fast as the player is moving away. Next, I'll read aloud the comments of each part of the code...

Heh, sorry for the wall of text, but since y'all know this stuff pretty well, I wanted to make sure I communicated my LACK of understanding. I didn't want to add it to the wiki because I hadn't decided where would be best. I definitely think that little explanation should be added, though, maybe in more than one place.

[eradicator]

Hm.. @Bilka:

First the data.lua file is called for each mod. Next, the data-updates.lua file is called for each mod and finally the data-final-fixes.lua file is called for each mod.

This is indeed ambigious as to the fact that it completes each stage for all mods before loading the next, as opposed to doing them all for each mod and then for then all for the next mod. I think i remember this phrase being complained about before, possibly by myself :p. Maybe...by saying it explicitly once?:

First the data.lua file is called for each mod. After it has been called for all mods, the data-updates.lua file is called for each mod and finally the data-final-fixes.lua file is called for each mod.

[Bilka]

Thank you both, I've added "These 3 different phases of the data stage allow to change data of other mods without needing to rely on dependencies to load last." to all docs (mod settings, data lifecycle, modding tutorial), thank you for the good wording suggestion. As eradicator points out, the loading may also not have been clear, so I also added the suggested "After it has been called for all mods" to all docs. Furthermore, the modding tutorial now gives an example for the data-updates with the barrelling recipes:

These 3 different phases of the data stage allow to change data of other mods without needing to rely on dependencies to load last. For example, the base mod creates barrelling recipes for all (then present) fluids in data-updates.lua. This means that if you add a fluid in data.lua, the base mod's data-updates.lua will add barreling recipes for it, regardless of whether your mod depends on base. Of course this also means that if you add a fluid in data-final-fixes.lua, it is created after the barrelling code runs in data-updates.lua, so no barrelling recipe gets created.

I hope that makes it easier to understand for the next person, thank you for the excellent feedback.

Heh, sorry for the wall of text, but since y'all know this stuff pretty well, I wanted to make sure I communicated my LACK of understanding.

That's just what I had hoped for, it's why I asked what the problem is :)

[Jon8RFC]

Nice, the barreling is a pretty good example of not only a practical application, but referencing something already present which can be examined. It will be something I'll look at myself. Thanks!

[eradicator]

Of course this also means that if you add a fluid in data-final-fixes.lua, it is created after the barrelling code runs in data-updates.lua, so no barrelling recipe gets created.

Nitty-nitpick of nitpickery: Some people might think that the preferred way to avoid barrel creation is to add fluids in -final-fixes now.

Thanks for changing .

[Bilka]

Okay mister nitpick, fixed.

[..] so no barrelling recipe gets created, even when desired. Because of this and similar mod interactions, it is recommended to create prototypes as early as possible. So, don't use data-final-fixes.lua to exclude a fluid from barreling, instead create it in data.lua and utilize "auto_barrel = false" on the fluid.