The problem isn't that it's not recalculating enough, the problem is that it arrives at the wrong answer when it does recalculate; it doesn't matter how many times I make it redo the math if it's just going to make the same mistake. At any rate, passing signals does not cause recalculation. Other co...

OK that makes sense....but what about the original example I gave? That is just about trains stopping in the roundabout because they didn't seem to follow the new rule (nothing to do with self collision).

The fix and the related logic has nothing to do with preventing train self-collisions on roundabounds. The fix is related to not allowing train to get stuck in chain signal section, but it can still pick a different exit then previously selected (on purpose). The logic itself doesn't have anything ...

The same applies if the destination station gets disabled by a circuit, if the destination station becomes inaccessible, or if rail along the planned path gets destroyed/removed. As far as I can tell, there are only 2 different behaviors of trains regarding pathfinding: (in the wiki's terms,) revali...

"Paving"/"pavement" seems like the best alternative so far.

Trains making an effort to not plug up other trains' stations is a good thing at any distance. The solution is to not put stops in weird places on rail lines that other trains will be trying to path through (and cannot avoid).

Working as intended. Train stops that are not the destination are more expensive to path to/through than train stops that are, but are occupied.

I did it by clicking the arrow in the train schedule manually, but the fix says it's a general rule about repathing while within a chain segment, so the cause of the repath shouldn't make a difference. (Also the wiki doesn't indicate any distinction.) The two stations I used are the ones in the scre...

+1. It seems backwards that people have to go to considerable lengths to destroy unwanted items (sacrifice box and bullets) while at the same time potentially precious ingredients are snatched away so easily. If productivity exploitation is in fact the problem, I'd argue that there are better ways t...

See 68681 Either I'm misunderstanding something, or the fix in the 0.17.38 patch notes is not working as described: Changes When a train performs path finding while in a chain signal sequence, the pathfinding will have a constraint to not go through reserved block before exiting the chain sequence. ...

Really? You can't think of any reasons that communities of people or developers shouldn't use common nomenclature rather than redefine their own terms? I mean... certainly there can't be any loss of readability if we just ignore the english language and redefine terms as we feel like it... Seriousl...

The one caveat I see is that the transmission efficiency for the standby field would have to be something miserable like 5% or dependent upon n in order for people to actually care about its cost (and for the change to not just be a massive buff to roboports/bots).

Bottleneck! Yes, that's the term we want. The point is to convert hard limits imposed by untenable factors into bottlenecks that can be resolved with scaling or clever design, not to just make things easier by buffing numbers or removing limiting factors entirely.

A lot of suggestions seem to be around trying to adjust the algorithms for bot charging. I don't think any of these will give a great solution but worse, for heavily bot based factories it could have a huge impact on UPS. Simple queues You're looking at O(1) for adding a new bot. Once you start ins...

Hallelujah!

The ideal outcome is to pick bots with just barely enough energy to dash to the charge pad. Skip all bots below the threshold (they will crawl and slow things down), and continue queueing bots above the threshold. Unfortunately it sounds like a pretty dumb algorithm, because it means searching for ...

The total workload on the roboport is the same or slightly lower, but it is not distributed the same; because the bots fly faster, they make it back to the roboport faster (and closer in time to each other), so they will spend more time queued at the roboport (rather than in transit) because the rob...

Don't you want bots with more charge to go first?[...] But does this theoretical issue have practical consequences? In what factory is higher speed research an actual measurable drawback? The practical problem to be addressed is the case where a large number of robots arrive at a roboport in a rand...

That'd be neat if roboports prioritized fast bots to keep the charging ports working as fast as possible. If by "fast bots" you mean ones that haven't drained completely, I don't know if that's really necessary, since that would only apply if some bots already ran out of power. The only p...

Since the deadlock issue appears to be a thing, I'm going to assume that roboports use a first-come-first-serve rule to recharge bots. This is because the premise of deadlocks being caused by speed research is that bots that would, without the research, still be en-route to the roboport make it to t...