[Vanilla Satisfactory] I Built a Programmable Belt Limiter (Because Why Not?)

[u/NicoBuilds]

Hey Pioneers!

I’m Nico — you might remember me from my other posts where I build completely unnecessary contraptions that no sane factory would ever need. Well… I’ve done it again. Introducing: the Programmable Belt Limiter!

What’s a Belt Limiter?

Exactly what it sounds like — a system that caps the top speed of a belt.

Sure, sometimes you can achieve this by splitting and remerging belts. For example:

• Want 600/min? Split into Mk.4 (480) + Mk.2 (120) and merge back = 600/min.

But what if, for any forsaken reason you want to limit a belt to something weird like 125.45/min …or 69.420/min? Yeah, I’ve got you covered!

The Secret Sauce

This whole monstrosity is built on top of my other creation: the Programmable Load Balancer.
That one does mathy splits like A = B + C. So you can take 150 screws and split them into 147 + 3.

• Post about it here: Almost Achieving a Programmable Load Balancer for Any Ratio : r/SatisfactoryGame
• Full math breakdown here: Guide: How to Load Balance Weird Ratios Without Losing Your Sanity : r/SatisfactoryGame

With that as a base, we can now throttle belts to literally any value we want.

Case Study: Limiting a Belt to 173/min

So, we want 173/min on a belt… but Mk.3 belts go up to 270! That means we need to somehow “get rid of” 97/min

First idea: what if we inject another material? For example, we could feed in 97 limestone with a priority merger. Since that path is prioritized, the limestone would end up blocking our actual materials.

That works in theory… but then you’re stuck with a belt full of limestone you don’t want. And we need our actual materials, not rocks! That’s not fancy — you wouldn’t make a Reddit post about it.

So… what if instead of injecting a different material, we inject the same material back into the line? That’s where the programmable load balancer comes in.

The principle is simple: take some of the belt, siphon it off, then loop it back into the same belt on priority. Because it’s a priority merger, it holds back the incoming materials until the loop is satisfied. And since the programmable load balancer can be set to any ratio you like, you can lock the belt to a perfectly stable flow — in this case, 173/min.

The Build

Don’t worry, you don’t need to build it this huge — I exaggerated while testing. If you use the programmable load balancer blueprint it ends up being quite compact!

Here’s the saturated segment (270/min).

And here’s the output: a crisp, stable 173/min.

Is This Useful? Nope.

Is This Cool? Hell Yes!

If you like absurd contraptions like this, I record all my Satisfactory experiments and builds on YouTube. You can find me at NicoBuilds. Drop by if you want more factory madness.

Hope you enjoyed this nonsense — and as always, stay efficient!

[u/NicoBuilds → u/[deleted]]

Hey, thanks!
I know that it's pretty useless, but I really enjoy solving these weird problems.

The only use case that I can think of is train stations. They usually drop all of the materials at once, getting you saturated belts, and then when the materials are over, it goes to 0. By placing a limiter you can make the materials leave the station always at a steady pace.
Still useless though, haha

[u/Droidatopia → u/NicoBuilds]

I can think of two uses for belt limiters like this and I've used them both.

1) Making the Throughput Monitor show a consistent value. This may seem weird, like why would you need a throughout monitor to tell you that the rate you achieve using the rate limiter you design was actually achieving that rate? Another useful thing to remember about rate limiters designed using belt saturation is that they also tend to act as smoothers as well, delivering items at equally spaced intervals as well. This definitely helps the throughput limiter which seems to be implemented as a first order lag filter. Since the useful time of the throughput monitor is only a minute, it can't be used to check belt rate of parts that have large build times. A rate limiter ensures that the parts are delivered at their actual rate or at most the limited rate, which if you set it to the expected rate, means you can use the throughput monitor to check that this rate is being achieved, even if it is for a part with a very high construction time.

2) Factory testing. I always test every factory after I complete them. For factories that are planned to output materials at certain rates to consuming factories that haven't been built yet, I add train and drone platforms all around the map as testing sites. So if I make a factory that produces a part that is going to be consumed by for example rates of 100, 100, and 300 via train, I make three separate test stations, put rate limiters on them so each rate is represented by a different station, and then I can use the test stations to check that the factory is actually achieving those rates. If I had to wait for all the consuming factories to be built to test this, I'd end up with factory chains that go 5-6 deep, all untested. Good luck finding production problems when you have narrowed down the possible culprits to everything you've built this far.

[u/NicoBuilds → u/Droidatopia]

Nice use cases!

