Factorio Forums

G'day. Originally I posted this to the #factorio-modding IRC channel, but I decided to also write it up here for discussion. I'm curious about people's opinions on this, as well as how the developers view it. So… here goes:

I'm new to Factorio - I started playing with 0.13 on Steam. I'm a front-end / UX developer by trade. I've been exploring the modding API for the game mostly to have some fun with it (hey, I like programming), but also to address some of the issues I feel there currently are with the game's combat (loving the game on the whole, though).

I've explored the forums a little (mostly using search and Google) to get the answers to some questions I had about modding — things like the custom input data types, which aren't really documented outside a thread I found here.

It seems that at the moment the mods are heavily server-focused; they all run on the part of the game that controls game state and in the case of multiplayer I would guess can make modifications server side only. This isn't super clear from the API's and such, but after browsing the forums and reading some dev responses that seems to be the approach.

There are quite a few modding options that could benefit from client-only changes — generally around user experience (UX). This is mostly for front-end stuff (I'm a front-end developer by trade), but I think the the ability to read client data and make client changes are important. These don't have to directly affect the game state, but can generally be used to smooth the user experience and determine which events we want the server to process.

For example, getting and interacting with the mouse (mostly using the cursor position, which seems to exist as a setter but not a getter in the LUA API). Or interrupting an event before it gets sent to the server (say, you want to override base game behaviour or overload an input key). Implementing new functionality outside the standard paradigm of just creating new objects and assets.

In summary — I'd like some freedom to smooth over certain UX elements, mostly so I can get more friends on board with the game (already dragged a couple in). Things like top-down mouse targeting for combat. Currently though these kind of client-side improvements don't seem to be possible (though if they are *please* point me in the direction of the correct API!).

Anyway, thanks for reading :-).

There is no concept of "server" or "client" when it comes to mods. All peers (the server included) simulate the exact same game and mods.

When player A clicks a GUI that event is processed by all peers and every mod on all peers gets the "gui_clicked" event with the associated LuaGuiElement that was clicked. The actual click may have happened half a second ago or more but that doesn't matter. The mod got the event and knows what GUI element was clicked and processes it how it wants to process it.

Gui elements *have* to be part of the game state if they get persisted - because they have to be saved in the map. They also have to be part of the game state because data about the GUI element needs to be known by all peers as they each process the event even though the peer may not see the particular GUI element that was clicked the backing object that holds the data is available and the mod can process it as if the widget actually existed.

Peers mouse positions aren't part of the game state else we would need to track and send every peers mouse position to every other peer which would add a ton of extra overhead that doesn't need to exist.

Thank you kindly for responding. And also thanks for clearing up the architecture a bit. So I think I get what's happening a little bit more. All the peers are running the exact same game. When any one peer performs an action (that affects the game state), all peers have to perform the same action (such that game state is identical across all systems).

What about activities that do not have to modify game state? Would you consider it feasible to implement (at some point in time) the ability for mods to perform actions and read data that are not part of the shared game state. In my case, mouse pointer interaction — reading the local player's pointer, running internal logic, and then (only if the game state needs to be changed) sending that change or event to all peers (in a way that's similar to the local player performing any independent action). ie, the script is effectively submitting input on behalf of the player (since the player can clearly perform non-deterministic actions already).

Client side modding would be awesome feature.

These mods could improve user experience without need for mod to be active on server. Server doesn't really have to know everything what is client doing unless it's modyfing game state (like position of cursor or what window is displayed). And even if some stuff would have to be persited on server it could because server would not have to interpret these data.

For example things like early blueprint construction, filter deconstruction or upgrade planner could be done using client mods. Also everything that only displays some information somewhere in the corner (for example evolution factor). But in theory, even mods like blueprint flipper could be client side.

Early blueprint construction:
Mod would scan ghost items around player and place objects that player has in reach and send placement commands to server. Or it could give player some brush so player can precisely select what should be placed.

Filter deconstruction:
For this mod, deconstruction planner would have to support some pre-commit hook before items are marked for deconstruction and mod would then filter out items that should not be deconstructed. Rest of items would be then marked for deconstruction by sending list of deconstructed items to server.

Upgrade planner:
Player sets what upgrades should be done and then selects area (not using new item but by clicking mod's button). Old items are then marked for deconstruction and ghosts are placed for new items.

I could go on but hopefuly you get the idea that not everything have to be interpeted by server without breaking the game (and if it does, your architecture is probably wrong). Still I think that features I just described should be part of vanilla game.

JOndra91 wrote:Client side modding would be awesome feature.

These mods could improve user experience without need for mod to be active on server. Server doesn't really have to know everything what is client doing unless it's modyfing game state (like position of cursor or what window is displayed). And even if some stuff would have to be persited on server it could because server would not have to interpret these data.

For example things like early blueprint construction, filter deconstruction or upgrade planner could be done using client mods. Also everything that only displays some information somewhere in the corner (for example evolution factor). But in theory, even mods like blueprint flipper could be client side.

Early blueprint construction:
Mod would scan ghost items around player and place objects that player has in reach and send placement commands to server. Or it could give player some brush so player can precisely select what should be placed.

Filter deconstruction:
For this mod, deconstruction planner would have to support some pre-commit hook before items are marked for deconstruction and mod would then filter out items that should not be deconstructed. Rest of items would be then marked for deconstruction by sending list of deconstructed items to server.

Upgrade planner:
Player sets what upgrades should be done and then selects area (not using new item but by clicking mod's button). Old items are then marked for deconstruction and ghosts are placed for new items.

I could go on but hopefuly you get the idea that not everything have to be interpeted by server without breaking the game (and if it does, your architecture is probably wrong). Still I think that features I just described should be part of vanilla game.

All of the things you describe are changing the game state and would have to be run on all peers in a multiplayer game to work - that's not client side anything

Also those 3 things you listed already exist as mods (and the filtered deconstruction planner is already part of the game as of 0.15.0).

I know those mods already exist, but they have to be installed on server.

The point of client side mods is that they can modify game state (by sending changes in the same way it happens when you place stuff manually) and that is something that doesn't have to be run on all peers.