Factorio Forums

Sorry if this is an exhausted topic, I did try using search and I couldn't find a thread that was exactly the same.

I'm suggesting two functions for LuaHelpers, and they would probably only work in the Prototype stage:

• file_exists: Returns true if the filepath contains a file.
• read_file: Returns the contents of the file as a string, or nil if there is no file.

Crucially, these functions have exactly the same restrictions as require, except it works on all FileNames not just LUA files. You can't use them for files in script-output etc. require currently doesn't break determinism, so neither should these functions.

My motivation is the mod Modlist UI, which attempts to gather all loaded mods' metadata and display them in-game. Instead of asking for an expansion to the active_mods table, I thought it would be interesting if a mod could read another mod's info.json directly and parse it using helpers.json_to_table().

Possibly add list_files as well (similar to Unix ls command) to allow recursive exploration of a mod's file tree, but I can see why you wouldn't want that.

This isn’t likely to happen since files outside of active mods are not guaranteed to exist on all players computers and as such would cause desyncs if used in multiplayer.

Shemp wrote: Fri Feb 13, 2026 2:30 pm Crucially, these functions have exactly the same restrictions as require, except it works on all filenames not just LUA files. You can't use them for files in script-output etc. require currently doesn't break determinism, so neither should these functions.

It's only supposed to work on files inside active mods. So the argument would need to be a valid FileName.

So functionally making “require” for non lua files and having it return them as a binary blob (string).

Rseding91 wrote: Fri Feb 13, 2026 3:16 pm So functionally making “require” for non lua files and having it return them as a binary blob (string).

Yes that sounds correct, but it would work on any file (including LUA files). My reasoning is, if it's safe to run require on these files, why isn't it safe to run read_file?

I don't know if there would be issues with particularly large files, you may want to include an argument for a size limit and/or a seek offset.

Mod author of Modlist UI here. I can only minimally chime in, deferring to Shemp's more thorough knowledge than mine.

As they mentioned, I was originally considering making a post asking if LuaBootstrap.active_mods could expose a bit more of the currently active mod's meta data/info.json fields, such as author,title, etc.
The cherry on the cake would be dynamically displaying each active mod's thumbnail, but reading images at runtime would require file parsing, not just outputting a string, which I'm assuming is potentially unsafe.

Obviously, being much more flexible on what can be dynamically read and required at runtime would open the door for many other mods to implement their own thing, instead of just expanding on LuaBootstrap.active_mods. I can think of several combinator-modders that would enjoy string output in this manner.

Thinking more about Rseding's question (reading in binary mode vs text mode), these are the main things I'd like to use these functions for:

• Parsing JSON data from a file, or parsing other kinds of text file (e.g. locale files)
• Checking if a certain asset is present (an image or sound file) and conditionally declaring a prototype with this information
• Checking if a certain LUA file exists, and conditionally calling require on it. (This would be analogous to checking LuaRemote::interfaces.)

Hopefully binary mode would enable all of these possibilities.

I might be making this all up because I can't find the official documentation anywhere, but I remember reading that mods which only contain scenarios or localisation files are not required to be loaded by all players.

If this were true, that would mean it's currently possible to cause a desync with code such as:
Unless this kind of mod specifically does not count as an "active mod"?