Optimize pathfinding

[NRH-AA]

Pull Request Prelude

• I have followed proper The Forgotten Server code styling.
• I have read and understood the contribution guidelines before making this PR.
• I am aware that this PR may be closed if the above-mentioned criteria are not fulfilled.

Changes Proposed

This is a overhaul of when and how pathfinding is done. I did attempt this before but I closed the pull request due to congestion. I believe all problems from the original pull request have been fixed.

This will change the pathfinding to work as A* algorithm rather than djikstra's.
It will also add more pathfinding calls as needed fixing monster moving around slowly due to 1 second pathfinding interval.
This PR also includes separation of when creatures will update their path from creatures onThink.
Lastly it includes some fixes for bugs which were not detectable until pathfinding was able to be called more often.

Issues addressed:
Might fix: #4617

[MillhioreBT]

I did a quick test but this PR doesn't work, the monsters walk randomly and move away from the target slowly until they disappear from sight, and the summons don't have any type of movement.

[Codinablack]

LGTM!

[floki21uu]

BUG: after changing the floor for the first time,

monsters have a slow walk reaction.
If the monsters had seen you before, they will have the correct walk reaction.

[NRH-AA]

BUG: after changing the floor for the first time, monsters have a slow walk reaction. If the monsters had seen you before, they will have the correct walk reaction.

I am still looking into this but I seriously doubt this problem is created from this PR. The only reason you are noticing it more now is because monsters have faster reactions in 99% of cases compared to base repo

[NRH-AA]

The new constexpr update seems to have destroyed this

edit: I think changing int_fast32_t, ect is the problem.

[NRH-AA]

Can someone test the last commit. I think this should fix the pathfinding again. I also tried to fix the reaction speed when a monster first targets a player that has changed floors. @floki21uu

Keep in mind you will need to have updated to the new constexpr position methods.

[NRH-AA]

std::sqrt is running almost 3x faster than std::hypot

[ranisalt]

edit: I think changing int_fast32_t, ect is the problem.

FP math is orders of magnitude slower than integer math. I don't see why you changed the get*Cost functions to use doubles without changing how they work.

std::sqrt is running almost 3x faster than std::hypot

How did you measure it?

[NRH-AA]

edit: I think changing int_fast32_t, ect is the problem.

FP math is orders of magnitude slower than integer math. I don't see why you changed the get*Cost functions to use doubles without changing how they work.

std::sqrt is running almost 3x faster than std::hypot

How did you measure it?

I used time measurements strictly around the sqrt operation. I checked 1sqm-100sqm paths. I also created a small project just as a frame of reference using only the sqrt and hypot so there wasn't any additional bloatware. All instances were 2-3x faster from what I saw. I also tried different data types with integers giving the best results with sqrt being 3-4x faster. With that being said, I am not aware of tools, ect that can be used so its just based on time measurements. Someone with more experience may be able to look into it more.

As for what I changed to double I can revert some of the code back to using integers. I didn't realize I should leave out the heuristic from the g (walk) cost and place it in its own variable. However, I do think leaving the heuristic as a double is best as from everything I read about path finding the more precise the better for the heuristic. In other words I am still learning and did some things that weren't needed. I also didn't know it was done using order of magnitude which I am assuming is referencing the extra cost for fields and destroying creatures

5 Iterations

100k iterations

Edit: I have tried moving back to integers for the walk cost function and the result is that because of how big of a difference the integers are compared to the result of our heuristic the algorithm can no longer find the path properly. So keeping the walk cost as a float or double seems to be the best option and we will have to modify the extra costs to work properly assuming they dont. I do think it works as expected though because I have just divided the values by 10.

We also may be able to just *10 the dx and dy before running sqrt on it as well.

[floki21uu]

The new constexpr update seems to have destroyed this

edit: I think changing int_fast32_t, ect is the problem.

destroyed what?

[NRH-AA]

The new constexpr update seems to have destroyed this
edit: I think changing int_fast32_t, ect is the problem.

destroyed what?

The path finding stopped working with @ranisalt's constexpr position change. I did revert the datatype changes in this repo for pathmatching so I think it should be working properly again.

[NRH-AA]

Lets get this added peeps