PMBLS - Poor Man's Belt Logistics System

[pearl vapor]

Working on creating a logistic system with belts and inserters. Saw https://old.reddit.com/r/factorio/comments/g29zfh/krastorio2_miniloaders_postage_stamp_base_with/
A while back and wanted to try doing something similar.

[dry tartan]

This is really interesting, i saw a video about fully vanilla system like that a long time ago, with belt "pathfinding" but have not been able to find it since then

[pearl vapor]

That sounds interesting too!
For my project I was just planning to first resolve the y discrepancy between points and then the x discrepancy. That does require you tile the routes in rectangular grids, but I haven't designed pathfinding before (neither fiddled with circuits) and was afraid implementing something like A* or dijkstra would be too hard

[dry tartan]

That sounds about right, at least at first.
I am also wondering how to implement routing items at junctions, warehouses trivialise this, but in vanilla its not an option. The video i remember had some way of "circuit controlled splitters" (not directly) and i really wanted to find it to know how it was done. If anyone remembers something similar please do tell.
One idea is to have splitter priority output to the side, but fill it with dummy items if the payload needs to go in another direction. With two such splitters you can control whether the items move right, left or straight.

[pearl vapor]

Oh that also sounds doable

[dry tartan]

What was your idea?

[pearl vapor]

I was planning on wagon-ifying the corners and use inserters to control direction

[dry tartan]

That can also work, but may kill throughput

[pearl vapor]

There pathfinding would be updating a memory at each corner that tells each inserter "you can output x items" in each direction

[pearl vapor]

Yeah splitters sounds much more throughput efficient

[pearl vapor]

Hey, umm

The middle decider combinator in this picture outputs a signal if it's -1. And it passes things to the ari at the top.

However, if I pass a one tick signal to the ari, the downstream clocks start going crazy because they have a delay to update the storage of their clock of 1 tick, so

Storage is keeping old signal-1
Old signal is being broadcasted
----- tick ---
Storage is keeping old signal
Broadcast resets
----tick ---
Storage is starting from 1
Broadcast outputs old signal

And so it cycles between the old count and the new count

The solution is to have a 2 tick pulse, which does reset the clocks and their storage right.

To detect a 2 tick pulse, I just added a delay to south of the middle decider (the bottom one), and now signals only pass when both network and 1-delay are both -1.

However, that only outputs a 1 tick pulse which jams the clocks.

How can I turn a 1 tick pulse into a 2 tick pulse?

[dry tartan]

Send a signal through and add a delay combinator that outputs to the same wire

[pearl vapor]

ty

I think moving everything to 2 tick pulses is going to be good for the system

that way on the off-chance 2 signals fire one after another, I can just ignore them instead of dealing with the scramble in the middle

[pearl vapor]

Turns out the matchmaker needs 5 tick signals to work well

Just did the 2 tick checker and used the delay trick 5 times to convert 2 tick pulses to 5 tick ones

[pearl vapor]

Hwaaat?

[pearl vapor]

The matchmaker now has a timeout feature and a dismissal feature. Timeout occurs when a station has been stored, but hasn't found a partner in quite a while (BP is set to 360 ticks but I'm setting it to 3600 rn, IDK where it will land

The dismissal triggers when the provider is not providing a sufficient amount for the requester. In such case, the operation will just be canceled. It can just wait until the provider registers a higher value.

I made it like that to avoid having to update the requester for incoming traffic. That would require setting up a memory in the requester which will also need more coordinate parsing to only apply it to that specific requester and I don't think that is a good idea.

Right now I'm planning to after solving the match, just send a shutup signal to that item chanel so a channel doesn't clutter the network. That should give some time to move the items. After that, a request could (unlikely) be answered twice. But that isn't so troubling, since the routing will just leave the items on the corner inventory and then that station just has a double buffer. It could become a problem if a station continually makes double requests, but I'm planning to have a 10 minute timer where all items in the corner inventory will be transfered to station inventories - that will absolutely mess up the current routes, but every item will be shown as provided in a random station

[dry tartan]

Circuit controlled splitter proof of concept. Ended up bulkier than anticipated

[pearl vapor]

Ooooh looks nice. Though I dunno how big the 4 directions would have to be. But it wouldn't have occurred to me to use those dummy items.

[pearl vapor]

I feel these decision are kinda bad

Hopefully after finishing I can do a retrospective and maybe try other things

[pearl vapor]

Now I'm wondering how to pack a dynamic size list into a signal

[dry tartan]

The size shouldn't be a concern, right turn only is really small, right + left should be smaller than a rail intersection assuming more than 10 minutes is put into making it compact

[dry tartan]

So in its basic form how should that "matchmaking" system work? A station makes requests and if another station can fulfill that request, they are "matched" and the items are sent through, with the items having a destination assigned to them?

