Friday Facts #317 - New pathfinding algorithm
Re: Friday Facts #317 - New pathfinding algorithm
Say the new algorithm ?? H-hehh
TWO! hours did nothing and just watched the new algorithm))
Before my eyes, after the shelling of the cannons, several flocks were organized, both large and smaller. And they stood still. I watched them all this time. During this time, after an hour and a half, several small groups arrived, where they hid for two hours?)) The main group, on the left in the screenshot, melted until it started to disappear, like most others. The remaining screenshots are in the archive. Look at them yourself.
TWO! hours did nothing and just watched the new algorithm))
Before my eyes, after the shelling of the cannons, several flocks were organized, both large and smaller. And they stood still. I watched them all this time. During this time, after an hour and a half, several small groups arrived, where they hid for two hours?)) The main group, on the left in the screenshot, melted until it started to disappear, like most others. The remaining screenshots are in the archive. Look at them yourself.
- Attachments
-
- show-path2.jpg (478.35 KiB) Viewed 8221 times
-
- 181019.ZIP
- (2.82 MiB) Downloaded 193 times
Re: Friday Facts #317 - New pathfinding algorithm
I have seen megabases that are less than one percent that size, and that only because of their pollution cloud, not because they actually used that much land.
If you think something other than the map size is the problem, you'll need to post a save, not just screenshots.
-
- Manual Inserter
- Posts: 1
- Joined: Fri Oct 18, 2019 2:52 pm
- Contact:
Re: Friday Facts #317 - New pathfinding algorithm
Hello. I'm a junior professor on informatics and during my phd I've worked with the parallelization of the A Star algorithm and I found this ff fascinating. I have a question: what's the data structure you're using for the OpenList and ClosedList?
Usually the ClosedList is implemented using a hash table or STL map. But the OpenList is much more complicated. Commonly implemented using two data structures, a hashmap/map and a priority queue. Although, the famous libboost has a great structure called multi-index and I was able to avoid duplicate nodes in memory just by using it.
If you're interested, search for "PA-Star: A disk-assisted parallel A-Star strategy with locality-sensitive hash for the multiple sequence alignment". The code is also available on github
Usually the ClosedList is implemented using a hash table or STL map. But the OpenList is much more complicated. Commonly implemented using two data structures, a hashmap/map and a priority queue. Although, the famous libboost has a great structure called multi-index and I was able to avoid duplicate nodes in memory just by using it.
If you're interested, search for "PA-Star: A disk-assisted parallel A-Star strategy with locality-sensitive hash for the multiple sequence alignment". The code is also available on github
Re: Friday Facts #317 - New pathfinding algorithm
We use just plain old binary heap for the open list. Plus a map for an all-nodes list, and each node has an “is closed” boolean in it, so that there's just one map to look up both closed and open nodes in, and closing a node amounts to setting a bool, and popping it off the open heap.danielsundfeld wrote: ↑Fri Oct 18, 2019 4:36 pm Hello. I'm a junior professor on informatics and during my phd I've worked with the parallelization of the A Star algorithm and I found this ff fascinating. I have a question: what's the data structure you're using for the OpenList and ClosedList?
Usually the ClosedList is implemented using a hash table or STL map. But the OpenList is much more complicated. Commonly implemented using two data structures, a hashmap/map and a priority queue. Although, the famous libboost has a great structure called multi-index and I was able to avoid duplicate nodes in memory just by using it.
If you're interested, search for "PA-Star: A disk-assisted parallel A-Star strategy with locality-sensitive hash for the multiple sequence alignment". The code is also available on github
Re: Friday Facts #317 - New pathfinding algorithm
A n-th level A* pathfinding is a good thing to have (I'm surprised it was not even already here).
What you could do to improve again this algorithm, is to go from 2 level of nodes to a 3 or 4 lvl node A* pathfinding. A power 2 scale or 3 should be a good (or a mix)
What you could do to improve again this algorithm, is to go from 2 level of nodes to a 3 or 4 lvl node A* pathfinding. A power 2 scale or 3 should be a good (or a mix)
Re: Friday Facts #317 - New pathfinding algorithm
Thanks for your hard work Togos!
Re: Friday Facts #317 - New pathfinding algorithm
You are using the A* Algorithm for defining the final path.
Why are you not using a Jump Point Search instead, which should be faster than the A*?
Why are you not using a Jump Point Search instead, which should be faster than the A*?
Re: Friday Facts #317 - New pathfinding algorithm
JPS basically means you store fewer nodes in memory, at the cost of examining more, since you can examine a node potentially multiple times during a search (because it's not saved). “Examining a node” in Factorio means doing a collision check, which is a rather expensive operation. So, in other words, it's the trade-off of having smaller open set at the cost of doing more collision checks. I don't think that trade-off makes sense for us.
Funnily enough, all the JPS benchmarks I've seen are on simple grids where examining a node amounts to reading a single bit from memory (wall/not wall), and those benchmarks usually only focus on the number of nodes stored in memory, rather than grid cells actually touched by the algorithm.
Re: Friday Facts #317 - New pathfinding algorithm
It was released in 17.70 (a few days ago).TheRealBecks wrote: ↑Fri Oct 18, 2019 2:45 pm Great! Is there already a timeline for that new pathfinding engine? Maybe... today?
There are 10 types of people: those who get this joke and those who don't.
Re: Friday Facts #317 - New pathfinding algorithm
Hi! another CS student here...
Are you aware of D* Lite? It's an algorithm for this problem that works simillary to A* (uses same heuristics), but can be much faster in your use case -> it's designed to handle graph that changes while it is traversed.
So, if you find a path and something changes (new building, or whatever), this algorithm should be faster than starting A* again.
"should be" is however proper term used, as it's not outmatching "repeated A*" in worst case scenario.
John
Are you aware of D* Lite? It's an algorithm for this problem that works simillary to A* (uses same heuristics), but can be much faster in your use case -> it's designed to handle graph that changes while it is traversed.
So, if you find a path and something changes (new building, or whatever), this algorithm should be faster than starting A* again.
"should be" is however proper term used, as it's not outmatching "repeated A*" in worst case scenario.
John
- BlueTemplar
- Smart Inserter
- Posts: 3202
- Joined: Fri Jun 08, 2018 2:16 pm
- Contact:
Re: Friday Facts #317 - New pathfinding algorithm
You've been featured on Hacker News !
BobDiggity (mod-scenario-pack)
Re: Friday Facts #317 - New pathfinding algorithm
*cough* flow field vector pathing *cough cough*
Re: Friday Facts #317 - New pathfinding algorithm
Cool stuff, but similar to https://www.computer.org/csdl/proceedin ... 2OmNAolH2Q
Re: Friday Facts #317 - New pathfinding algorithm
You know, I wouldn't at all be opposed to smaller biters being able to either squeeze through trees easily, or not collide with them at all.Oxyd wrote: ↑Fri Oct 18, 2019 12:04 pmTaking cliffs into account on the abstract level is not a bad idea, but it would mean that splitting a chunk into components would now have to look at the chunk's entities, which is considerably more complicated and slower than simply looking at its tiles – tiles are, basically, just integers.LotA wrote: ↑Fri Oct 18, 2019 11:22 am Magnificent !
Although, I'm wondering if cliffs should not be taken into account by the "abstract pathfinder", It's not something you can remove early on and even when you can, most of it will remain intact (as you will probably only remove cliffs from inside your base). The only moment the pathfinding "slows down" is precisely when it has to find a way around cliffs using the "base pathfinder". Moreover, you don't need to update the abstract map on any cliff destruction, just once in a while, ideally when a bitter comes close and "finds out" a new way is available.
Anyway this looks very very promising.
Also, the biggest hurdle for the base pathfinder now is something very relatable to everyone: Trees.
Re: Friday Facts #317 - New pathfinding algorithm
<biters-on-belts.gif>programaths wrote: ↑Fri Oct 18, 2019 11:44 am TOGoS, from conveyor belts to treadmills...there is only a step!
Thanks for the well-wishes everybody!
Re: Friday Facts #317 - New pathfinding algorithm
You are show the pathfinding only from A to B, is two sided search not better? I can simultaneously search paths A to B abd B to A, just wait when they find the same point, connection point.
- BlueTemplar
- Smart Inserter
- Posts: 3202
- Joined: Fri Jun 08, 2018 2:16 pm
- Contact:
Re: Friday Facts #317 - New pathfinding algorithm
I guess that you already thought of this, but maybe converting cliffs to be, like water, a tile type rather than an entity - would be a better solution ?Oxyd wrote: ↑Fri Oct 18, 2019 12:04 pmTaking cliffs into account on the abstract level is not a bad idea, but it would mean that splitting a chunk into components would now have to look at the chunk's entities, which is considerably more complicated and slower than simply looking at its tiles – tiles are, basically, just integers.LotA wrote: ↑Fri Oct 18, 2019 11:22 am Magnificent !
Although, I'm wondering if cliffs should not be taken into account by the "abstract pathfinder", It's not something you can remove early on and even when you can, most of it will remain intact (as you will probably only remove cliffs from inside your base). The only moment the pathfinding "slows down" is precisely when it has to find a way around cliffs using the "base pathfinder". Moreover, you don't need to update the abstract map on any cliff destruction, just once in a while, ideally when a bitter comes close and "finds out" a new way is available.
Anyway this looks very very promising.
Also, the biggest hurdle for the base pathfinder now is something very relatable to everyone: Trees.
(Also in this way, you can use the same algorithm accounting for map changes for landfill and for cliff explosives...)
And it would hopefully solve all those issues with cliff bounding-box-corners sticking out and trapping belts, rails & cars !
PIC
While on the other hand trees and rocks are ultimately easy to destroy, and biters in fact do regularly destroy them to get a better path : make a very polluting base on the other side of a dense forest from a nest and see the biters clear a path in it !BobDiggity (mod-scenario-pack)
- BlueTemplar
- Smart Inserter
- Posts: 3202
- Joined: Fri Jun 08, 2018 2:16 pm
- Contact:
Re: Friday Facts #317 - New pathfinding algorithm
Give'm hell !TOGoS wrote: ↑Sat Oct 19, 2019 4:49 pm<biters-on-belts.gif>programaths wrote: ↑Fri Oct 18, 2019 11:44 am TOGoS, from conveyor belts to treadmills...there is only a step!
Thanks for the well-wishes everybody!
BobDiggity (mod-scenario-pack)
-
- Burner Inserter
- Posts: 14
- Joined: Sat Apr 27, 2019 12:38 pm
- Contact:
Re: Friday Facts #317 - New pathfinding algorithm
Congratulations on the new pathfinding algorithm and good luck Togos.
I have been expanding my base so I have done a lot of fighting. I usually build a turret barrier and attract the enemies. I have observed that they don't attack the barrier but focus on trying to reach the player, as seen in the snapshot below. If I stand far enough behind, I and the turrets don't suffer any damage. Is it intended or not?
Best regards,
Marcos
I have been expanding my base so I have done a lot of fighting. I usually build a turret barrier and attract the enemies. I have observed that they don't attack the barrier but focus on trying to reach the player, as seen in the snapshot below. If I stand far enough behind, I and the turrets don't suffer any damage. Is it intended or not?
Best regards,
Marcos