Take a look at the tile_buildability_rules for the offshore-pump to get started; you need to define multiple rules for the different areas of your entity. It looks like you just need to set lava_tile=true instead of water_tile=true?

Good Luck!


Thanks for the reply! The main issue is that the ...

How to allow an entity (with an area larger than one tile) to be built on lava and ground simultaneously, but forbid construction on all other tiles that collide with the water_tile layer?

You don't use fluid wagons for oil or uranium mining ? because really the premise that there is a problem with fluid wagon can be discussed lol.


Nope. I use the far more effective strategy of barreling it and then transferring it over using logistics bots.

Or even better, just place your ...

True, but at the same time, it's still a game with objectives and dominant strategies (which is what this thread was specifically created to fix - a dominant strategy).


You don't use fluid wagons for oil or uranium mining ? because really the premise that there is a problem with fluid wagon ...

Just to clarify, I think some of you are misunderstanding my point. I actually really like the new 2.0 fluid mechanics and fully support the change. The near-instant distribution within a cluster is brilliant and essential for maintaining high UPS at scale. I am absolutely not advocating for a ...

Ultimately, my proposal is just an attempt to restore the value of fluid wagons without rewriting the current core simulation logic. It relies purely on geometric constraints (128 tiles including pumps for local networks, and 256 for main pipelines), dynamically scaling throughput for main pumps ...

It is only natural that everyone sees their own solution here. Some want to maximize UPS optimization while introducing a completely new layout mechanic, while others are willing to sacrifice a bit of performance to create a hybrid between the 1.1 and 2.0 fluid systems. Both ideas definitely have ...

Instead of a pump being binary (either pumping at 100% capacity or 0%), its throughput should scale smoothly based on the fill percentage of the input pipeline network. If the upstream pipe network is only 5% full, the pump dynamically throttles down and only pushes a fraction of its max rate ...

Instead of a pump being binary (either pumping at 100% capacity or 0%), its throughput should scale smoothly based on the fill percentage of the input pipeline network. If the upstream pipe network is only 5% full, the pump dynamically throttles down and only pushes a fraction of its max rate ...

Building upon @Hurkyl's point about throttling, a great way to handle pump mechanics without sacrificing performance is to make the pump speed dynamic instead of discrete.

Instead of a pump being binary (either pumping at 100% capacity or 0%), its throughput should scale smoothly based on the fill ...

hmm, im my opinion the old fluid system was simply a very elegant solution which naturally fit in with the game in almost every aspect.

I really believe we should try to improve upon that instead of taking the 2.0 system as a starting point.

Teleporting fluid is not cool.

EDIT
Tbh I think ...

https://forums.factorio.com/134574

My proposal from there:

One way to nerf it is to limit overall throughput of a pipe cluster to pumps to 1200 no matter how many pumps are attached to it, and spread it evenly between those. With that you will be forced to drag several distinct pipelines in ...

hmm, im my opinion the old fluid system was simply a very elegant solution which naturally fit in with the game in almost every aspect.

I really believe we should try to improve upon that instead of taking the 2.0 system as a starting point.

Teleporting fluid is not cool.

EDIT
Tbh I think we ...

To expand on this, instead of standard underground pipes, we could design Elevated Main Pipes. They wouldn't be allowed to intersect with Elevated Rails, which would add a layer of logistical complexity.

As a naive balancing solution, we could introduce a tiered pipeline hierarchy with layout limits to bring back logistics depth.

For example:
* Local Network Limit: A single local fluid system is restricted to a maximum of 128 standard pipes/tanks.
* Small Pumps as Internal Balancers: Small ...

Why not just introduce generic build and destroy events with support for native engine filters (like filtering by entity name)? In many use cases, this would drastically reduce the boilerplate code required for registering multiple layout-specific events. If a modder needs to track specific methods ...

Maybe we could add an option to the Selector Combinator to output ingredients based on the selected recipe? Or, if an item signal is passed as an input, it could output its ingredients in binary format (for alternative recipes), where each bit position represents one of the recipes? Of course ...

Maybe we could add an option to the Selector Combinator to output ingredients based on the selected recipe? Or, if an item signal is passed as an input, it could output its ingredients in binary format (for alternative recipes), where each bit position represents one of the recipes? Of course, this ...

To build upon what @AntiElitz mentioned, a continuous (per-tick) consumption model solves this "uneven sharing" beautifully while respecting fluid physics.

In Factorio, fluid injection is inherently discrete — upstream machines dump batches into the pipe instantly when their craft finishes.

Pros ...

I have to disagree with making this model strictly global for all machines, as doing so would seriously limit flexibility for overhaul mods. Keeping it as a toggleable property allows modders to design unique batch-processing setups and complex factories that actually rely on discrete buffers.

And ...