Factorio Forums

Simulation / logging mod for analyzing factory behavior (education & systems analysis)

Hello everyone,

I’d like to share a Factorio 2.x mod I’ve been working on that focuses on
observability and analysis, rather than gameplay automation.

The core idea is simple:
treat a Factorio factory as a production / logistics system and make its
internal behavior measurable in a way that supports
offline analysis and reproducible experiments.

What the mod does

• logs inventory changes in chests and buffers
• tracks machine-level production metrics
• records power usage and pollution per machine
• uses periodic snapshots instead of raw event spam
• provides export-friendly logs (CSV-style)

Many of these values are, of course, already accessible in-game in some form.
This mod is not meant to replace the UI, circuit networks, or existing helper mods.

What problem it tries to solve

The focus is on:

• time-based system analysis
• external evaluation of factory behavior
• changing a system and re-running it under comparable conditions

This mirrors how real logistics and production systems are analyzed.

I mainly use this in logistics and production education, where students:

• design a system
• collect operational data
• analyze bottlenecks, buffers, and dynamics
• change layouts or policies
• and directly observe the effects

With real factories this feedback loop is slow or impossible.
With Factorio, it’s fast and reproducible.

Why I’m posting here

I’m explicitly interested in technical feedback, especially from experienced players and modders:

• Are these metrics Factorio-idiomatic?
• What would you log differently?
• Obvious performance pitfalls?
• Better ways to structure this kind of data collection?

The mod is available on the Mod Portal:
https://mods.factorio.com/mod/logistics_simulation

I’m happy to discuss internals, design decisions, or specific implementation details.

It's not really about internals, or specific implementation details, a bit about design decisions, but mostly about the presentation : i think it would benefit the mod if there was an example of the collected data. You most likely have a workflow to analyze them, but not me, as an experienced player but newb modder that happened to have toyed with data viz only couple month in my life, it feels like getting the csv is only half of the job, like one brick that doesn't make a something alone. If you'd share what you would use that would be the other brick to make a something "following the instructions" instead of having another step of "research/guessing/trial and error" to do. " or in another word my feedback would be : Reduce the amount of work for grunt me to be able to see results; if i can see nice graph in couple clicks i will be hooked more easily than if i envision spending my whole morning trying to figure out what's the trendy way to do so nowadays.

Here is another post that you may be interested in, it shows example built with graphana of the kind of data you mentionned : viewtopic.php?t=112898 , albeit the collection method sound dfferent. I've heard of graphana because it's been around for a while, it was also used to illustrate this mod : https://mods.factorio.com/mod/graftorio which sound similar to me to what you are describing. If you're familiar with it or another way to display the data, i think it would be nice to add some notes on "how to", to make it extra obvious, maybe at the end of the page with a catchy graph picture

There are a lot of different mod that already exist for players to "not rely on intuition" as you mention, like helmod, factory planner, or rate calculator , i think most players interested in external tools already uses one of those, or online calculators like kirk mc donald's for things like material ratio and possible bottlenecks. But there are metrics that aren't available in vanilla factorio and a bit outside of the scope of those that may be useful to illustrate logistic puzzle, like the distance travelled by trains, (https://mods.factorio.com/mod/train-log ) ( https://mods.factorio.com/mod/train-tracker) , or a graph showing how much time they spend idle, or their average speed, which seem to me to be popular additionnal metrics for players to monitor that may be analog to trucks or carts for students ?

Also to finish with the obvious, sorry, but in factorio there's a thing called "logistic networks" and although that's not typically a super important metric in game for most players, it literally contains the words logistic, so that may be worth logging , the content of logistic networks themselves rather than individual chests. In game they can be named, and searched for certain items, and you can monitor the number of logistic bot being active or idle too, they are as fun as train to look at , but a whole lot less trouble to setup , and may be an analogy for the future of drone transportation ? x) A graph showing overtime what is being carried by the swarm of flying robots like 20% of them iron plate 10% steel plate 15 % copper plate in a pie chart or whatever smart representation sound to me like it would help making informed decisions on how to refactor the factory to reduce the number of them flying at all time, establishing priority order to target the area/ recipes that generate the most traffic first. This is something emergent from not only the assemblies numbers and rate of production, but also from their relative position, the location of roboports, the concurrent jobs , and enough complex that it is a bit beyond the scope of what calculators mathing/predicting the factory from recipe and upward can do. It sort of REQUIRE a different approach, looking top-down, measuring "after it's built and while it's working" rather than the more common calculating "before" , exactly what your mod sounds about to me, so i would log that, not sure if that make sense in your planned use cases nor if it's technically doable / realistic performance wise.

Thanks for the thoughtful feedback — that’s a very fair point, and I agree with the core of it.

You’re absolutely right that “getting a CSV” by itself is only half the story. For many people, the missing piece is a concrete example of what to do next and what kind of questions this data is meant to answer. That’s something I should make much more explicit. To give a concrete example: I’m currently using the mod in a student project that treats an existing Factorio factory explicitly not as a game, but as a running production and logistics system.

The task is not to design a new factory or to scale aggressively (“just add more machines”), but to analyze and optimize a historically grown system under realistic constraints. The factory already exists, runs stably, but performs far below its theoretical potential. Optimizations must therefore be done within the existing structure, with unavoidable side effects elsewhere — very similar to real production environments.

The workflow looks roughly like this:
The factory owner provides layout documentation and allows access to logged data.
The student acts as an external logistics consultant with no access to internal game mechanics.
Using time-series data (machine states, buffer levels, production rates), bottlenecks and inefficiencies are identified.
Concrete measures are proposed (e.g. additional machines vs. module changes, speed vs. energy tradeoffs).
A quantitative effect is predicted.
The change is implemented.
New data is collected and prediction vs. reality is compared.

In this context, the logger is not meant to replace planners like Helmod or Factory Planner. Those are design-time tools. This mod is about run-time observation: measuring what actually happens after a system has been built and is operating under load.

That distinction is also why I deliberately avoided built-in dashboards. In teaching and analysis, the important step is not “seeing a nice graph”, but understanding why a graph looks the way it does, and being able to relate it back to structure, layout, and control decisions. That said, I fully agree that providing example data and a minimal analysis workflow (e.g. a simple plot of machine states or buffer levels over time) would lower the entry barrier significantly, and that’s something I plan to add to the documentation.

Your suggestions regarding additional metrics (e.g. train behavior or aggregated system-level views such as logistic networks) are also very much in line with the overall idea. Especially system-level, emergent behavior that cannot be derived easily from recipes alone is exactly the kind of thing this approach is meant to support. Whether and how far that is technically feasible and performant will have to be evaluated carefully, but it’s a good direction to think about.

So thanks again for the detailed feedback — it helped clarify both how the mod is perceived and where the presentation can be improved without changing its core philosophy.