mrvn wrote: ↑Thu Sep 12, 2019 5:47 pm
It's a solved problem. Theoretically and Practically. The electric network has such IDs. The fluid system has such IDs.
Even belts have segments that are basically the same and they merge and split constantly as items are added and removed.
You're so very, very wrong it almost hurts to see it, and i'm actually questioning myself if i'm reading your posts correctly.
Understandable though, it's not a simple problem and a complicated subject.
No search algorithms are needed for belts or the electric network, and the fluid system has unique behavior with pipe adjacency -- none of them really use or need any kind of searchable pattern of any description, not even close to the likes of A*.
Electricity is simple point-to-point with a bit of balancing math. Not even comparable to rails, not at all.
Fluids aren't moving anywhere with any kind of intention, they are following a sort of "fluid pressure" based on the pipes next to them. These networks only change on pipe/entity built (and fluidboxes touch).
And belts can be pre-cached so that a single unbroken chain of belt can act like a single belt, so to speak, and only really needs to check where the end of the belt lane is (items included). Belt "networks" only change on entity built. It's perhaps the most complicated one so far, but it is absolutely nothing compared to trains and we
still don't need a search algorithm.
Comparing rails to any of these other network types is simply nonsensical and irrelevant - they are not relatable in any meaningful way.
The only other reasonably comparable .. comparison, would be how biters and other units navigate the world (like biters avoiding water -- and we've all seen how "good" they are at that).
Looking at mods, another example of something that would need something of a search algorithm is something like how starcraft lays creep - it "searches" outward from the central position for the closest tile, within range, that isn't already creep.
Interestingly, target finders can also be compared, sort of how an artillery turret procedurally scans through chunks over time to find a nearby target -- It won't neccessarily be the
actual closest biter nest, but it gets close enough - it will target the biter nest that was "closest" in terms of chunk scans.
Although i agree with the idea of adding some optimization to the trains so that trains don't path on networks that fundamentally don't connect to eachother, as the devs stated, it's adding complexity to an already complicated system, and as Ghoulish too states...
Ghoulish wrote: ↑Wed Dec 04, 2019 8:38 am
I wanted to bring this issue up again. As it's truly a problem for me. I also wanted to get clarification from those familiar with the topic as.. A*.. it's complicated!
I've written A* before.
It involves math so far beyond your understanding it is hard for me to describe it using just words because it relies on what is essentially an infinite loop, and needs some existing knowledge or experience of how code works.
It's like trying to explain what "great circle distance" is -- you really need an image to illustrate what the math is actually doing, and what we're actually dealing with here.
But first....
mrvn wrote: ↑Tue Dec 10, 2019 1:22 pm
The impact would be twofold:
1) When you place a blueprint with 1000 rails then you don't get all trains repathing 1000 times even though the rails don't even connect to anything.
2) When you have stations with the same name but not on the same rail network then they wouldn't get included in any path finding.
This would work, but I'm pretty sure you would simply be replacing one problem with another and you also don't really solve the problem.
Why not only make the check when both sides of the rail are connected to something? This may have more desirable results with less work.
It is my guess that "rail network ID's" as you described it, would reduce the performance for everyone by a linear amount and improve performance exponentially (better performance for bigger factories).
And reminder, this is only in the circumstance of having e.g. 100 trains siting in a station on automation waiting for its next station to open while you are placing a rail segment.
Ghoulish wrote: ↑Wed Dec 04, 2019 8:38 am
~How would it effect the pathfinding in an Explain like I'm 5 way?
A* search algorithm, in a nutshell.
The math to calculate shortest path between nodes (or points) on a grid.
https://en.wikipedia.org/wiki/A*_search_algorithm
A* is used due to its simplicity and reliability for most applications.
You heard me, due to its
simplicity.
The dots are color-coded based on their distance from the goal.
You could consider each single step as costing $1, and the walls as making a single step costing $5.
Interesting how this could lead to situations where the shortest path is through a waiting train -- but the potential issues are acceptable.
The effect it has for
you is that you need to build smaller networks and use less roundabouts.
End-to-end trains may be better.
Train dropoffs to transfer between rail networks may be another idea.
Build less stackers maybe.
"Cheap and nasty"
"The somewhat, but not neccessarily cheaper, but also more complicated Goal-Distance shortest path (used by trains)"
"Literally used commercially to deploy rail networks and chart real train stations across the USA"
And then on top of that, consider train signals and how must those be calculated?
Also if you want anything to come of these thoughts and your raised issues with your save, i suggest posting your save so wube can test
ssilk wrote: ↑Mon Sep 16, 2019 5:32 pm
tracks of different surfaces can connect?
OMG
YOUR LUAS.
GIVE, PLEASE????