[pearl vapor]

I was thinking of doing this:

The grid is all labeled via an unique constant ID placed in the origin

This propagates the ID (Using I for now) through all the grid

Then the matchmaker is connected to radar through red

The red channel is picked up locally at each station

Then, 2 signals have to be sent through the red channel at the same time

An M signal that carries Coordinate information in the following schema

Digits 1-3 X coord, Digits 4-6 Y coord, Digits 7-9 UID of the network

and an Item signal with the requested quantity

The item signal is loaded into a memory cell near the station

Right now using linked chests for the graphic but later it should be easy to change.
The memory cell stores in negative the number of items, uses that to set the filter, and enables the outbound inserter (circled), with the inserter pulsing each item taken (adding it to the network until it becomes 0 because the negative memory runs out)

That takes care of the "station" itself, now the contents are on the belts

I can probably use an extra digit in the M signal to specify if its an outbound/inbound request

And remove an ID digit to make up space for a new direction digit.

Direction digit =0 for outbound/inbound requests.

[dry tartan]

What is ID even for?

[pearl vapor]

When designing the X,Y coords system, I made it so you have a kinda dynamic origin.
So you can theoretically plonk down many non-connected networks.

hmmm

I added ID because I was planning to use radar

Because my green channel is already in use for requests/providing info

But because the number of matchmaker blocks should be much lower than requester/providers, I could try using the red channel with delays for sending the actual orders.

---

The problem basically boils down to -> I'm using the channel (the icon of the signal) as a way of transmitting both location and amount of items. So I can't "post" 2 requests/ 1 request 1 provide / 1 request 1 set route command/ etc. It has to be one at a time

And because of delays on the red wire for the coordinate system, I only have 1 wire.

I could use qualities for some special things, but then that makes it so the system doesn't support quality.

[dry tartan]

How does it handle when multiple stations request the same item?

[pearl vapor]

