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 ...

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 ...

"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 ...

+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 ...

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 ...

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 ...

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 ...

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 ...

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 ...

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 problem I ...

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 ...

+1. I run into this problem when updating multiple blueprints to newer versions (e.g. optimizing rail system blueprints). It struck me as odd that blueprints are so hard to get rid of. If someone takes issue with the suggestion above, I think an alternative would be for Shift+Right Click to trash a ...

+1 to title; I feel like in its current state solar power is too rewarding for the amount of effort it takes, and I like the bad weather / solar eclipse idea to introduce some unreliability. Making solar itself more complex could be interesting, but implementation would be tricky. Either way, I feel ...