Simulation & logging mod: making factory behavior observable

[biggerw]

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.

[mmmPI]

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.

[biggerw]

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.

[mmmPI]

It reminded me of that galileo quote they put in civilization game when you research the scientific method : "Measure what is measurable, and make measurable what is not so" I know there's often demands for more statistics to be available in game, or different presentation, but that's also a point where many people have their own preference, so the .csv is a good compromise too if one is familiar with them. The idea of the fancy graph was not that the fancy takes over the meaningfullness, but to have an example, as if to put myself in the shoes of a student (again), i'm not sure i understand what they will have to do, what will be the form of their initial set of information to form their decision, like would they see the factory ? would it be their own ? or you build one and take a lot of data from every angle possible to serve as a model for student to propose "reforms" that you test in different games to generate another set of data for them to quantify the actual effect of their "reform" ? I think it would help (me) to have a few picture / graph, like first step you have this graph or factory, second step you collect / annalyze the data, this is how it could look, next step you change a thing, and seeing the data again after it's changed with another picture. Maybe your student don't need this much hand helding, but for a 'gamer' like me, i feel it would help "follow" for the first time, like a tutorial, and the second time i try on a different case than the example one, either for the factory, or for the .csv vizualization method.

I think the philosophy behind it is interesting because that kind of observation, modification, observation, loop and measure in between is how i play the game but i feel some of the thing you need to acknowledge to understand the behavior of a factory aren't always visible in aggregated datas, sometimes micro-behavior can have macro impact, if you have an array for furnace, and the decision from the first round of observation is to add speed module on them, it can happen that "inserter" becomes the bottleneck, say they can't output the plate fast enough from the furnace, this would create a discrepency between the expected result of the "module addition" and its actual impact in game, it would show maybe 40% increase production instead of the planned 60% on aggregated data, but without a look at the actual factory, it will be difficult to understand it is because of an inserter bottleneck, and not a lack of material that cannot match the increased consumption, or a saturated output belt, creating a backlog quite similar unless you log inserter's electric consumpton too. When you are "in" the game you can and should use those clues to make sure your design behave predictably, but if you are expected to take the decisions based on the exported datas (only), how do you adress the case when data can't be explained ? is it "not suposed to happen" or " a teachable moment", or "time to get more data" something else ? if it's the more about the fomer i can try help narrow down the cases of failures to some that could be measured via data, that's why i hinted toward logistic network, where each "factory" can be reduced to a very small number of piece, 2 chest, 2 inserters and an assembly, no beacon, large buffer of request and making sure there is always some idle logistic bot i thought it create very simple test conditions where one wouldn't have to teach students the (whole)game for them to understand the options available in their decision making.

[biggerw]

Thanks a lot for the thoughtful and constructive input — this discussion is genuinely helpful, and I appreciate the time you took to articulate your perspective so clearly.

Let me start with the visualization topic. I don’t have hands-on experience with Grafana myself, but in consulting projects clients always come with dashboards, charts, KPIs, and traffic-light systems. That’s normal — and often useful. The problem is not visualization per se, but the recognition horizon it creates. The moment you decide on a specific chart or dashboard, you implicitly decide what is worth seeing. Everything outside that horizon becomes invisible, even if it is operationally critical.

That’s why I’m deliberately cautious here. Visualizations are not neutral. They guide thinking, sometimes too strongly. Raw data, by contrast, keeps the thinking space open. It’s uncomfortable, but it’s honest. And in my experience, only raw data really “counts” in the long run — everything else is an interpretation layered on top.

That said, I fully agree with your core point: a CSV alone can feel like “half a brick”. What’s currently missing is not a built-in dashboard, but concrete examples:
- a small reference dataset,
- a minimal analysis example,
- and a before/after comparison showing what kinds of questions this data can answer.

Not as a prescribed workflow, but as orientation. That’s a very fair request, and I plan to add exactly that.

Your remarks about micro-behavior versus aggregated data are also spot on. Situations where predictions fail because of inserters, buffers, or local constraints are not edge cases — they are the reality of production systems. When data cannot explain what happens, that is not a failure of the exercise, but a teachable moment: time to get sharper data, or rethink the system boundary. This is intentional.

Finally, your suggestion regarding system-level metrics like logistic networks fits extremely well with the overall idea. Emergent behavior that cannot be derived from recipes alone is precisely where runtime observation becomes valuable. Whether and how far this can be implemented technically still needs careful evaluation, but conceptually, you’re pointing in the right direction.

So thanks again for the input. It helped clarify where better onboarding and examples can improve accessibility — without compromising the core philosophy of the mod.

Forget Maximum Utilization: Logistics doesn’t fail inside machines — it fails between them. Buffers and flows matter more than perfect utilization. This post explains why stabilizing flow beats maximizing machines, every time. https://martins-wahre-logistik.blogspot ... ation.html

Using Factorio as a Logistics Simulation: Factorio isn’t interesting because it’s fast or efficient — it’s interesting because it behaves like a real logistics system. This mod doesn’t optimize or automate. It makes factories observable and turns “I think” into “I can see”. https://martins-wahre-logistik.blogspot ... ation.html