Right now, it goes as follows -
Each station listens to the green wire and has an internal clock.
A special "silence" value (-1) can be sent through the green wire, in say, the copper plate channel. That -1 is pulled and resets the internal clock to one.
The clock increments its value by 1 each 2 ticks.
A first pass is made -> the clock signal is only passed if its >300 (so that means the gag order to stations lasts 5 seconds).
A second pass is made -> the clock signal is %300, and the signal is only broadcast to the network when %300 = 1 (so each 5 seconds a 2 tick signal is made).
If you have multiple stations that could provide/request the same item, setting it so %300 =1,2,3, etc. means their signals will never conflict (the green wire is global, and so has no delay across the network. So the clocks of the items are correctly synchronized.

As I was coming up with the system, an idea came across my mind that I could just use
4 digits for UID for items (and you would need a dictionary that specificied 1=iron ore, 2=copper ore, etc.), 3 digits for kind of order (I'm requesting/providing/outbound items order/inbound items/silence/etc), 3 digits for X, 3 digits for Y, 3 digits for dynamic data (interpreted within type of order context, say the duration of the silence, etc).
That way, you could just look for a random empty channel on the red wire (say signal A), send your int, and decode all the instruction from just the int. That way you have all channels available and no competition

But alas, circuit network is 32-bit and won't support such a ridiculous amount of digits.

There are some ideas that come to mind to fix it
-using a constant combinator to specify the X,Y coords of the block - this would free up a global red wire network to de tangle the mess a bit. Cons - you have to manually set up this for each block.
-using quality to specify type of order. This allows for some detangling.
-using radar red/green for specific purposes
-actual circuit network channels via a super ugly parallel power pole network
-using circuit channels via mod
etc

Sorry for the ranting, but I came to post about the thing because talking to others about it yields a lot of easy ideas I don't often come up with

[dry tartan]

So, to make sure i understand correctly.
Each station at a unique moment in time sends a signal of an item and metadata. The matchmaker then stores this in a list until it finds a match, at which point it sends a signal (how?) to the provider station to send items and the routing system handles the rest.

[pearl vapor]

Yes. The matchmaker signal is not done yet. I'm designing it right now (though storing a provider/requester and then looking for its opposite presents some challenges, perhaps I should just store a requester and then listen for providers)

[dry tartan]

That makes sense

So i think the routing system can have the metadata sent alongside the items (stored at junctions). So when a signal and the items arrive at a junction, it decodes the position and configures itself to the correct direction, and sends items and signal through

[pearl vapor]

Ohhh I didn't Think that!!! thanks!!!
I was thinking of a matchmaker signal (or a set of pulses of the matchmaker) that sets ALL the points along a route.
I never thought about sending a special junction signal, that tells 1 Junction at X,Y -> hey, route items to N/S/E/W and send a signal to other routes (using your X,Y and relative +X,+Y) until +X,+Y =0. Making each route point not only a signal receiver but a sender makes it work!

That's genius tbh

[dry tartan]

In fact, if a signal is sent through as relative X and Y position between provider and requester, then all a junction needs to do is the following:

Is X > 0 ? send item right and decrement X
Else is X < 0 ? send item left and increment X
Else is Y > 0 ? send item up and decrement Y
Else is Y < 0 ? send item down and increment Y

So the signal always shows the step needed to reach next junction and X and Y are zero when items arrive, which can also be used for error checking

[pearl vapor]

ty for the idea. It's gonna take some work but now it isn't something nebulous thats "I'll just deal with it later"

[pearl vapor]

Ughhh I have been designing these stations for a while. It isn't done yet but it's the begginings of a buffer station

This one has got error correction going on but it takes so manyyy ticks to process instructions

The problem is it captures a (relevant, related to provided/requested items) pulse signal then closes. Then it takes like ~8 (or 9) ticks to begin listening again for that resource.

[pearl vapor]

And this is only the checking the signal part! no actual instructions have been processed!

The problem here is ->
Say a matchmaker A station picked up a provider signal from this buffer station.
It holds onto it's info
Say a matchmaker B picked up another provider signal from this buffer 300 ticks later.

Then a requester signal is broadcasted and is picked by A and B (as it's a global network, there are no delays).
Then matchmaker A and B emit an outbound signal directed at this station. As there is error correction going on, the station will discard the scrambled signal.

I'm afraid whether these problems are going to make the network grind to a halt

But I think I should probably just build a network and stress test it and see what happens after like 10 hrs playtime

For now I will just clock the matchmakers so they send orders at different times.

[pearl vapor]

I don't know if that is good haha

[pearl vapor]

Negative signals can't set filters? @silk spindle

[silk spindle]

need >0

<=0 will not

[pearl vapor]

ty

Guess I'll try something hacky

[silk spindle]

in most cases it's ideal, since you can math your way to the correct filters

[pearl vapor]

I guess not only do you need a positive signal, but that red+green is positive

[pearl vapor]

checkbox would be nice, but yeah

[silk spindle]

most buildings sum red+green as their inputs
arithmetic/decider/radar are the weird ones now

you can use constants 2^31 of everything if you want negative signals to set the filters

and positive to not

[pearl vapor]

I was trying to connect an inserter to a memory cell directly

[silk spindle]

if you want 0 to also set the filter, 2^31-1

[pearl vapor]

And the memory cell would keep the numbers in negative. So when the inserter picked them up, they would be auto subtracted from the cell

[silk spindle]

i have done this before, trying to remember

was ages ago, spacex, probably 2-3 years

[pearl vapor]

I haven't played space exploration yet. So I'll have to see how it plays out

I'm in part designing this system to deal with mod crazy-ness

+mod Circuit-Controlled Routers

[grim rampart]

Circuit-Controlled Routers

Adds a belt-based router network to the game. Make a network of smart routers, connected by belts and by green circuit wires. Request items from the network, or provide items to the network, using I/O terminals connected to chests.

This mod is intended to provide another logistics option for complex mods, such as Seablock, Krastorio 2, Space Exploration, Industrial Revolution 3, or Pyanodon's.

Author

bitwiseshiftleft

Downloads

852

Factorio version

2.0

[pearl vapor]

exists but it feels too much like linked belts to me

effort-sense

[pearl vapor]

It is done!
Outbound/inbound orders are ready

[pearl vapor]

I ended up connecting the inserter to the memory cell (now positive), read contents, then with another color of wire also output the pulse read contents, *-2 (-1 to cancel the just read item and another -1 to actually decrease the count by 1)

[pearl vapor]

It works with many items at once

Though this might as well be UPS death

[silk spindle]

i remember i was doing something cursed but can't remember why
i was writing negative green + positive red to the memory cell so it would be inert, but then let red go through long distance to set other things along with the memory cell

oh, i think i might've had constants on it instead of pulses?

either way - for your inserter +1 to the memory cell, just need to shift from starting around 0 to starting around either minint or maxint

as your baseline values

[pearl vapor]

Hmm, but if I start at:
2147483647 - 9
Then add 10
-2147483647
Then with the same number
-2147483647 + 2147483647 - 9
Will yield 9

Then adding 10:
9+10 and now its broken

[silk spindle]

why are you adding 19?

i'm not sure what you're doing and why

[pearl vapor]

It was starting from max int (top) to count

Setting it to 10

Then doing it 2 times

[pearl vapor]

I think buffer stations are now complete! (This is like the third time I've said that )

Because labels are not shown in the bp bot:
The station listens on the L wires, Speaks on the S wires, and can request with negative numbers using the R combinator.
The "o" chest is for placing "outbound" items that will go to the routers, the "i" chest is for "inbound" that will be taken from the routers

With this new design, the station now has the capacity to request 99,999 items instead of 999!
The "silencer" command now has a variable duration instead of being hardcoded! That will be useful to adjust the length of the silences based on path length.
Also the silencer is now location specific! Muting a copper station will now not mute all copper on the map!

[pearl vapor]

I am sorry if someone happens to graze their eyes at my documentation

Bit this is going to be impossible to understand tomorrow

[pearl vapor]

This took my soul away from my body

It's the matchmaker, and it isn't even finished

I'm kinda beggining to hate this

Anyways, the matchmaker listens through the "l" cables, and has a constant combinator (R,T in the image) that tells it what items it can listen to. First it listens for a requester and saves it on memory, at which point it begins listening for a provider of that item. It has a clock - if it doesn't find it after 30 seconds, it flushes the requester away. If it did found a provider, all data accesses the second stage, where it is evaluated that the provider has enough items for the requester, and that they aren't more than 99 blocks away (manhattan distance).
If it passes those checks, the matchmaker will begin a stream of orders to silence the provider-requester combo for roughly the travel time (I think I might be a few ticks short for yellow belts but plenty for red belts and above - the tick silence can be adjusted with the T combinator), then set the provider and requester inbound-outbound orders.

Now I just need to build up the routing signal

This is going to be more of a pain because routing takes up 3 channels

If two matchmakers live on the same item channel, their streams have to be staggered by 30 ticks, but I didn't implement it :(

Hmm, maybe later. Could be implemented just before firing the valid pairs, below the 4 constant combinators in the middle of the image

[pearl vapor]

Ughhh routing signal is done, all that's left is building the routers

[pearl vapor]

Da router is done

[pearl vapor]

hotfix, added listener combinator

I haven't tested this thing yet

But I'm going to go out on a limb and say

I'm not doing 100% vanilla circuits again

at least not for something that needs more than 3 combinators

[pearl vapor]

Added X,Y part

[pearl vapor]

Fixed after testing

I can't believe it!!!!!!

Do I get to graduate from circuit school ? @silk spindle

[silk spindle]

always more things to learn about circuits

[pearl vapor]

I guessed so 😭 the learning never stops.

Tbh the heat equation version is 10000% better

Mainly because it won't jam with hundreds of requester/providers on the same network

PS: You are linited to 1 fast inserter with stacksize = 1, per direction, for all of the game

Unless you always make requests in multiples of 3. I think

[pearl vapor]

Oh I guess requests with multiples of 10 allow bulk inserters

[pearl vapor]

Oh my god I was thinking that adding a UUID system could make the network more performant (i.e. It would allow to drop signals not intended for a given station, even if tuned to the same channel).

I haven't playtested the thing tho so I absolutely wont optimize until I run into its limits.

Also because you can make independent networks I probably should stop caring about efficiency (i.e make parallel PMBLS's instead of trying to optimize a monolithic one)

[short path]

spitballing an idea here since I had a similar thought earlier -- why not use vehicles for the inventory (+ filtering)? Since IIRC you can move them on belts on multiple tiles, it can make the whole thing multi-directional pretty easily, and the inventory filters in vehicles makes it easier to control what items go where and when. Sure, it's not constant throughput, and you can't exactly read the inventory, but it makes moving stuff a heck of a lot easier. Just a thought

[dry tartan]

There is no way to alter the path they go in

[short path]

Hmmm... nevermind, must've misremembered. Thought they could be influenced by belts on more than one tile, turns out that assumption was wrong

because if they could then yeah, you could alter the path

just tested though and nope! RIP idea.

[silk spindle]

pretty sure stuff is only belt influenced on their pinpoint origin

[pearl vapor]

I think you could achieve that with AAI vehicles. At this point I'm unsure if my combinator bloat is more expensive than a mod's lua 🤣

[dry tartan]

I'm certain that is not the case for aai vehicles in particular, i heard they are very ups expensive

[pearl vapor]

Oh :(

[short path]

🤷 was worth the thought at any rate. Glad to see I'm not the only one thinking up janky stuff like this

Neat idea you have though

[pearl vapor]

I was really planning to use the system with the omnicompression mod, so the inserters really weren't too much of a throughput worry. Though it is neat that you can kinda do the logistics in full vanilla.

[dry tartan]

I realized that all this time the thing i was searching for was in my browser bookmarks
https://www.reddit.com/r/factorio/comments/1bcwwju/making_trains_out_of_belts_the_logistic_belt/#lightbox
The splitter design is very compact, i couldn't manage to make it so small in my tests and chose a much bulkier system.