Skip to content

Commit 1ee2acd

Browse files
authored
Update README.md
Update description for Implementation details
1 parent 5a17490 commit 1ee2acd

File tree

1 file changed

+3
-3
lines changed

1 file changed

+3
-3
lines changed

README.md

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -132,9 +132,9 @@ All pathfinding algorithms in this library are inheriting the Finder class. It h
132132

133133
The normal process works like this:
134134

135-
1. You call `find_path` on one of your finder implementations
136-
1. `init_find` instantiates `open_list` and resets all values and counters.
137-
1. The main loop starts on the `open_list`. This list gets filled with all nodes that will be processed next (e.g. all neighbors that are walkable). For this you need to implement `check_neighbors` in your own finder implementation.
135+
1. You call `find_path` on one of your finder implementations.
136+
1. `init_find` instantiates the `open_list` and resets all values and counters.
137+
1. The main loop starts on the `open_list`. This list gets filled with all nodes that will be processed next (e.g. all current neighbors that are walkable). For this you need to implement `check_neighbors` in your own finder implementation.
138138
1. For example in A*s implementation of `check_neighbors` you first want to get the next node closest from the current starting point from the open list. the `next_node` method in Finder does this by giving you the node with a minimum `f`-value from the open list, it closes it and removes it from the `open_list`.
139139
1. if this node is not the end node we go on and get its neighbors by calling `find_neighbors`. This just calls `grid.neighbors` for most algorithms.
140140
1. If none of the neighbors are the end node we want to process the neighbors to calculate their distances in `process_node`

0 commit comments

Comments
 (0)