TL;DRFactorio's fully deterministic game engine enables, that if we have two completly identical areas, and both have the same input and output (of items, power, other events...) that both behave the same.
That can be used vice versa: Instead of calculating both areas, we need to calculate only one of them and use the results to render both. Which can be used to set up very big areas of cloned production chains to create crazy big factories.
What?The idea was born from that threads:
viewtopic.php?f=6&t=82060 Optimization idea: abstraction
viewtopic.php?f=6&t=91587 Nuclear Reactors BluePrint Cloning
This shows basically the idea
Abstraction is an idea, which can be used only either by near estimation of what comes out from a production or under very distinctive circumstances only. The cloning could solve all of that issues (but brings of course some others ).
It's very difficult to explain that idea, so first some
Glossarcontainer: one production-site, a sub-factory, a plant, a child.
cluster: A factory-street, many cloned production-sites. See picture above.
master: origin, there is - like in Factorissimo - an extra Factorio-surface (see wiki), which contains the original production-site. When in operation-mode (green lamp), that surface cannot be changed.
(virtual) clone: A child. This is - basically! - the copied rendered display of the master surface in the operation-mode green. There are no real entities and so on. The technical difference to a container is, that you will not always see the clone; when editing or so you are operating on a copy of the master.
synchronization: This is a process, that brings all clones to the exactly same state as the master (or all other clones). There are different methods to achieve that. The simplest is to "reset" all entities (just the same state as if the entitiy is just places, without any items)
state: Everything that can change in a container.
operation-mode: There are different operation-modes.
Green: Synchronized, working, input is full and output is clear (and so on, see below).
Yellow: The player is editing. All changes are made to all containers.
Red: Unsynchronized, after editing, placing etc. Something prevents the automatic synchronization to work. For example the container is not in the same electric network.
Blue: Synchronizing. See below.
DetailsHow to build a cluster?
1. We build a production-unit in a way, that has distincted input- and outputs. Nothing really complicated or different than yet.
2. Containerizing it. We have a tool similar to a blueprint to draw the borders of the container. This automatically will add the fence, the special underground-plates, the input- and output-gates, power connection (only one is allowed), and the operation-state-lights.
3. When we have done that, we cannot simply change the container anymore. We need to enter the container for that, which turns automatically the container (the whole cluster) off.
4. We can just copy paste that container: Click on the container (selects the whole container), copy it, then paste it like a blueprint. Or mark an area around the container, which copies the container plus the marked area.
5. Copying a container automatically links the clone to the master. To see, which are the same clone all linked containers are marked, when hovering over one.
How to edit/change a container in a cluster?
By defition a container is a copy of the master. Which means: If you edit one container, you edit the master and with that all other containers.
This has the advantage, that after editing all containers have the same state, no synchronization is needed. But the disadvantage is, that the containers change "magically", when you edit one.
Many things can be done, to remove that kind of magic, but I prefer this behavior, because it is just fast and straight-forward.
When is synchronization needed?
Only when you place a new container. For that case it needs to be synchronized with the existing. When you edit a container, the master is edited and with it all cloned containers.
How does synchronization work?
There are many ways to achieve that. I describe two:
This means, that all containers are reset to the state, as if freshly blueprinted. No items, all entities are reset to their initial state.
The question is, what to do with the items, that had been cleared from belts, assemblies etc. I leave that question to the implementer.
This means, that the cluster needs to be stopped (all containers stopped) and are brought into the same state. Items are requested to be placed by bots on belts and into assemblies (like with modules). As long this takes, the containers are in blue-operation mode.
How to keep the cluster synchronized?
The synchronized cluster (all green) works only, if
- there is enough items/fluids on every input of every container.
- there is enough space left for the produced items/fluids on every output of every container.
- if all containers are at the same electric network.
- if all signal-cables (in- and outgoing) are on the same common circuit-network.
- any edit of a container changes the master and so it changes all containers.
This is of course much more complex to implement and needs some changes in the Factorio engine. And I think this is not really needed, if editing a container is equal to edit all containers.
What happens if not enough input or output is full?
This is simple: The whole cluster stops working until all inputs are filled/all outputs are cleared. The lamp symbolized symbolize that (eg. green blinking). The container, which has not enough input/too much output shows extra lights (yellow blinking?).
To avoid too much waiting time I can think of small buffers in the inputs/outputs.
You can use input- and output-circuit networks, but like the electric network all inputs/outputs needs to be on the same network.
The fence takes too much space. Why I'm not allowed to change a container directly?
I didn't say that the fence needs an extra tile more space. This is implementation detail.
The fence is to prevent from accidential changes.
Technically the player operates then on a different Factorio-surface.
Think also to multiplayer: There can be multiple players in different containers, editing the same master at the same time. Dunno, if that is a good idea.
How can this be implemented as mod?
Take Factorissimo, implement the cloning/linking, a hard-reset-sync to all clones, and the rules that keep the cluster synchronized (see above). Then we only need to have the logic to pick up the items from all inputs and multiply the production for all outputs. In truth only one surface is calculating. It might depend on the size of the internal structure (bigger = better), if we will really see big performance gains.
Can I turn off single containers?
Makes no sense, because afterwards the cluster needs to be re-synchronized.
Can I turn off the cluster?
Maybe. I think to a similar mechanism as the power switch: Every input/output has a logic like the power-switch. If turned off, the input/output is closed. Output still works. That enables to "clear" a container from as much items as possible and when all items are used (nothing is produced anymore) an power-switch inside the container can turn the power off for all.
Why?- Incredible performance/UPS gain!! New targets for mega/giga/penta-factories.
- A completly new way to build interesting factories. The main target is here to serve enough items to all containers and transport the produced items away. You cannot simply rely on belt queues.
- New things that can go wrong: If you have too much containers this works extremly ineffective. That is a completly new game principle.
- Super nice looking. See the above picture. Everything is synchronized. It will look like a ballet.
- Thinking not in pure item-production, but in balanced production-chains. It will make much more sense to have one chain for all red-, green-, purple-, and so on -bottles.