Mk3 drills vs belt speed.

[Dog]

An idea I just had, no belt can take the full capacity of an OC Mk3 miner on a pure node so the idea occurred to me that if we could directly attach a splitter to the out port of the miner itself it could be a way to utilize the miner to its potential. As far as I know splitters dont have a speed limit so you could get 2 600/min belts or 3 400/min and could rebalance it as you need to. Just a thought since i dont think were going to get belts faster than Mk5 and currently cant use pure nodes to capacity.

[Wolfgang]

That won't work as you need a belt to connect the miner to the splitter so you are limited by the belt again.
But the community managers already stated that they have ideas on making a fully overclocked MK3 miner on a pure node work. What exactly wasn't stated though.

[Bird_Dog]

Originally posted by Wolfgang:

That won't work as you need a belt to connect the miner to the splitter so you are limited by the belt again.
But the community managers already stated that they have ideas on making a fully overclocked MK3 miner on a pure node work. What exactly wasn't stated though.

I think he meat changing the build system so that the splitter attaches directly to the miner, not needing a belt segment.
Not sure if that would work with the game engine or if it would even be the simplest sollution.
I'm not programmer, but from my layman's perspective the simplest sollution would be to give the MK3 miner two outlets that split the outputt 50/50 between themselfs if both are connected to a belt.

[Dog]

Originally posted by Bird_Dog:

Originally posted by Wolfgang:

That won't work as you need a belt to connect the miner to the splitter so you are limited by the belt again.
But the community managers already stated that they have ideas on making a fully overclocked MK3 miner on a pure node work. What exactly wasn't stated though.

I think he meat changing the build system so that the splitter attaches directly to the miner, not needing a belt segment.
Not sure if that would work with the game engine or if it would even be the simplest sollution.
I'm not programmer, but from my layman's perspective the simplest sollution would be to give the MK3 miner two outlets that split the outputt 50/50 between themselfs if both are connected to a belt.

Yes exactly, either give the miner more outs or make splitter and mergers able to directly connect to buildings.

[Vectorspace]

The reason there aren't faster belts is that belts work by adding/subtracting one item at a time to/from the connected machine/storage/belt, and not in parallel. 780/min means 13 separate sequential subtractions per second per belt segment. Above 780/min, the game engine cannot always manage that, and items get lost or are duplicated. The same issue can already occur with the dual inputs/outputs on industrial storage containers.

So it's not specifically that belts cannot be faster, it's that items cannot be moved faster from individual inventories.

Simply adding a separate output to the mk3 miner, or allowing a splitter to be directly attached, would not solve the core issue. Because with a max speed of 1200/min and 2x 780 belts each separately subtracting from the same one inventory slot, that would be 2x600/min per belt, or 2x10/sec, or 20 subtractions per second. Too fast.

So whatever solution the devs have in mind would have to be more complex than a 2nd output or direct attach splitter.

[Gallomimia]

game obviously needs stack belts, that move stacks of 5 or 10 as a single item.

[Dog]

Originally posted by Vectorspace:

The reason there aren't faster belts is that belts work by adding/subtracting one item at a time to/from the connected machine/storage/belt, and not in parallel. 780/min means 13 separate sequential subtractions per second per belt segment. Above 780/min, the game engine cannot always manage that, and items get lost or are duplicated. The same issue can already occur with the dual inputs/outputs on industrial storage containers.

So it's not specifically that belts cannot be faster, it's that items cannot be moved faster from individual inventories.

Simply adding a separate output to the mk3 miner, or allowing a splitter to be directly attached, would not solve the core issue. Because with a max speed of 1200/min and 2x 780 belts each separately subtracting from the same one inventory slot, that would be 2x600/min per belt, or 2x10/sec, or 20 subtractions per second. Too fast.

So whatever solution the devs have in mind would have to be more complex than a 2nd output or direct attach splitter.

Wasnt part of the reason for going to UE5 that it can handle more of that processing stuff?

[Still B0r3d]

Originally posted by Dog:

Wasnt part of the reason for going to UE5 that it can handle more of that processing stuff?

No, ultimately it was to future proof the game a little more and had little to nothing to do with short term gains, U8 took 6 months to get to this stage. There is a planned fix/solution to the item throughput issue but it is currently no disclosed.

The item/min issue he is describing is a issue with floating point number precision, not something UE5 can solve as it is a problem with the way x86_64 CPU's handle math. Floating point math has a finite precision, which means they can only store a certain number of digits after the decimal point. This can/will lead to rounding errors or loss of accuracy when performing arithmetic operations on them, thus pipe/item throughput issues.

TLDR; Ultimately Satisfactory is doing a lot of math with big and small numbers and your CPU rounds off the small numbers because it is doing fast lazy math. We can't have faster belts currently because numbers being too large, this is a CPU limitation the the developers have a planned fix for.

[MC Ninja38]

I'm not sure, but I think Snoot made a statement saying that the plan is to rebalance miner output, and rebalance all recipes in the game, so that you can take full advantage of all resource nodes in the game. I know there was an official statement about doing so with oil, because full Mk2 pipes have issues. I personally think it would be best to go off binary, and have 16 be the smallest, and 512 be the largest.

[Vectorspace]

I think Snut's rebalance comment was specifically for fluids.

[Still B0r3d]

Originally posted by Vectorspace:

I think Snut's rebalance comment was specifically for fluids.

It has also been discussed in multiple livestreams pipe fluid throughput issues are the same reason we can not have faster belts. They mention other potential solutions they talked about internally but never publicly stated them, suggesting other ideas tie into the secret 1.0 stuff. All we know for sure is that they have something planned for it, but they have never given a clear and concise answer on their plan.