It would be nice to have some diagnostic tools for the network. For example, traffic jams often occur if for some reason the terminal cannot push resources into the container if it is full or its slots are blocked.

It would also be nice to correct the picture with the arrows on the router, so as not to remember the direction of each conveyor every time. Maybe I'm the only one so stupid, but I keep getting it wrong :)

And of course, you need a route tracing tool... say, from a terminal with a selection of a resource, so that you can see where it will go or where it will go.

Thanks for the suggestions.

For diagnostics, what are you thinking in particular? A traffic jam coming into a terminal can only occur if it the container is full / blocked, so there's no much to diagnose there. I guess I could set a map alert of some sort? There's probably a way for the entire system to deadlock though, in the same way that a loop being fed by splitters can deadlock. I'm not sure what information to show about this though.

I'm pretty new to modding, so I don't know how to make a route tracing tool.

I made a note to change to double arrows on the routers (indicating direction of the conveyors), next time I update the graphics. I suppose another possibility would be for the router to detect which way you connected it, and update the underlying hardware, but that would be trickier to program. In principle it could even allow you to have both lanes in one direction, though it would require considerable care to make sure that this cannot cause traffic jams. So I probably will just go with making double arrows.

Thanks for the suggestions.

For diagnostics, what are you thinking in particular? A traffic jam coming into a terminal can only occur if it the container is full / blocked, so there's no much to diagnose there. I guess I could set a map alert of some sort? There's probably a way for the entire system to deadlock though, in the same way that a loop being fed by splitters can deadlock. I'm not sure what information to show about this though.

I'm not very sure, sometimes jams arise that can be "treated" by simply removing the router, then putting it back in place and restoring the "green" wires. And this is not always due to overflowing chests.

I'm pretty new to modding, so I don't know how to make a route tracing tool.

I made a note to change to double arrows on the routers (indicating direction of the conveyors), next time I update the graphics. I suppose another possibility would be for the router to detect which way you connected it, and update the underlying hardware, but that would be trickier to program. In principle it could even allow you to have both lanes in one direction, though it would require considerable care to make sure that this cannot cause traffic jams. So I probably will just go with making double arrows.

If routers and terminals could determine their connection solely through conveyor belts, without the need to connect them with wires, this would certainly make life much easier. :)

Double arrows will be enough, for now, I think :)

For diagnostics, what are you thinking in particular? A traffic jam coming into a terminal can only occur if it the container is full / blocked, so there's no much to diagnose there. I guess I could set a map alert of some sort? There's probably a way for the entire system to deadlock though, in the same way that a loop being fed by splitters can deadlock. I'm not sure what information to show about this though.

I'm not very sure, sometimes jams arise that can be "treated" by simply removing the router, then putting it back in place and restoring the "green" wires. And this is not always due to overflowing chests.

OK, I think I know the cause. Basically the terminals send new items based on the demand. It's supposed to be conservative, but sometimes they send too many because of latency. When this happens, demand for a commodity might drop to zero within the network. And the routing is based entirely on current demand. I've been thinking of whether there's a way to "remember" the last way that something was routed, but sometimes the routing changes paths, especially as demand drops toward zero, so remembering the last route might end up with circular routes.

If this is the cause, it can be avoided by setting a large enough value for the "default" signal (it's one of the new signals added by the mod) on one of the I/O terminals to act as a buffer chest. Then any leftovers in the network will be routed there. Then you can set a low value (1) for the send threshold on that terminal, so that it will be eager to send things back out to the network when they're only slightly in demand.

This isn't a very elegant solution, but I don't currently have a better one, so ideas are welcome. Anyway, let me know if that works in your base.

If routers and terminals could determine their connection solely through conveyor belts, without the need to connect them with wires, this would certainly make life much easier. :)

Yeah, I'm thinking of eventually making them detect this. I would probably want some way to interface to the circuit network, as the system does now, so that it could propagate demand across surfaces for eg Space Exploration mod, but that's doable. The problem is how to efficiently detect whether two routers are connected without tracing belts all the time, which would cost UPS. It would only be a UPS hit while building long belts though I guess, and it might improve UPS during normal operation, so maybe it'd be worthwhile.