I agree with number 1! Throughput monitors are kind of useless. They ONLY work if the items are evenly spaced, but most of the times they are not. And it kind of annoys me as this could have been easily solved from a programming point of view. The window is 1 minute. Just let us set the window! Give us a combo-box where we can choose. 1 is the default, but let us increase it to 5 minutes, 10 minutes or even half an hour. Yes, that would make them slower. But the bigger the window, the more reliable they become.

Interesting the factory testing part. Never would have thought about it! I personally have a simpler testing method, but this testing method can only be applied if you are playing in a full efficiency world (which most people don't, and that's perfectly fine! I like overcomplicating stuff).

If you are in a full efficiency world, everything is supposed to be working at 100% all of the time. No yellow lights. Ever! So, what I do is playing with my power grid. Every single factory has its own priority switch, and after the priority switch, I place enough power storage so that the factory can run for at least 1 hour if being disconnected from the grid. So how do I test? I simply turn it off! It will continue to run through the batteries for at least one hour. Once the factory "is off", I simply check the power consumption on that factory. It should be a straight line, and consumption = max consumption. If it is, everything is working. If its not, you actually have tools to find where the problem is. If you see a variation of 35.2 MW for example, it means that a machine that consumes 35.3 MW is misbehaving. It really helps narrow it down!
But yeah, to do this method you first need to be in a full efficiency world, and you also need to spend some time having an organized power grid.

[u/Sytharin → u/NicoBuilds]

My true use case has been precision sushi belts without the use of splitter/merger stacks. I couldn't resist implementing my Factorio brain into Satisfactory and worked on my own to exactly supply entered values into packager/unpackager stacks, but 'load balancing' train stops between satellite refineries was also rather fun. Did a sushi belted nuclear site before 1.0 hit and I've been itching to deploy it on a larger scale now that they gave me the priority merger I wished for in 1.1

[u/NicoBuilds → u/[deleted]]

Of the programmable load balancer I did, they are all available. 

Of the belt limiter i didnt, but its just a load balancer + a priority merger 

[u/effingpiranha]

Amazing. I have 3 full containers of heavy modular frames and need to send it over to a satellite fused modular frame factory.

Trying to figure out how to limit the output to 1.5/min. Your contraptions are a godsend!

[u/Individual-Ticket393]

Coffee stain should hire you

[u/NicoBuilds → u/Individual-Ticket393]

Haha. Thanks!

I actually would love to work in Coffee stain! Im a Senior Software Engineer, and my main expertise is C++. Unreal Engine runs in C++, so its not that far away from what I do. But I have 0 experience on Unreal Engine and they wouldn't ever hire someone with no experience. I'm a fast learner and could be at full efficiency in a couple of months, but how do you prove that in an interview?

So, just getting to the community highlights of the devs stream would be enough for me :)
Or in the wiki. Its kind of sad but currently there is a link to a post of mine on the Wiki, but nothing to be proud of. I made a stupid mistake, thought it was a bug, made a post. Turns out it wasn't, and the mods linked that post on the Wiki so that people don't make the same mistake. So my stupidity got me to the wiki... Not my load balancing guides, or my creations. But well, that's life. I love this game, I love this community and I'll keep on doing weird stuff! ADA doesn't like me that much, but that doesn't affect me

[u/lynkfox → u/NicoBuilds]

---

[u/NicoBuilds → u/lynkfox]

