Plastanium Conveyors and Interactions with Routers, Junctions, etc

[Draco18s]

Describe what you would like changed, and why.

As it is right now, when a bundle of items reaches a junction (router, etc) it is disassembled into its constituent items before being pushed through. This makes routers virtually useless with plastanium conveyors because it splits up the stack of 10 into 2 stacks of 5 (which can't be moved) until another packet comes along. This results in a nightmare when two different item types are traveling along the same plastanium conveyor (either accidentally, due to a leak, or on purpose due to space restrictions).

Fixing these sorts of problems often requires repeated deletions and rebuilding until the junction/router is empty before allowing the plastanium conveyors to begin feeding the input side again in order to remove all of the non-full stacks from the system. (In addition to cleaning up the input line).

It also introduces a speed bump, lowering the throughput of the plastanium belt down from 40 items/second to the speed of the junction (10 items/second) for no other reason than "it had to go over something."

Describe the changes you want to propose. Include possible alternatives.

Note that this applies to all sorts of non-conveyor blocks that move items, not just the three I've named explicitly. Overflow gates, sorters, etc. Either:

(a) allow the packaged item to get junctioned/routered across to an accepting plastanium belt as a single unit. Acknowledging that weirdness returns when the router is adjacent to both plastanium and non-plastanium destinations, however what I'd suggest here is that if the destination chosen is plastanium, dump the entire packet on it in one operation. If it is not plastanium, then break the packet up and distribute the individual items across all valid non-plastanium targets until the packet is depleted (then process the next one, starting fresh, obviously choosing a plastanium output if the previous one was not and vice versa) in order to avoid jamming.

(b) plastanium versions of routers that handle that function as above (operating on bundled packets), but which cannot accept input from, nor output to, non-plastanium conveyors. For a plastanium junctions, a pair of opposites being non-plastanium, it should function as a normal junction (optional: improved buffer capacity). The improvement would be that for a plastanium input-output pair, it will handle an entire packet all at once with no drop in throughput. Plastanium bridges would operate much like routers, only accepting input and output to/from plastanium conveyors (I don't even care about length of the bridge, but it would be nice if it was about as long as a phase conveyor).

[itcannotbe]

The fix is simple. Don't make the plast conveyor go through something.

[LixieWulf]

plastanium bridges would fix this issue

[Quezler]

just design your factory better, this was an intentional design decision 👀

[Quezler]

hi, creator of the plastanium conveyor here:

they are designed to carry items directly from where they are made to where they are needed, or in other words: blocks that have an inventory gui (like the core, a vault, or another factory)

in case that you need to interact with the flow like a normal conveyor by using bridges/junctions/routers/etc you should have just used those instead (plastanium conveyor are a "one block solution", having other blocks added "just" for this block seems really bloated)

coincidentally, they were not designed to be better than conveyors in every single way, i wanted to keep titanium and armoured ones relevant as well:

• need health? use armored
• need throughput? use plastanium
• need interaction? use normal

so to wrap things up: yes your old designs won't work, this is not a straight upgrade like titanium is for a normal conveyor so you can't expect sorting & routing to act the same way, its an entirely new way you need to think if you want to put this new tech to some good use, but keep in mind that you can always use the other 3 conveyors just fine, no one is forcing you to use them :)

(one thing that may be worth considering is routing the items automatically if there is nothing in front and 2 plastanium conveyors to the side where they just take turns, this would make a lot of sense but it also won't require an entirely new block, i might make a draft for this in october, should be perfectly backwards compatible since the required arrangement described above doesn't exist in the wild)

🥔

[LixieWulf]

a correction i can make here is bridge stacking is indeed better for throughput, and with overdrive enabled in v6 they will thwart plast conveyors. by adding the ability of being able to be crossed efficiently you give your favourite conveyor an advantage over the one you hate the most

[Quezler]

i was talking about throughput in the conveyor category ^

[rabit232]

hi there I been testing the plast conveyor in many way's the good thing that it hold most ore then all conveyors and what I've find out is that it really slow just the time it take to it get filled and it transfer ore stack on the conveyor it take time simular to titanium conveyor as show in the gif https://cdn.discordapp.com/attachments/689230537575104523/760044920706039818/Screen_Recording_20200921-132944_Mindustry_BE_1.gif to see it copy the link and paste it in discord or use browser

I thing it a bug or the plast conveyor is not that great as the community was thinking

btw in the contraption is 8.7k ore i empty it

[Quezler]

that it takes time to load is irrelevant, only throughout matters in the long run ^

[Sp3rw3r]

Wrong use of plast conv: do not load it from only one side. You can load the starting point from three sides. That way it fills a stack to 10 very fast. It is also possible to side load a plast belt from other plast conveyors. By creating several stacks in parallel it is easy to fill the plast belt to capacity. The creator of the plastinium conveyor made it intentionally so it does transfer full stacks when interacting with things like routers, bridges and sorters.

[Colonizor48]

I think plast conveyors need a slight buff. As doing some testing phase conveyors actualy have a better throughput in most(but not all) circumstanses.

[Kyllingene]

Phase conveyors are much more expensive to make and maintain. They need power and phase fabric, whereas these are more like better titanium (although they are not, as explained above).

[InvalidError404]

Just came back to the game to try 6.0, plastanium belts seem a bit broken to me: they make it relatively convenient to merge multiple different items in one convenient compact item highway (simply put a 'dock' for each item type) but getting items off the belt without bogging it down (ex.: using sorters to select specific resources off the belt) is seemingly impossible: it works some of the time when the belt has a clean start with evenly spaced stuff that goes either way through the sorter but then bogs down to half-speed at the slightest hiccup.

Since it takes four almost fully loaded titanium belts to saturate plastanium belts and plastanium belt ends can only split three ways, there really needs to be a way to reliably pick stuff off of them without slowing them down.

[Quezler]

use some unloaders ^

[InvalidError404]

use some unloaders ^

While unloaders do work around the "pick stuff off without slowing the belt down" issue, they only have time to pick 2-3 items out of the blob while it is passing by so you may need two or more consecutive unloaders just to get one normal belt worth of stuff out depending on how common the item is on the belt. Would be nice if unloaders could transfer whole blobs between plastanium belts at least when the destination plastanium belt tile is clear.

I thought I could do U shapes with plastanium belts around unloaders to give unloaders three chances to unload from a blob but that just ends up stalling the plastanium belts whenever a partial blob of something else passes by, as if the belt was waiting for the unloader to refill the blob but the unloader is unable to put stuff back into it because it is a different material.

[itcannotbe]

Use a vault and some unloaders.

Also moving a whole roomba to a separate path is too OP.

[InvalidError404]

Having to feed plast belts to a vault to get stuff out at full rate and then having to put everything back together to send the remainder along is similar to what I did back in mainline 5.x with mass drivers. Not really seeing the "OPness" of plastanium with all of the extra gymnastics required to get anything beyond the most basic stuff done with those on top of the gymnastics I was already used to from abusing mass drivers back then.

I tried looking for practical examples of plastanium conveyor uses for a few minutes, didn't find anything beyond basic how-tos and complaints about them not working as expected, seems like plastanium conveyors simply cause more issues than they solve in their current form. I tried using plast belts a few times on my last two campaign maps and the only two times I ended up with something actually useful and functional was for garbage/overflow collection of conveniently pre-sorted factory lines and one spot where I had room for only one conveyor but needed to shove about three total lanes worth of five different things through, the latter only making sense because I hadn't re-unlocked mass drivers yet.

If you want to talk about something "OP", mass drivers + CPU-controlled unloaders to prevent overflows (configure overflow unloaders to unload anything that is above 50% of max capacity or not supposed to be in there, disable them otherwise) allow me to implement a more effective version of what I used to do in mainline 5.x using less than a quarter of the space. Before ulog (and my Threshold Unloader fork in 5.x), I used to dump mass drivers into vaults for extra unloader space, need 2-4 belts for each resource to keep up with the uneven arrival rate between output vaults, have to manage overflows on those outputs and have a launcher to buffer overflow bursts as a backup plan. With TU or its ulog equivalent in 6.0 which can be fine-tuned on a resource-by-resource basis, I can do all of the above (except launch surplus) using only the drivers' own internal storage for buffering. Now that is powerful. Greatly simplifies how I use drivers to get stuff in/out of distant production areas without compromises. (Well, no compromises besides the power and thorium costs.)

The main argument for making plastanium conveyors suck is to keep titanium conveyors relevant, which kind of misses the tree for the forest when strategically placed and managed mass drivers can outright eliminate a metric crap-ton of conveyors once you can spare the power. It is ok for new stuff and changes to existing stuff to make some things simpler, easier, more convenient and more efficient to the extent that intuitively expected behavior is generally compatible with the gimmick.

[LixieWulf]

i was talking about throughput in the conveyor category ^

. bridge CONVEYOR

[LixieWulf]

to ram this point home, StackConveyor != Conveyor

[348joey]

hi, creator of the plastanium conveyor here:

they are designed to carry items directly from where they are made to where they are needed, or in other words: blocks that have an inventory gui (like the core, a vault, or another factory)

in case that you need to interact with the flow like a normal conveyor by using bridges/junctions/routers/etc you should have just used those instead (plastanium conveyor are a "one block solution", having other blocks added "just" for this block seems really bloated)

coincidentally, they were not designed to be better than conveyors in every single way, i wanted to keep titanium and armoured ones relevant as well:

• need health? use armored
• need throughput? use plastanium
• need interaction? use normal

so to wrap things up: yes your old designs won't work, this is not a straight upgrade like titanium is for a normal conveyor so you can't expect sorting & routing to act the same way, its an entirely new way you need to think if you want to put this new tech to some good use, but keep in mind that you can always use the other 3 conveyors just fine, no one is forcing you to use them :)