Factorio 2 is going to add the ability to read a whole belt, and maybe in doing this they will also add a good way in Lua to see where that belt goes.

Regarding diagnostics, what exactly are you thinking about? A congestion at the entrance to the terminal can only occur if the container is overfilled/blocked, so there is not much to diagnose there. I guess I could set some kind of map alert? However, there is likely a way to deadlock the entire system, just as a loop fed by splitters can become deadlocked. I'm not sure what information to show about this.

I'm not too sure, sometimes there are jams that can be "cured" by simply removing the router, then putting it back in place and restoring the "green" wires. And this does not always happen because the chests are full.

Okay, I think I know the reason. Basically, terminals send new goods depending on demand. This is supposed to be conservative, but sometimes they send too much due to the delay. When this happens, demand for the product within the network may drop to zero. And routing is entirely based on current demand. I was wondering if there was a way to "remember" the last way something was routed, but sometimes routing changes paths, especially when demand drops to zero, so remembering the last route can result in circular routes.

Maybe it’s possible to remember the “sender’s” terminal, and in case of overflow, return the resources back?

If this is the cause, it can be avoided by setting a large enough value for the "default" signal (this is one of the new signals added by the mod) on one of the I/O terminals, which will act as a buffer chest. Then any leftovers on the network will be redirected there. You can then set the send threshold on this terminal to a low value (1) so that it tends to send data back to the network when it is only marginally in demand.

By the way, how does default priority work?
Those. I have a "sender" person with a resource and 2 "default" ones, with priorities 10 and 100, both having some amount of the same resource. When a resource is requested, who will send it?

This is not a very elegant solution, but I don't have a better solution yet, so ideas are welcome. Anyway, let me know if this works for you.

Here is a BP with a stuck one

0eNrtW11uqzgU3srIzyHCBhuIZhfzOLqKnOA21gUTGVO1qrKAu4tZ26xkbMhvYzcYkOaq9KVVsfnO8Xd+fHxM38GmaNhecqHA6h3wbSVqsPr7HdT8WdDCPFNvewZWgCtWggUQtDR/yapRTAbxaxw80VoFdUmlAocF4CJnr2AFDz8WgAnFFWcdYPvH21o05YZJPcEJxSstZl/V+tVKGAU0XLTEC/Cm34JaRM4l23aD6LC4Q0YPlLwDT07QFrDoI9i2KveV0LM6tGBf6R8FLfdO3HAJSRwShLXqml4lq2K9YTv6witpZm653DZcrfVYfn79ictare+M8MKlavSTj1p1E4OCi5/GCDUzYP6vM/oEWi3LPZVUGf3Av7/+Mc+ammkNi0pqayrZMBtZ8QiyIJobW9jXT08UWR2VnNG4eOJCDwXbHastMAE6B9MStxHbzV/XTCkunmszT7KyemHrRo8VWjeWr03866EnWtRsAbrHXWQf5bJCR6WsBN8GRyMBQ05jMgsKwwUoq9zMo8pQ12p2SRa2JSXnJSlJRd06z4YVtiWFt0u6zhDj3eg281mW2blqrahZKgzNWm+c4s92xlEiE3RTsHXOa/O7c4/LqGQ0X++odkejtSbkQvmVyu1AN7cjNexUEN2qWwvCzoz5dfLludHPsG2hOz0vsahorv1xL6sgDKGFbvgZ3UfWtE/vG8PNnaCst6CwhxwuHGJgeJZDKQ9qY7TnTfV6LwZd9paeJCZX8lpSoYNUCN05kVfBRZwjLd5sfB4WXoBnyZi4G4pceiK3nm3gKclL82zDRevVn2i6JFmGYJq4Uvh17vBNumonWb2rirwLuqaLuEeZBI7ZxslpR7oxxFfZmOxeZXcep5NfNv52/3qUrmN3WNvQ8UD08CM6saGTMRXeMo1wFiWzdw3k2lRgMr6AhieWZ0tvjF30pn6xkfnFRjYQvVdco3DMcQF+Z+VjViYO30BwguPYF409G11oFF1feiew0RX55QaIvVIPiofC98s9njUF9CtZEBkK34+cxBOe+MF7biow8YPPhsIb7m09unAoHXfGjG3w0A/+rG7kUBf54ZFrvMfa+sYl9IP3jUv0iA081BuQA5AM9QbUi4BkqL4uAtKh+vYzWObZBSH9Gw2xq+qPw4m6Hh7KRJmz6xG7uh7xwFsI0qvH+Gmfo19T8djfeNjgiNHAMzLuk7HjCdsnZL6HOGe0xANvrIgVDY8/ceOveQnjc6pKXMaasF8041hIXfQmA1sO/RJZOmHLYcbWc7Uc4myClgOezw1wOPQK2Jr5MZywgzFf78auahGjoaf6XskJj6my4HeZdTKf65YKe5dZ8LM6C4+ps2Ayu1xHRtH1nZw67yZO7/btS/hVTjjt3Ubw7yO4F5WN/SoBhZdlooz8Th8lkNCr+XBZyYfuA/nfuw9k5Ecut0vr6TQ4dfZ7sKs+JdN95UKWSRhB9Bu5UzSwBUT63GiQeHxXgczmLpHggafYfrYgE5yyZmSMZGjZ3s8a6QR14IyskQ2tUyzW0BtAu5Otrv6LYQEKqqH0s79Us/35R73dMS1uAV50Pu7eS2GcZChJMc5QFB0O/wG0o9do