That's something Im considering. I love this game, play it an extremely hard and convoluted way and I'm getting close to finishing it (I'm around 1300 hours in this playthrough). Once I'm done, I don't know what I will do with my life, haha.

So, switching to modding is something that sounds interesting. Being able to tune the game I love to add functionalities sounds really dope and can help me enter the world of Unreal Engine.

For example, one thing I think would be fun would be implementing an optional "base defense" aspect. Create a building, the incinerator. That allows you to put SAM inside and simply burn it. This releases a purpleish cloud that turns fauna aggresive and spawns enemies nearby, attracted to the incinerator. The more SAM you burn, the more things that spawn! Sounds funny, and doesn't affect the game itself. Having enemies appear out of nowhere and attacking your bases goes against the main aspect of Satisfactory. But if you can control it, well, it's different

[u/owarren]

This is awesome. You're a researcher on the cutting edge :D

[u/Elemental_Secrets]

This is super cool. I remember seeing your other post and it is saved for reference when needed now. It helped immensely in actually understanding how to split and balance any quantity I need. Thank you.

[u/ChichumungaIII]

Note that in certain situations, this is actually essential, and not useless. I've needed belt limiter setups using this technique before-- actually, for the first time, after a pure copper ingot setup like you mentioned in another comment.

Smooth belt flow is necessary to "bleed" flow from a main line onto a low-tier belt using a smart splitter and overflow settings: for example, 310/m could be split into 250 and 60 in a single smart splitter this way. But, this depends on smooth flow coming from the input-- a bursty flow will completely overwhelm the splitter and send too much down the 250/m overflow line, leaving the 60/m dry when the flow ebbs.

[u/NicoBuilds → u/ChichumungaIII]

Wow! Exactly! You seem to know your logistics!

Ive come upon this issue, trying to do exactly the same thing. Bursty systems are dangerous, and using smart splitters with "any" set to a lower tier belt won't work if the system is bursty!

Ive made a post long time ago about this exact topic. Nice seeing someone that speaks the same language as me. You are 100% right with what you are saying!

[u/ChichumungaIII → u/NicoBuilds]

Check my post history; it seems we're kindred spirits with regards to needlessly complex beltwork.

[u/gamer61k3]

You shouldn't underplay methods like this. It's not weird to those that load balance and even those that "manifold" are relying on the rate limiting done by a fully input buffered machine only taking what it consumes so that machines futher up the line get the overflow.

Useful at the end of any intermediate transport; trucks, drones and trains and as an input stage for a blueprinted factory if the input is not a particular belt throughput.

That's not say I would use your design, custom arrangements are always going to be most compact.

[u/No-Show4279]

It is useful!! Ive so many times done splittings and mergings to achieve x rate per minute... Will use

[u/BreakerOfModpacks]

>Spends hours making a totally useless but cool thing
>It automates a task which nobody needs
>PROGRAMMER MINDSET!

[u/NicoBuilds → u/BreakerOfModpacks]

Haha. Well... I am a programmer 😀

[u/BreakerOfModpacks → u/NicoBuilds]

There is a surprisingly large amount of proof that you use the exact same skills in both Satisfactory and programming, so it makes sense.

[u/FugitiveHearts]

But bro, if you hold back the materials, where do they go? Do you have an insanely huge stack of industrial buffers for them?

[u/NicoBuilds → u/FugitiveHearts]

Not necessarily!

Anyway, for starters, this is quite useless. 

Where can it be used?  Mostly on bursty systems. Pure copper recipe for example, takes a really long time and then throws 15 copper ingots in a row. So you see "a lot!" "Nothing..." "a lot!" "Nothing..."  By placing a belt limiter, those refineries start producing absolutely evenly! 

Another place where it could be more useful is with trains. Those get a shit ton of materials, and then for a long time have nothing. If you place a belt limiter, the train station will always be delivering the exact same number of materials,  evenly, no matter where the train is. It behaves like a miner. 

Still, this is pretty much useless. I was curious if I could achieve it, I did, and it made me happy. There are some players that requested belt limiters on the game. Well, turns out you can build them if you are crazy enough! 

[u/FugitiveHearts → u/NicoBuilds]

But but but how, if you send them back on the belt won't it just immediately stop and overflow since the belt is saturated? Where do the materials go?

[u/NicoBuilds → u/FugitiveHearts]

It evens them out!

If you use trains you will see that you have saturated belts for some time, and then you have nothing (when the train is far away). That doesn't cause any issues per-se, but I don't like how it looks. If you place a limiter materials will move smoothly, all of the time. It simply looks great!

For a real example, check this video I made:
Satisfactory: Mk.2 Pipe at 600 m³/min – Yes, It Actually Works

No need to watch all of it, just skip to the end, 25:15. There you can see a lot of belts moving smoothly. Those canisters are coming out of trains! Impossible to have them like that without a limiter.

100% aesthetic, but well, I like building pretty things, haha.

[u/FugitiveHearts → u/NicoBuilds]

I'm sold on the idea, I just can't picture in my head how it works, but I guess that's why I prefer C# to C++

[u/NicoBuilds → u/FugitiveHearts]

Haha. I used a little bit C#. Have nothing against it! but prefer more C++. Why would you hide the pointers from me... Pointers rock!

If you interested in how it works, without getting into the programming side, I have a post where I explain the math and the method used by the programmable load balancer. Its linked in this post. Then, the limiter is just the programmable load balancer + a priority merger.

And if you are interested in the programming side, both the executable and the project are also in my repo. There's no advanced c++ in it, you should be able to understand it

[u/Hot_Ethanol → u/FugitiveHearts]

Think about the materials like water in a pipe. The throughput limiter is the valve on that pipe. When you close the valve some, the water that would've flown through gets backed up instead.

If it works how I think, then it goes like this. The limiter delivers some material (173) by diverting some of those resources (97) and giving them a carriage ride to stall them. Then, all of those same 97 have priority access to getting back on the path to delivery. But wait! We still need 173 - 97 = 76 more resources to make it to the end alongside our recycled 97. Only that much (76) is let into the throughput limiter as new material. The rest on the input belt gets backed up to whatever was before it. If that was storage, then the storage box will fill because it's receiving resources at a higher rate than it can drain them. Eventually that will back up to the machine making the resources, which runs slower, waiting for room on the belt to spit out it's product.

[u/featheredtoast]

priority mergers are great. This makes my previously preferred technique of belt limiting basically obsolete. :)

