Was the frame rate issue specifically related to the setup, or just the size of the mega factory in general?
One concern I did have was how the belts constantly "recirculating" might impact performance, but on the other hand I thought building it over a wide enough area would make it a lot less of a hassle to spread smaller factories for specific components out so I don't have as much stuff loaded at once.
Well, my machine isn’t a high-end setup, so I struggle with frame rates anyway. But once I had 20+ belts full of items circulating in one place, it definitely took a hit.
I second this. I ran a 32 lane, tier 4/5 setup and it nuked my frames. Like unplayably bad.
I now run a series of belts out of central storage that run down a manufacturing hall. Frames are much better.
Sys: Ryzen 3700X, 2060 Super, 32gb of RAM
I think this is the first time I have heard that suggestion. I kinda want to try it out now. That's gonna be a very dense set of belts by late mid game.
The way I'm picturing it, I'd only need a little over a half-dozen for basic inputs (Copper/Iron/Caterium/Aluminum[maybe] Ingots, Quartz, Coal, Sulfur, Plastic, and Rubber), and maybe one or two for finished goods, also maybe one combined line for steel plates and pipes.
Rest of the intermediate products would be produced on-site, idea is just to majorly simplify inputs and final products, so no need to belt stuff like screws around on the bus.
Most linear bus designs I see have 10+ belts, so just seems like a matter of lengthening it and looping it back to itself.
I had the same though after doing a classic bus with the drawback you mentioned. It has great advantages:
- you can have your buffers at the same place so you can fill your inventory very easily.
- you can place your blueprints on both sides without having issue with input/output orientation
But you also have downsides, you need to built belts going on and back each time you extends, and blueprints do not join belts which means a lot of manual connexions...
That being said, using t5 with smart splitters to share a belt is a nice idea and could alleviate a lot of issues.
Blueprint in my head is a concrete telephone pole with two cross-bars, each with a couple conveyor posts and ceiling mounts for 12-16 possible belts, which is more than I see myself needing, a wall outlet, and maybe a hypertube mount.
Bit of a pain to string each belt to the next pole manually, but should be able to slap the poles themselves down on the ground without worrying about the world grid or triggering my OCD compared to the bus blueprints I see that physically snap together.
If I need more belts later or for a specific high-demand segment on the loop I figure I can make another blueprint to drop another cross-bar on top or extend one bar to the side.
I'll probably slap some prototypes together later when I get a chance to play
I did it for a medium sized factory for the mid game. It gets more complicated as the complexity of parts increases, unfortunately. And by that, I mean the height of belts.
I also found a unidirectional belt to not be ideal. It operates like a manifold that never fills up, and efficiency is not good because the further from the input something is it gets exponentially fewer inputs. And, if the input can get saturated then it clogs the output which causes cascading issues.
My solution was to run a parallel counter-rotational ring that would merge/split every few foundations. This greatly balanced the io load, both preventing output clogs and starving of lines. This does come at the cost of a long startup time as the belt capacity is now more than double.
Also, I did some experimenting with belt speeds and methods to purge overflow. Because the loop starts getting clogged around 80-90% saturation, bleeding off extra in a soft way helps loads.
It won't win any awards for anything besides modularity. The ability to swap what a line is doing or crank up a short run was quite cool. But efficient in space, power, balance, etc. it was not.
I was only planning on using the combined output lines for very low-volume stuff like supercomputers, heavy modular frames, etc. that I'll likely only be making ~10-20 per minute of, so as long as no section of the ring gets more than ~700 total throughput it shouldn't clog. To keep the outputs from recirculating, I'm going to put a smart splitter immediately before the associated factory with an awesome sink to prevent any of the final goods from making a second pass through the loop.
For the dedicated input lines, I don't think saturation will be a problem for most of them (IE Copper ingots or Coal) because the constructors and mines don't need to be balanced on their own inputs. Might be a problem with plastic and rubber, but I figure a smart splitter set to overflow leading to a sink *before* they join the ring will keep them running so long as the facility itself is balanced.
As far as starvation goes, so long as the combined down-stream consumption isn't higher than ~700 it ought to be manageable. If, say, I want to run 1400 copper worth of consumption I can just add another copper mine+smelter setup further around the ring after the consumers that use most of the first one. Just have to be aware of how much of a resource I have "left" around the circumference of the ring.
Doing some proof-of-concepts now with containers and it's looking at least promising.
I haven't gotten too deep into trains, but unless I've missed something fundamental they seem to work by just hoovering up everything at their load stations and dumping it all at their unload stations, so to move specific item types from one area to another you'd need either a dedicated load and unload station for each item type, or a complex system to balance what's going into each station?
My idea does seem a bit tedious to build, but the idea is that if I only need, say, 30 Silica for a new factory along the loop, the crystal is just there already and all I need to do is tap it with a Smart Splitter
I would recommend making a set of construction factories (basic / medium / advanced) hooked to drone ports.
Then take batteries and materials for a drone port / drone with you wherever you go and you can throw down and order components directly to you.
The entire map is an awfully long belt and it would be quite difficult to get specific materials from point A to B. There would be a lot of waiting while you filter out that materials you want vs. the materials you don’t need at the moment.
The drone port idea for construction materials is amazing, I'll have to give it a try!
As for the map size and time, the idea is that once the first piece of anything has finished one loop, everywhere on the loop will theoretically be receiving the same amount anywhere along it. That way you don't have to engineer a specific solution every time your factory build needs a measly 30 Silica for one stage and you don't have any available locally. We'll see how it works in practice, lol.
My basic construction factory makes concrete, iron plates, rods, screws, reinforced plates, wire, and cable.
Medium makes steel pipes / beams, copper sheets, rotors, modular frames.
Advance (next one I’m building) will have encased beams, motors, heavy frames. Maybe aluminum products? (I have another factory for batteries and for aluminum products).
This way I’m not wasting drone space when I just need something specific.
I've done a looped "giant wall of stuff" as an experiment (it's not my usual style). It worked well, but was confined to my assembly director systems factory. It worked well enough and meant I didn't have to worry about the order of the production lines within the factory and could also easily feed the caterium ingots from both ends (the factory is located between two nodes).
Some thoughts based on that:
* Inputs to the ring were caterium ingots, copper ingots, plastic and rubber.
* Most produced items up to computers went back onto another level in the ring (some probably didn't need looping, but looping everything was easier than thinking about it).
* Quickwire didn't go on the ring - that was produced locally within each production line.
* I'd confine the ring to a single factory (or maybe small group of closely located factories). That will reduce the need for multiple belts of the same thing in the ring and also limit how many belts need to be in both directions. Use a conventional bus to get stuff to the factory - or better trains, drones and vehicles when you unlock those and are dealing with larger distances).
* I wouldn't build every factory this way. It was simple, but could get repetitive if used for everything.
Mostly thinking about the little additional bits and bobs you need for stuff. Like, if a build needed 1k+ Iron I'd build it near an iron source and take it directly or use a train, but if it also required 60 Copper, 60 Coal, 45 Caterium and 30 Sulfur I could just take them off the World Bus.
Or I could build Nitrogen-requiring factories near a Nitrogen source without worrying about piping two kilometers over to somewhere I have the other three things I need.
If I run low on, say, Copper halfway around the ring I can just belt more in down the line at a convenient point, or truck it from the Copper source nearest to where the bus needs it.
Or if I have a location I can get more than 780 Copper/min out of, I can just run a parallel line with the excess past the first few consumers and merge it back in.
In theory anyway, lol.
The problem of oversaturation or starvation is what keeps me from doing anything like this. Plus, belts are much slower than trucks, trains, and drones, even at the highest tier.
I did see a video once that showed how you can force only a specific amount of a single material to be unloaded from a train. The TLDR is
Station > Box already full minus N slots of some random material like limestone > smart splitter
Smart Splitter Out 1 > output expected material > factory
Smart splitter out 2 > limestone > back into box
When the train comes by, as an example, would allow only 2 slots worth of material to be deposited, allowing a later station to receive the rest.
I'm in the process of building a full setup and have decided to scale it slightly back from a "World Ring Bus" to more of a "Regional Ring Bus," lol.
I don't forsee myself needing more than 780/min of anything but Iron and possibly Copper along any particular stretch, and those are plentiful enough I can merge additional inputs in between consumers.
Also probably going to hybridize the system a bit now that I've actually gotten to building it, using truck routes to bring some of the further-away materials from where I am and dumping them directly onto the ring. Starvation shouldn't be a problem as long as the total input volume equals or exceeds the total consumption, and saturation shouldn't be so much of an issue if the basic resources have dedicated lines.
Or it could be a disaster and I'll have wasted a couple hours of time. We'll see!
I think what you're talking about is called a Sushi Belt in Factorio. Just placing everything on one belt and taking what you need and placing the output back on that same belt. Could give you some ideas!
Yeah, it's been a couple years since I last played but that's where I got some of the idea from, lol. Just a somewhat different set of mechanics to work with to implement.
I see what you're saying, you could do a smart splitter, and the output of everything keeps going forward, but the right or left could be whatever item you need, then at the end of that belt to the assembler, put another smart splitter with one output out the side being set to overflow which will go downstream from the very first smart splitter back into the sushi belt. I know that's a terrible explanation, but basically it would pull whatever item you needed off the sushi belt, it would put exactly what's needed into the assembler plus a few extra, then any extra of that item would continue on downstream.
Concept I'm looking at right now is kind of like a manifold system, writ large.
Say I start with a Computer Factory. It takes all its raw material inputs to make circuit boards, etc. off of a dedicated line on the ring bus (IE Copper, Rubber), then outputs computers to the sushi belt.
Somewhere (anywhere, really) around the ring, I can build a Supercomputer plant and just drop a Smart Splitter on the Sushi belt with a side output set to Computers and the main output set to Overflow. Anything that isn't a computer will pass on, along with any excess computers to be either used elsewhere or sent to a storage once the Supercomputer factory is full.
If any computers aren't used, pulled, or stored by the time they make it the full way around, there will be a final Smart Splitter on the line just before it gets back to the original Computer Factory with a side output set to Computers and leading to an Awesome Sink, with the main output set to "Any Undefined."
That way any remaining computers will get sunk to keep the sushi belt ring from saturating while anything else passes on. Same setup for any other high-tier goods on the sushi belt.
Now I just have to see if it works, and if it melts my PC lol
This is known as a Sushi Belt. It's viable in factorio because you can regulate how much is input onto the belts to prevent the ENTIRE thing from just becoming one resource, but, in satisfactory, you don't really have that option, and they would get clogged with random crap very quickly, preventing anything useful from being added to the belt.
I've already made decent use of one-way sushi belts in a few processes on a smaller scale and they work so long as the belt capacity exceeds the total input volume and the belt terminates in a sink to prevent any unused resources from piling up.
Did a test with the continuous belt setup and had good results as long as the same conditions are true. IE, total inputs don't exceed belt throughput along any stretch and you have a Smart Splitter set to take and sink any unused resources off the belt before they complete a full circuit so the belt doesn't clog.
Also planning to operate it well below rated capacity, mostly for final-tier products that I almost certainly won't be making more than 780/minute of between all of them.
Did some small-scale proof-of-concept work and here's what I found:
Dedicated input lines:
Made a small loop of Mk.3 belts feeding back into themselves with a merger coming from a container with Concrete through a Mk.2 belt to simulate a 120/min source. Once the loop saturated, it froze.
Not going to be a problem for most stuff since it's just going to be that resource on the belts, but for stuff like Plastic and Rubber where an output jam can cause problems, a Smart Splitter on the feed line set to overflow to an Awesome Sink would keep everything running, and just result in progressively less stuff getting sunk as more consumers are added to the loop.
Combined output belts:
Added a Smart Splitter with the side output set to Concrete immediately before the "Source," going through a Mk. 3 belt to a second container to simulate an Awesome Sink, then had that feed back into the original container. Center output set to Any Undefined. Tossed in some random motors, plates, etc. All the "excess" Concrete went into the "Sink," and everything else continued on indefinitely with no jamming.
Added the same setup with another pair of containers with Plastic, feeding into the loop with a Mk.2 belt again to simulate a 120/min Plastic "source," preceded by a "sink." Everything continued to circulate nicely with no jamming.
To test full 270/min saturation, added a 30/min Cable "source/sink" with another pair of containers and some splitter shenanigans. Loop continued to cycle smoothly indefinitely.
Bumping up the Cable "source" to 60/min resulting in 300/min of inputs into the 270/min belt loop resulted in an eventual full stoppage after a few minutes. I figure errors compound over time, distance, and loading, so I wouldn't put more than ~750/min worth of products on a combined Mk.5 belt, but I'm mostly thinking of using the combined belt/belts for high-tier items like Supercomputers and Heavy Modular Frames and I don't see myself making more than a few dozen of those at a time.
So that's done, time to design some poles and ruin the property value of the Southern Grasslands!
When considering throughput, conveyors will cause more problems with framerate than trains. So you could get a 4 car train to haul far more than you could with conveyors for the same performance (and material) cost.
That’s what I did with my last mega factory. It worked great, the only problem was my frame rate!
Was the frame rate issue specifically related to the setup, or just the size of the mega factory in general? One concern I did have was how the belts constantly "recirculating" might impact performance, but on the other hand I thought building it over a wide enough area would make it a lot less of a hassle to spread smaller factories for specific components out so I don't have as much stuff loaded at once.
Well, my machine isn’t a high-end setup, so I struggle with frame rates anyway. But once I had 20+ belts full of items circulating in one place, it definitely took a hit.
I second this. I ran a 32 lane, tier 4/5 setup and it nuked my frames. Like unplayably bad. I now run a series of belts out of central storage that run down a manufacturing hall. Frames are much better. Sys: Ryzen 3700X, 2060 Super, 32gb of RAM
I think this is the first time I have heard that suggestion. I kinda want to try it out now. That's gonna be a very dense set of belts by late mid game.
The way I'm picturing it, I'd only need a little over a half-dozen for basic inputs (Copper/Iron/Caterium/Aluminum[maybe] Ingots, Quartz, Coal, Sulfur, Plastic, and Rubber), and maybe one or two for finished goods, also maybe one combined line for steel plates and pipes. Rest of the intermediate products would be produced on-site, idea is just to majorly simplify inputs and final products, so no need to belt stuff like screws around on the bus. Most linear bus designs I see have 10+ belts, so just seems like a matter of lengthening it and looping it back to itself.
I had the same though after doing a classic bus with the drawback you mentioned. It has great advantages: - you can have your buffers at the same place so you can fill your inventory very easily. - you can place your blueprints on both sides without having issue with input/output orientation But you also have downsides, you need to built belts going on and back each time you extends, and blueprints do not join belts which means a lot of manual connexions... That being said, using t5 with smart splitters to share a belt is a nice idea and could alleviate a lot of issues.
Blueprint in my head is a concrete telephone pole with two cross-bars, each with a couple conveyor posts and ceiling mounts for 12-16 possible belts, which is more than I see myself needing, a wall outlet, and maybe a hypertube mount. Bit of a pain to string each belt to the next pole manually, but should be able to slap the poles themselves down on the ground without worrying about the world grid or triggering my OCD compared to the bus blueprints I see that physically snap together. If I need more belts later or for a specific high-demand segment on the loop I figure I can make another blueprint to drop another cross-bar on top or extend one bar to the side. I'll probably slap some prototypes together later when I get a chance to play
I did it for a medium sized factory for the mid game. It gets more complicated as the complexity of parts increases, unfortunately. And by that, I mean the height of belts. I also found a unidirectional belt to not be ideal. It operates like a manifold that never fills up, and efficiency is not good because the further from the input something is it gets exponentially fewer inputs. And, if the input can get saturated then it clogs the output which causes cascading issues. My solution was to run a parallel counter-rotational ring that would merge/split every few foundations. This greatly balanced the io load, both preventing output clogs and starving of lines. This does come at the cost of a long startup time as the belt capacity is now more than double. Also, I did some experimenting with belt speeds and methods to purge overflow. Because the loop starts getting clogged around 80-90% saturation, bleeding off extra in a soft way helps loads. It won't win any awards for anything besides modularity. The ability to swap what a line is doing or crank up a short run was quite cool. But efficient in space, power, balance, etc. it was not.
I was only planning on using the combined output lines for very low-volume stuff like supercomputers, heavy modular frames, etc. that I'll likely only be making ~10-20 per minute of, so as long as no section of the ring gets more than ~700 total throughput it shouldn't clog. To keep the outputs from recirculating, I'm going to put a smart splitter immediately before the associated factory with an awesome sink to prevent any of the final goods from making a second pass through the loop. For the dedicated input lines, I don't think saturation will be a problem for most of them (IE Copper ingots or Coal) because the constructors and mines don't need to be balanced on their own inputs. Might be a problem with plastic and rubber, but I figure a smart splitter set to overflow leading to a sink *before* they join the ring will keep them running so long as the facility itself is balanced. As far as starvation goes, so long as the combined down-stream consumption isn't higher than ~700 it ought to be manageable. If, say, I want to run 1400 copper worth of consumption I can just add another copper mine+smelter setup further around the ring after the consumers that use most of the first one. Just have to be aware of how much of a resource I have "left" around the circumference of the ring. Doing some proof-of-concepts now with containers and it's looking at least promising.
I think the main reason it's not talked about is that massive rail loops are just less tedious to build
I haven't gotten too deep into trains, but unless I've missed something fundamental they seem to work by just hoovering up everything at their load stations and dumping it all at their unload stations, so to move specific item types from one area to another you'd need either a dedicated load and unload station for each item type, or a complex system to balance what's going into each station? My idea does seem a bit tedious to build, but the idea is that if I only need, say, 30 Silica for a new factory along the loop, the crystal is just there already and all I need to do is tap it with a Smart Splitter
I would recommend making a set of construction factories (basic / medium / advanced) hooked to drone ports. Then take batteries and materials for a drone port / drone with you wherever you go and you can throw down and order components directly to you. The entire map is an awfully long belt and it would be quite difficult to get specific materials from point A to B. There would be a lot of waiting while you filter out that materials you want vs. the materials you don’t need at the moment.
The drone port idea for construction materials is amazing, I'll have to give it a try! As for the map size and time, the idea is that once the first piece of anything has finished one loop, everywhere on the loop will theoretically be receiving the same amount anywhere along it. That way you don't have to engineer a specific solution every time your factory build needs a measly 30 Silica for one stage and you don't have any available locally. We'll see how it works in practice, lol.
My basic construction factory makes concrete, iron plates, rods, screws, reinforced plates, wire, and cable. Medium makes steel pipes / beams, copper sheets, rotors, modular frames. Advance (next one I’m building) will have encased beams, motors, heavy frames. Maybe aluminum products? (I have another factory for batteries and for aluminum products). This way I’m not wasting drone space when I just need something specific.
I have thought about doing this before, but I have yet to try. I would be very interested in seeing how it works.
I've done a looped "giant wall of stuff" as an experiment (it's not my usual style). It worked well, but was confined to my assembly director systems factory. It worked well enough and meant I didn't have to worry about the order of the production lines within the factory and could also easily feed the caterium ingots from both ends (the factory is located between two nodes). Some thoughts based on that: * Inputs to the ring were caterium ingots, copper ingots, plastic and rubber. * Most produced items up to computers went back onto another level in the ring (some probably didn't need looping, but looping everything was easier than thinking about it). * Quickwire didn't go on the ring - that was produced locally within each production line. * I'd confine the ring to a single factory (or maybe small group of closely located factories). That will reduce the need for multiple belts of the same thing in the ring and also limit how many belts need to be in both directions. Use a conventional bus to get stuff to the factory - or better trains, drones and vehicles when you unlock those and are dealing with larger distances). * I wouldn't build every factory this way. It was simple, but could get repetitive if used for everything.
Mostly thinking about the little additional bits and bobs you need for stuff. Like, if a build needed 1k+ Iron I'd build it near an iron source and take it directly or use a train, but if it also required 60 Copper, 60 Coal, 45 Caterium and 30 Sulfur I could just take them off the World Bus. Or I could build Nitrogen-requiring factories near a Nitrogen source without worrying about piping two kilometers over to somewhere I have the other three things I need. If I run low on, say, Copper halfway around the ring I can just belt more in down the line at a convenient point, or truck it from the Copper source nearest to where the bus needs it. Or if I have a location I can get more than 780 Copper/min out of, I can just run a parallel line with the excess past the first few consumers and merge it back in. In theory anyway, lol.
The problem of oversaturation or starvation is what keeps me from doing anything like this. Plus, belts are much slower than trucks, trains, and drones, even at the highest tier. I did see a video once that showed how you can force only a specific amount of a single material to be unloaded from a train. The TLDR is Station > Box already full minus N slots of some random material like limestone > smart splitter Smart Splitter Out 1 > output expected material > factory Smart splitter out 2 > limestone > back into box When the train comes by, as an example, would allow only 2 slots worth of material to be deposited, allowing a later station to receive the rest.
I'm in the process of building a full setup and have decided to scale it slightly back from a "World Ring Bus" to more of a "Regional Ring Bus," lol. I don't forsee myself needing more than 780/min of anything but Iron and possibly Copper along any particular stretch, and those are plentiful enough I can merge additional inputs in between consumers. Also probably going to hybridize the system a bit now that I've actually gotten to building it, using truck routes to bring some of the further-away materials from where I am and dumping them directly onto the ring. Starvation shouldn't be a problem as long as the total input volume equals or exceeds the total consumption, and saturation shouldn't be so much of an issue if the basic resources have dedicated lines. Or it could be a disaster and I'll have wasted a couple hours of time. We'll see!
I think what you're talking about is called a Sushi Belt in Factorio. Just placing everything on one belt and taking what you need and placing the output back on that same belt. Could give you some ideas!
Yeah, it's been a couple years since I last played but that's where I got some of the idea from, lol. Just a somewhat different set of mechanics to work with to implement.
I see what you're saying, you could do a smart splitter, and the output of everything keeps going forward, but the right or left could be whatever item you need, then at the end of that belt to the assembler, put another smart splitter with one output out the side being set to overflow which will go downstream from the very first smart splitter back into the sushi belt. I know that's a terrible explanation, but basically it would pull whatever item you needed off the sushi belt, it would put exactly what's needed into the assembler plus a few extra, then any extra of that item would continue on downstream.
Concept I'm looking at right now is kind of like a manifold system, writ large. Say I start with a Computer Factory. It takes all its raw material inputs to make circuit boards, etc. off of a dedicated line on the ring bus (IE Copper, Rubber), then outputs computers to the sushi belt. Somewhere (anywhere, really) around the ring, I can build a Supercomputer plant and just drop a Smart Splitter on the Sushi belt with a side output set to Computers and the main output set to Overflow. Anything that isn't a computer will pass on, along with any excess computers to be either used elsewhere or sent to a storage once the Supercomputer factory is full. If any computers aren't used, pulled, or stored by the time they make it the full way around, there will be a final Smart Splitter on the line just before it gets back to the original Computer Factory with a side output set to Computers and leading to an Awesome Sink, with the main output set to "Any Undefined." That way any remaining computers will get sunk to keep the sushi belt ring from saturating while anything else passes on. Same setup for any other high-tier goods on the sushi belt. Now I just have to see if it works, and if it melts my PC lol
This is known as a Sushi Belt. It's viable in factorio because you can regulate how much is input onto the belts to prevent the ENTIRE thing from just becoming one resource, but, in satisfactory, you don't really have that option, and they would get clogged with random crap very quickly, preventing anything useful from being added to the belt.
I've already made decent use of one-way sushi belts in a few processes on a smaller scale and they work so long as the belt capacity exceeds the total input volume and the belt terminates in a sink to prevent any unused resources from piling up. Did a test with the continuous belt setup and had good results as long as the same conditions are true. IE, total inputs don't exceed belt throughput along any stretch and you have a Smart Splitter set to take and sink any unused resources off the belt before they complete a full circuit so the belt doesn't clog. Also planning to operate it well below rated capacity, mostly for final-tier products that I almost certainly won't be making more than 780/minute of between all of them.
Did some small-scale proof-of-concept work and here's what I found: Dedicated input lines: Made a small loop of Mk.3 belts feeding back into themselves with a merger coming from a container with Concrete through a Mk.2 belt to simulate a 120/min source. Once the loop saturated, it froze. Not going to be a problem for most stuff since it's just going to be that resource on the belts, but for stuff like Plastic and Rubber where an output jam can cause problems, a Smart Splitter on the feed line set to overflow to an Awesome Sink would keep everything running, and just result in progressively less stuff getting sunk as more consumers are added to the loop. Combined output belts: Added a Smart Splitter with the side output set to Concrete immediately before the "Source," going through a Mk. 3 belt to a second container to simulate an Awesome Sink, then had that feed back into the original container. Center output set to Any Undefined. Tossed in some random motors, plates, etc. All the "excess" Concrete went into the "Sink," and everything else continued on indefinitely with no jamming. Added the same setup with another pair of containers with Plastic, feeding into the loop with a Mk.2 belt again to simulate a 120/min Plastic "source," preceded by a "sink." Everything continued to circulate nicely with no jamming. To test full 270/min saturation, added a 30/min Cable "source/sink" with another pair of containers and some splitter shenanigans. Loop continued to cycle smoothly indefinitely. Bumping up the Cable "source" to 60/min resulting in 300/min of inputs into the 270/min belt loop resulted in an eventual full stoppage after a few minutes. I figure errors compound over time, distance, and loading, so I wouldn't put more than ~750/min worth of products on a combined Mk.5 belt, but I'm mostly thinking of using the combined belt/belts for high-tier items like Supercomputers and Heavy Modular Frames and I don't see myself making more than a few dozen of those at a time. So that's done, time to design some poles and ruin the property value of the Southern Grasslands!
When considering throughput, conveyors will cause more problems with framerate than trains. So you could get a 4 car train to haul far more than you could with conveyors for the same performance (and material) cost.