It would be ideal to be able to receive some signal if a resource is stuck in the router for a configurable amount of time...
I can then connect the router to the speaker to receive the alarm.

And I think this alarm should be network-wide so as not to connect speakers to each router :) I see your network already uses special signals, just add an one more.

And each router must have a display ID, and this ID must be present in the alarm.

I thought maybe it would be worth making a button (and/or signal?) that would force the network to completely reset and recalculate the routes, and send everything that is stuck to buffer boxes, not allowing the terminals to send anything until all routers are clean for some reason time so that all the tapes have time to clear?

Also a good idea. Adding it to TODO.MD. I think I wouldn't make it "until all routers are clear" but instead just "as long as the signal is asserted".

By the way, how does default priority work?
Those. I have a "sender" person with a resource and 2 "default" ones, with priorities 10 and 100, both having some amount of the same resource. When a resource is requested, who will send it?

The routing algorithm is controlled by the circuit network and not lua (mostly for UPS reasons), so it's pretty basic. The system propagates a demand signal for each resource across the network, in a way that weakens over distance (edit: distance is measured in links: the routers don't know where they are or how long the belts are between them). The routers just send everything in any direction of higher-than-average demand: since the demand signal weakens with distance, this is generally toward the requester. Demands are always positive, so it can never send to a terminal which didn't request that item, unless that terminal requests Default.

Each terminal has a "threshold" setting that you can adjust (using the small "threshold trim" combinator on the terminal). When the terminal sees a demand above the threshold, it sends that resource. So the main answer is: it will be sent first by terminals which are closer and/or which have a lower threshold setting.

The demand signal is a little slow to propagate, which can result in too much being sent. Also, multiple terminals might send at the same time. To avoid this happening too much, the terminals have a rate-limiting circuit, so if demand is only slightly over threshold they won't send the resource at the full belt rate.

Whenever a router sends an item, it signals the next router in the network, and that next router keeps a count and reduces the demand by that much. This is also to prevent too much of the item from being sent, but the system isn't perfect and can lead to oversupply.

If a router gets an item which is not demanded by any of its neighbors (probably due to too much being sent, and the demand has since dropped to zero), it sends it toward whoever has higher-than-average demand for Default. Since Default is not an item, the Default signal is never reduced by counting items on belts, so Default routes just depend on which terminals set Default, to how high a value, and how far away they are. If nobody demands the item and nobody demands Default, then the item gets stuck. If on some terminal you set default to a very small value, then because the signal gets weaker with distance, it might not propagate to the full network.

Ok, that's about clear. That is, if some distant terminal does not receive what it requires, because this resource is being processed by those closer to the sender, you need to change the “threshold” value on the receiving terminal, did I understand correctly?

"Threshold" is only for sending. If a receiver isn't getting enough, you could adjust its request up, and/or adjust threshold on the senders so that they will send more rapidly (if they have the item in stock). But there isn't a priority system for requests, beyond the request amount itself.

Ok, I see, thanks.