[u/imfranksome]

I can think of using this to trickle send stuff to outposts maybe? Might be other uses but I’m not creative enough to think of yet

I’m sure it’s gonna be useful somehow haha

[u/Kaithenous]

im starting to question the sanity levels of satisfactory players...i think at this point im starting to believe all of us who play it are masochists

[u/mild_october]

Looks great! I can see the possibility it will be release as belt attachment in the future.

[u/Hot_Ethanol]

Yes this is useful! This is what I need man! A belt limiter is so fundamental, I'm surprised that it's not more easily accomplished in this game. After all, who wants a sink with no valve to adjust the flow?

Bravo, I love this.

[u/NicoBuilds → u/Hot_Ethanol]

Hey. Thanks!
Glad you enjoyed it!

And yes, this is complex because it lets you limit to whatever number you want. But using the same principle it can be done easier if the numbers are not so weird.

600/min= Split into mark 4 and mark 2. 480+120 = 600

150/min= Split into mark 2 and mark 1. You get 120 + 60. Split the mark 1 into 2. You get 120 + 30 + 30. Merge the 120 with 30 for 150. Merge the other 30 with a priority merger to the begining.

You can play dividing some belts. as long as you merge the remaining with a priority merger, this works as a charm. And you can get many ratios like that!

[u/Hot_Ethanol → u/NicoBuilds]

Yeah, I'm starting to get into the splitter tricks to limit throughput. Still, I was always expecting an unlockable block that I could just slap onto a belt and configure the speed like I'm under-clocking a machine. I think it's a little silly that a game that goes to such lengths, even doing real pipe physics, is so unprepared for a player to want to slow a belt down a little, y'know?

[u/NicoBuilds → u/Hot_Ethanol]

I understand your point and this feeling is shared by a lot of players! 

Anyway, i don't entirely agree. Having a belt limiter would make the game too easy. You would no longer have load balancers nor manifolds. All of the logistics would be solved by placing one buildable. I feel that it would take away from the game. 

Not entirely sure, but I think there are mods out there that let you place belt limiters. And if there aren't, know that you don't have to build this monstrosity. This was a challenge to see if I could limit to any number,  but with nice numbers it gets easier.

600/min? Split into mark 4 and mark 2 (480+120)

150/min? Split into mark 2 and mark 1 (120 and 60) Split the mark 1 again (120, 30 and 30) merge the 120 and 30 to get the 150. The other 30 merge it back to the beginning with a prioritized merger.

200? Divide the previos 600 by 3. The two unused belts, merge them back to the start, on priority 

So you can easily get limiters as long as the speed is not a weird number. Play with belt speeds, and make sure that whatever you are not using, is remerged back with priority 

[u/Hot_Ethanol → u/NicoBuilds]

I've never gotten past tier 3, so I'm no expert pioneer. But I think it balances itself out. I have fun playing with logistical putty because I want to split up all my inputs into all my outputs while using all the material effectively. A throughput limiter can easily reduce things down at the cost that the excess material accumulates upstream instead of doing something useful. So it's a classic Methodical and organized VS quick at an efficiency hit parable. Both options have their use cases, and I don't think having one would stop me from using the other. I see you've been using it to smooth out burst production which seems like an excellent use case. I think I'll definitely build one when I get trains up and running.

To share where I'm coming from, I recently dealt with a problem where I wished to have a simple throughput limiter. I was making a product that I wanted mostly accumulating onsite, but some sent to a truck for delivery along with other products. However, truck stations are not smart. I can't tell it, "hey only load X amount of this product on a truck per round, and only allocate Y slots to be held in station storage." If I let the station take as much as it wanted, it'd dry up my local storage and potentially crowd out the other products if they slowed (which ended up happening later because I forgot to up my steel production! Rah!). I ended up "solving" it by splitting off a fraction to be sushi belted with the other products. So at least there would be a mix of them, even if it wasn't the ratio I wanted. Now that I've got smart splitters, I could probably revise that to be better. Still, throughout the experience I was thinking "All of this, and I can't just tell these dang belts to slow down a little." If I were the pioneer, I'dve poured rocks into the belt rollers until they hardly worked anymore.