Modify fpp & allow fleeing creatures to use pathMatching #4969
Conversation
|
Looks like new flee algorithm works better, it does not stuck in random places ex. current master algorithm stuck here forever: New algorithm has some problem with keeping distance: |
|
Yes, the code for fleeing monsters isn't perfect yet but the old code wasn't either. I will try to get it working better but I think having fleeing monsters that are only stuck until you get close is better than ones that are stuck even when you are close. (I know my other fix helped that a lot but there was still plenty of ways to get them stuck when the player was close to them). Now if the player is close to them they at least know how to get away. I will try to get it working better if it will stop this PR from being merged but this is good bones for adding different "AI" monster behavior. It's also simplified so hopefully more people can understand what is happening. We could also add the changes for this other than moving the fleeing monsters and just use my other fix. If that is preferred I can modify this PR and reopen my other one again. Also as far as it moving to 3 which it shouldn't because its closer to player, there are many cases where this will allow the monster to find a way out of corners. I think I have an idea to get it working better. I will test it out here in a bit. |
IDK, if they changed something on RL Tibia, but monsters getting stuck was a feature on RL Tibia and it was added in some version of TFS. To replicate RL Tibia 'dumb monsters', I had to add a lot of IFs in monsters logic and write second path finding algorithm (check tiles in 2-3 SQM range), that does not use A* to find path, when player is 1-2 SQM from monster. Depending on situation monster switched between path finding algorithms. |
|
When I was doing tests I never saw pathfinding being called on fleeing creatures. I send a magiceffect out to show paths when they are drawn. |
|
Alright, this should be a pretty good implementation now. Needs some more testing probably but from what I have tested everything is looking really good. |
NRH-AA
changed the title
|
I had a case where monster, while fleeing, chose a square that was closer to the player then the rest |
|
Alright, I will do some more testing and see if I can figure out what the issue is. That behavior would happen in the new getDistanceStep code I created. Give me some time and ill get it. @ArturKnopik You may need to add the revert heuristic PR for this to work correctly. |
|
https://youtu.be/v7s-jcYlbws |
| { | ||
| Creature::getPathSearchParams(creature, fpp); | ||
| fpp.fullPathSearch = true; | ||
| } |
There was a problem hiding this comment.
Remove this function from the class since it does nothing but call the base class function
| // maxSearchDist = 0]]]]]) selfMoveTo(position[, minTargetDist = 1[, maxTargetDist = 1[, fullPathSearch = true[, | ||
| // clearSight = true[, maxSearchDist = 0]]]]]) | ||
| // selfMoveTo(x, y, z[, targetDist = 1[, clearSight = true[, maxSearchDist = 0]]]) | ||
| // selfMoveTo(position[, targetDist = 1[, clearSight = true[, maxSearchDist = 0]]]) |
There was a problem hiding this comment.
This is a breaking change, can the previous signature be emulated using the new signature? If yes, then add a compat layer
4 participants
Pull Request Prelude
Changes Proposed
Remove unused fpp vars, add some vars to handle different pathMatching senarios, change how we check for correct paths so it is easier to make different pathMatching senarios. Move fleeing monsters to pathMatching instead of distanceStep.
Issues addressed:
N/A
How to test:
https://youtu.be/VFpEPI7FSvU
Make sure when player walks to items on ground at a distance when moved (tested)
Make sure player walks to creatures when moving them
Make sure all paths are still being made.