(one thing that may be worth considering is routing the items automatically if there is nothing in front and 2 plastanium conveyors to the side where they just take turns, this would make a lot of sense but it also won't require an entirely new block, i might make a draft for this in october, should be perfectly backwards compatible since the required arrangement described above doesn't exist in the wild)

🥔

It's just really hard to get one plastanium belt to get around another. I don't think routers for them should be used, but in a schematic that uses plastanium belts, it's really tedious to have the items separated out of one belt just to cross another plastanium belt and remerge. Alloy smelters especially need a lot of items quickly, and you only have so much room around the smelters to work with. I don't need them sorted, mixed with other items, routed to other lines, or anything like that; I just want to move the items in one plastanium belt to the other side of another plastanium belt without going all the way around its source. Plastanium belts lose a lot of their usefulness when you need things from the north to go south at the same time you need things from the east go to west. As it is, I'm often very limited on when I can use more than one on a map, and I need to push everything else aside for it.

[itcannotbe]

Plan your routes in advance.

[InvalidError404]

It's just really hard to get one plastanium belt to get around another.

Inconvenient, sure. Hard, no.

If you have a fully loaded plastanium belt consisting of up to four full belts of one resource each: plast belt -> container -> 4x unsorted unloaders -> 4x bridges -> container -> 4x sorted unloaders -> re-pack plast belt

