| Age | Commit message (Collapse) | Author |
|---|
|
Currently translated at 51.5% (457 of 887 strings)
|
|
Currently translated at 90.7% (805 of 887 strings)
|
|
Currently translated at 50.6% (449 of 887 strings)
|
|
Currently translated at 75.7% (672 of 887 strings)
|
|
Currently translated at 27.6% (245 of 887 strings)
This is a merger of two commits.
|
|
Currently translated at 73.9% (656 of 887 strings)
|
|
Currently translated at 100.0% (887 of 887 strings)
This is a merger of three commits.
|
|
Currently translated at 89.6% (795 of 887 strings)
This is a merger of three commits.
|
|
Currently translated at 85.6% (760 of 887 strings)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Doing it the other way round was a mistake, since it breaks
minetest.formspec_escape with escape sequences that contain
special characters.
|
|
This makes it work even if it contains escape sequences,
which didn't work before.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fixes the issue introduced by c1a0ebb (Fix use of uninitialised variable
in class Event) causing Windows builds to fail
|
|
|
|
The path finding code works fairly well except that it considers
anythin not CONTENT_AIR to be "above the surface". This results in
paths that are unwalkable for entities since e.g. plants are not
walkable. The path would force them to jump on top of grass plants,
etc..
The obvious solution is not to use CONTENT_AIR as a criteria, but
instead distinguish between walkable and non-walkable nodes. This
results in paths that properly walk through grass nodes.
This was extensively tested by a flock of electric sheep.
Note that for underwater purposes this changes the behaviour from
"the surface is walkable" to "ignore water entirely" making the
path go across the water bottom, and pathing fail likely from the
water surface. This is intentional.
|
|
Before, the GridNodes were stored in vector<vector<vector<T>>>,
and initialized in advance. Putting three vectors inside each other
puts lots of unneccessary stress onto the allocator, costs more memory,
and has worse cache locality than a flat vector<T>.
For larger search distances, an the array getting initialized means
essentially O(distance^3) complexity in both time and memory,
which makes the current path search a joke. In order to really
profit from the dijkstra/A* algorithms, other data structures
need to be used for larger distances.
For shorter distances, a map based GridNode storage may be slow as
it requires lots of levels of indirection, which is bad for things like
cache locality, and an array based storage may be faster.
This commit does:
1. remove the vector<vector<vector<T>>> based GridNodes storage that
is allocated and initialized in advance and for the whole
possible area.
2. Add a vector<T> based GridNodes storage that is allocated and
initialized in advance for the whole possible area.
3. Add a map<P,T> based GridNodes storage whose elements are
allocated and initialized, when the path search code
demands it.
4. Add code to decide between approach 2 and 3,
based on the length of the path.
5. Remove the unused "surfaces" member of the PathGridnode class.
Setting this isn't as easy anymore for the
map based GridNodes storage.
|
|
There is no need to reinvent the wheel here, we have
great classes from irrlicht.
|
|
* Fix naming style for methods and classes:
Use camelCase for methods and PascalCase for classes as
code style demands it. And use sneak_case for methods that
are not member of a class.
* Replace "* " with " *" for Pointers
* Same for references
* Put function body opening braces on new line
* Other misc minor non functional style improvements
|
|
There is no need to put them into the header, they are solely used
inside the pathfinder.
Another advantage of this change is that only the pathfinder.cpp has
to be compiled if PATHFINDER_DEBUG gets defined or undefined, not
all files including the .h.
This commit moves the pathfinder classes to the cpp file without
modifications.
Also, the PATHFINDER_DEBUG macro gets moved to the cpp file and
the PATHFINDER_CALC_TIME macro gets moved to a plce where it
actually does work.
|
|
|
|
|
|
|
|
Currently translated at 51.7% (448 of 865 strings)
This is a merger of two commits.
|
|
Currently translated at 100.0% (865 of 865 strings)
This is a merger of two commits.
|
|
Currently translated at 75.4% (653 of 865 strings)
|
|
Currently translated at 46.5% (403 of 865 strings)
This is a merger of two commits.
|
|
Currently translated at 28.7% (249 of 865 strings)
|
|
Currently translated at 57.4% (497 of 865 strings)
This is a merger of three commits.
|
|
Currently translated at 21.8% (189 of 865 strings)
|
|
Currently translated at 67.5% (584 of 865 strings)
This is a merger of 5 commits.
|
|
Currently translated at 100.0% (865 of 865 strings)
This is a merger of two commits.
|
|
Currently translated at 75.3% (652 of 865 strings)
This is a merger of 3 commits.
|
|
Currently translated at 59.3% (513 of 865 strings)
This is a merger of 5 commits.
|
|
Currently translated at 58.9% (510 of 865 strings)
This is a merger of two commits.
|
|
Currently translated at 58.9% (510 of 865 strings)
|
|
Currently translated at 58.9% (510 of 865 strings)
This is a merger of two commits.
|
|
Currently translated at 58.9% (510 of 865 strings)
|
|
Currently translated at 46.2% (400 of 865 strings)
|
