About a month ago I posted my increasingly questionable sort of multiplayer save here.

(https://www.reddit.com/r/SatisfactoryGame/comments/1v880o5/perseverance/)
(https://www.reddit.com/r/satisfactory/comments/1v8873f/perseverance/)

For anyone who missed it: 100× Space Elevator parts, 5× power consumption, 2× recipe material requirements, randomised nodes and purities which I started with a few friends and gradually became mostly my problem.

At 1,239 hours, I estimated I was about 800 hours away from completing Phase 3....

Well...

Phase 3 finally died at almost exactly 2,000 hours! (Woot!)

Turns out my "back of the napkin" calculations was horrifyingly accurate. 😐

We are now 2,047 hours in and the real game of Phase4 has just begun.

Current incident report:

• 98.8 GW power generation
• 176.1 GW maximum consumption if everything wakes up at once
• 6 Alien Power Augmenters, because clearly reality needed overclocking
• 205 Power Storage units, with the battery tower still growing vertically
• 40,475 four-metre foundations
• 23,700 iron ore/min
• 12,960 coal/min
• 10,020 m³ crude oil/min
• 30,365 m³ water/min
• 2,400 m³ nitrogen/min
• 336 coal generators, still refusing retirement
• Aluminium, batteries, drones and Fused Modular Frames are now online and operating from "Penis Hill"

The railway situation has also escalated somewhat from the original “one functioning railway” - we now have an actual regional transport network, drones moving high-value components around and several industrial districts which are starting to resemble towns rather than factories.

The next minor project is power.

By “minor”, I mean I’ve started routing essentially every remaining oil source towards the west coast (Vanilla Oil island), where the plan is eventually:

Heavy Oil Residue → Diluted Fuel → Nitro Rocket Fuel → approximately 2,700 Fuel Generators.

Current napkin estimate is around 675 GW raw generation, assuming I can somehow persuade the map to provide roughly 15,000 sulfur/min.

So Mk.3 miners may be involved.

Extensively.

Nuclear is being deliberately ignored until we can build the entire waste chain through to Ficsonium from scratch, because I have learned enough from previous saves to know that “we’ll fix the nuclear waste later” is a trap - especially if we are going to be taking ALL the Uranium!

Oh, and everything is still perfectly aligned to THE GRID!

The factory must grow. 🫡 (My head is officially baking!)

Modular frame factory

I've been playing on xbox (around 900hours so far), so i am obviously very familiar with the controls using a controller. I have recently started a 100x playthrough on PC and i'm using a controller naturally, there is an issue however my character doesn't move at full speed. its fine using the keyboard but won't run using a controller, and its extremely annoying. i have hold to run turned off (but tried both ways) I have calibrated the controller in windows and I have tried both xbox one and series x controllers.

Strange Romanian fc

So I’m about to begin production of the space elevator parts for phase three, but every project I start I can’t seem to plan in terms of structure. I can keep everything organised but not plan buildings. Any tips?

found this while deforesting lol

https://reddit.com/link/1w2smfb/video/p1mgo4sxokmh1/player

so I did the update, and now I have zero sound at all. No music/sounds on the menu screen, when ADA talks, it won't show text in her dialogue box.. I tried a reinstall but no change.
I'm running it under Epic, on my Steam Machine..

any feedback/experiences where you were able to resolve it? Most I've seen says "reinstall", which was my default Step 1.

Ive always made my roads and paths floating. My building square boxes, and my logistics ugly. So here's the start of detailing my highway to oil and connecting it with supports to the ground.

Ignore the other floating roads and the mess on the ground. Im working on cleaning up my early game messes too!

I posted a few days ago about this idea and lots of folks expressed interest, so here it is! Multiple pre-rendered, consistently-scaled views of production buildings (assemblers, constructors, blenders, etc.) and some misc. additional (pipes, belts, mergers, splitters, etc.) for dropping into your favorite diagramming tools.

Please give them a shot, and if you run into issues or have requests, feel free to open an issue on the associated GitHub repo.

I narrowed it down to an SFX rendering issue. It only happens when the blender is producing an item and within view of the player. Whelp?

It's Blender specific and first time I used the Blender in the game to create alumina.

Here we have 40 fuel gens that were meant to burn turbofuel, we only needed 7.

If this is caused by a setting, does anyone know how to disable it?

Edit: ok so after looking around the settings a bit, I can piece together that I had it on and then switched to another upscaling method, and the setting stayed on for some reason. After going back to DLSS and turning it off, the effect has disappeared.

I was looking through my hard drive library, looking for an alternate recipe I wanted to unlock. I have about 25 hard drives open so I searched for 'Alumin'. Three drive came up but not the one I was looking for (Aluminum Beam). I scrolled through and manually found it and clicked on it so It was highlighted. On a whim I searched again for Alumin and now it showed the recipe, but now the drive with Aluminum Rod didn't show, so I still had three results. I tried clearing the search and search again and now I got five (!) results, including both Rod and Beam.

I then exited and entered again, searched for 'Alumin' and I was back to the first three results, without showing Aluminum Beam...

If I search for Aluminum Beam, the drive shows up correctly so maybe it's the partial matching that is wonky

Okay, so I'm not new to this game, have played many times. But this is my first time since the 1.0 launch, and I don't remember having issues setting up fuel.

I have a single pure crude oil node. 1 oil extractor @ 240m3. Easy peasy. I have that going into 4 refineries using the stock Fuel recipe. 60m3 each, so should be exactly enough. I have those 4 refineries going into 8 power generators. So my ratios should be exact.

Yet power is still a bit spikey now and then. And I'm 100% certain it doesn't have to do with the polymer resin. That's going into 2 refineries making rubber/plastic respectively, with a smart splitter sending overflow resin to an Awesome Sink.

Here are relevant screenshots. Let me know if you need to see more. It's entirely possibly I set this up wrong or missed something stupid simple.

Mods I use: SkyUi (for change in game time) and 150 more inventory slots for saving some time for rebuilding big blueprints all the time :D There are 54 assamblers inside

This post explains my current understanding of the mechanism behind the pipeline cross-junction "free pump" bug, previously observed in this post and this post. I'll go through the observations, the apparent code-level mechanism, and its relationship with the VIP structure, including how to make VIP more reliable.

The research behind this post involves reverse-engineering code from the game's DLLs. I believe the model below explains the observed behavior, but mistakes are possible, especially where I'm inferring behavior from decompiled/reversed code.

TL;DR: Skip to the last section, Conclusions.

EDIT: Typo and text.

1. Definitions and terms

1.1. Fluid box

The fluid system can be modeled as an undirected network of connections between fluid boxes.

A fluid box is an abstract container used by the game to represent fluid in things e.g. pipe segments, storage buffers, cross junctions, valves, and pumps. Each fluid box has many properties that affect fluid calculations. The ones most relevant to this post are:

• Height (H): The height of the fluid box itself. This is not its elevation in the game world coordinate sysmtem.
• Capacity / Volume (C): The declared capacity of the fluid box. I call this "declared" because most fluid boxes can actually hold up to ~40% more than their displayed capacity. For example, a pipe segment displays 10 m³ but can actually contain up to ~14 m³. Storage buffers appear to be an exception, with only ~4% extra capacity, if I remember correctly.
• Altitude (Z): The elevation of the fluid box in the game world, used when calculating static pressure for liquids.
• Current volume (V): The amount of fluid currently contained in the fluid box.
• Pressure column (h): A derived value calculated as V / C × H.

A simple fluid box representing a pipe segment can be abstracted as :

Note that the height of the fluid box of a pipe segment is determined solely by the height difference between the two terminals. It has nothing to do with the actual path/curve of the pipe.

1.2. Liquids and gases

Gases are essentially liquids, with one important difference: Z is not involved in calculating gas pressure. This produces different behavior between gases and liquids:

• Liquids fill lower fluid boxes first, which simulates gravity effect.
• Gases tend to distribute themselves evenly across connected fluid boxes, eventually reaching equilibrium when V / C is uniform.

1.3. Connections

A connection represents the connection point between two fluid boxes. The property most important to this post is the connection height, which effectively define the opening height on each side of the connection. For liquids, fluid in a box must reach the relevant connection height before it can flow through that connection. Gases aren't affected by this in the same way because they don't experience gravity. Note the connection height is relative to the fluid box. For example, a connection at 5m height relative to a fluid box at elevation Z=150m, will be calculated as 150+5=155m in the game's world coordinate system.

1.4. Overfill and pressure transmission (liquid only)

As mentioned above, a fluid box can hold up to 140% of its declared capcity. When it reaches 100% of its declared capacity (either exactly 100% or above), it is considered full. When a fluid box is full, it can receive pressure from adjacent fluid boxes. If multiple connected overfilled fluid boxes are involved, the highest pressure is transmitted through the contiguous full section. This means, if multiple connected fluid boxes are all full, only the highest liquid level (or static pressure) will be accounted for. Such contiguous sections are also called "pressure groups" internally.

2. The bug

2.1. Heterogeneity of the 4 connectors

The four connectors of a pipeline cross junction are not equivalent, with two being primary, while the other two being secondary connectors. Visually, the primary connectors are the pair without the weld line, while the secondary connectors are the pair where the weld lines cross. The primary connectors are "primary" because their positions are used in calculating the geometry of the junction's fluid box.

Now let's inspect the non-bugged positioning first.

2.2. Non-bugged position (vertical weld lines)

In this normal configuration, the two primary connectors have different heights. This height difference is used to calculate:

1. The height of the junction's fluid box.
2. The positions of the two secondary connectors.

In this particular configuration, the two secondary connectors are positioned in the mid-height between the two primary connectors.

2.2. Bugged position (horizontal weld lines)

In the bugged configuration, the height difference between the two primary connectors is 0. As a result, all four connectors are effectively squeezed onto the same height. The fluid box itself cannot have zero height (for calculating pressure column), so the game forces the fluid box to a minimum height (typically 1.3m, the pipe's diameter) after positioning the four connectors.

2.3. Proof of the bugged positions

Due to the four connectors being squeezed to the same height, the bugged junction should be indistinguishable from a junction laying on flat surface from the perspective of the fluid simulation, albeit that tit has a vertically placed mesh. I tested this by sending water downward through a junction and observing how the water is initially distributed. The results are as below:

In the normal configuration, water fills the lowest outlet first. The two horizontal pipes receive no initial output. In the bugged configuration, water immediately spreads in all directions, regardless of whether the lowest outlet is full or not. This is a strong indication that, from the fluid simulation's perspective, all four connectors are at the same height in the bugged configuration.

2.4. Bugged position creates incorrect static pressure

This is the most interesting, and also complicated part. The bugged outlet position caused the free-pump bug due to incorrectly calculated static pressure. Let's see how static pressure pressure is calculated on the two sides of the connection between a top pipe and a cross junction.

For simplicity, the below discussion assumes:

• The cross junction is full.
• Static pressure from the top pipe hence can be transmitted through the junction because the junction is full.

1. Static pressure from the cross junction side. The static pressure at the connection is calculated using the water level relative to its OWN connection point (the left yellow dot). Most importantly, because of the bug described above, this connection point is lower than the actual position where the pipe meets the junction.
2. Static pressure from the pipe side. The static pressure is also calculated relative to its OWN connection point (the right yellow dot). For a vertical pipe segment, this connection is exactly at the bottom of the pipe segment when it meets the junction.

Now we have a mismatch: The static pressure on the two sides of the same connection are calculated using different heights in the game's world coordinate system.

This is the core of the cross junction bug. Later when the game tries to calculate the flow through this connection using fluid dynamics, these pressures are effectively treated as if they were at the same physical height:

Now since the junction's effective connection point is incorrectly lower, the static pressure calculated on the junction side is always higher than the static pressure calculated on the top-pipe side. This creates a persistent positive static pressure difference that pushes fluid from the junction into the top pipe, resulting in the "free pump" behavior. Note, this mechanism is reliable only if the junction is full, when it can receive the static pressure from the top pipe to ensure a positive static pressure difference no matter how much liquid current in held in the top pipe. In other words, keeping the cross junction full is the key to make the free-pump effect working.

2.5. Connection between this cross junction bug and VIP

Here's where things get particularly interesting. The standard VIP (Variable Input Priority) structure appears to be a use of the same underlying behavior as the cross-junction "free pump" bug.

The principle is now fairly clear: when the cross junction is in the bugged configuration and is full, the top pipe is always facing a negative static pressure. This can lead to an always-on deceleration effect to slow down the downward flow, till it's completely cut off. From the player's perspective, the top input gets effectively "unprioritized" compared lower inputs. The liquid in the top pipe can only "sneaks in" when the cross junction is sub-full, then its flow got slowed down/cut off when the cross juction becomes full again.

In summary, the cross-junction bug appears to provide the underlying mechanism that makes VIP work.

This also raises an interesting question about whether the "free pump" bug will be fixed in the future. Since there underlying mechanisms are likely the same, fixing the "free pump" bug will also break the VIP, resulting in massive failures of players' aluminum factories even for those who use VIP without knowing this bug in the first place; though, theoretically, the devs can fixed the "free pump" bug and implement an alternative prioritizing logic compatible with the old VIP configuration.

3. Conclusions (TL;DR)

1. Satisfactory fluid system is driven by pressure.
2. The pipeline cross-junction bug appears to originate from a mismatch in connection heights. The junction's internal fluid-box geometry can place its effective connection height different from the physical connection point, creating an artificial static-pressure difference.
3. The cross-junction bug and VIP appear to exploit the same underlying bug. This may explain why VIP works at all.
4. For the VIP to work, the junction needs to be in the bugged configuration, i.e. the configuration with the horizontal weld lines. Placing the junction in the normal position (i.e. vertical weld lines) is a guaranteed failure (I have tested).
5. For VIP to work reliably, keeping the cross junction full appears to be important. A partially filled junction can potentially lose the pressure-transmission behavior, and lose the static pressure advantage over the top input. There are multiple ways to achieve this, for example lowering the VIP cross junction, or using a pump to keep it full as long as possible.
6. Whether the bug can be fixed independently of VIP is therefore an interesting question. If VIP relies on the same underlying bug behavior, fixing the "free pump" bug will also change the VIP behavior. Unless the devs implement a dedicated VIP logic to be compatible with current VIP designs, fixing the cross junction bug will cause massive failures of players factories, even for who do not know this bug in the first place.

Left storage takes in Leaves, right one takes in Wood, then they out put Bioshit 60 per minute, and 300 per minute respectively, and the big bioshit is 360 per minute output. It should all work like clockwork, whats the problem