It would be nice if there was a 3x3 "plastanium warehouse" that could take care of stockpiling up to 30 of each resource from any number of inputs and dump neat stacks of 10 on neighboring plastanium belt starts whenever the warehouse has more than 20 of something in stock and could also output to other belts via unloaders. Then you could just dump the raw mixed belts into the warehouse and let it take care of the rest. Wouldn't quite "solve" the plastanium crossing problem but it would at least significantly simplify the most tedious part of it along with many other things.

Unfortunately, devs have decided that using plast belts much beyond basic "bring stuff from source to vault" should be painful by design, so your best option at least for now is to avoid needing to do so by planning accordingly. Worst case, dump the plast belt into a mass driver and drop the receiver wherever there is enough space to re-assemble the belt.

[chadmawhinney]

If one of the plast belts has only one type of material, then two phase conveyors will handle it and it doesn't take too much space. You split the plast belt with only one mat type into 2, use two phase conv. to get over the line in the way, and recombine on the other side. It looks somewhat inefficient space-wise, but it takes no more space than 4 titanium belts would. Does take power though, and if both plast belts have multiple content types it won't work.

That said, I would like to see at least a bridge for that belt type. There's no in-game reason why other types of belts can cross each other in the z-axis, but not plastanium belts. It's a limitation that doesn't physically make sense if you were actually there mining and shipping materials.

...And to all those saying vault + unloaders, let's not forget that unloaders have an unloading speed a little short of a full titanium belt. Something like 8 or 9 items/sec. So using just 4 of those will eventually clog up when the vault gets full. You'll need possibly up to 8 unloaders if the incoming belt has 10 items/sec of 4 different mats. That solution sucks for full throughput.

[github-actions[bot]]

This suggestion is now stale, and will be automatically closed.