Hi im trying to write a plugin that supports walking around immovable monsters.
Its pretty annoying when theres a Geographer/Flora/Drosera etc on the way to your lockmap or theres loot near them and the bot walks into them.
The problem is i dont know how to make the bot walk around them.
One possible solution could be to rewrite the fieldfile on the fly and make the fields around the monster non-walkable.
But i dont know how to do this.
Maybe you could avoid them like the portals are avoided, but i couldnt find information on this.
So could you please help me on how to do this?
Plugin supporting immovable Monsters
Moderator: Moderators
Re: Plugin supporting immovable Monsters
This seems rather interesting. I might dig in once I have some time. Keep us updated on the progress.
Re: Plugin supporting immovable Monsters
Once upon a time. I've written a 'Drunken walk' patch for OpenKore.
So it picked random point (radius was given in config.txt) around intermediate points in route to the target point.
So It could look more human.
But, again. "Field" package does not support changing map 'penalty' values in runtime. So it's gonna be hard.
I think, that you may try to patch XSTools A* part and it's Perl Accessors, to support runtime change of 'penaly' values. That will enable you to make that possibility to avoid getting close to mob's on map.
But, I might remind you, that A* is a heavy computation task, and recomputing route each time can result in CPU overload.
So it picked random point (radius was given in config.txt) around intermediate points in route to the target point.
So It could look more human.
But, again. "Field" package does not support changing map 'penalty' values in runtime. So it's gonna be hard.
I think, that you may try to patch XSTools A* part and it's Perl Accessors, to support runtime change of 'penaly' values. That will enable you to make that possibility to avoid getting close to mob's on map.
But, I might remind you, that A* is a heavy computation task, and recomputing route each time can result in CPU overload.
-
- Developers
- Posts: 1798
- Joined: 05 Dec 2008, 05:42
- Noob?: Yes
Re: Plugin supporting immovable Monsters
Drunken walking is unrelated to that, as completely different path may be chosen if monsters completely block one of alternative paths. It would require to remember offscreen monster positions too.
Recalculating only needed when specific monster appears on your path.
Recalculating only needed when specific monster appears on your path.
Re: Plugin supporting immovable Monsters
I will not agree on that.EternalHarvest wrote:Drunken walking is unrelated to that, as completely different path may be chosen if monsters completely block one of alternative paths. It would require to remember offscreen monster positions too.
Recalculating only needed when specific monster appears on your path.
"Drunken walk" was made in a way, to avoid intermediate point and pick one near.
As A* Calculates all the possible way's, and stick to Highest ranked points.
The next intermediate point is picked on the way, then the next point is the highest ranked in the len on step.
So, if you add penalty in runtime when A* is already calculated, you could avoid the next 'dangerous' step and pick the more safe one.
The offscreen 'penalty' could be removed, because the is really low chance that the next intermediate point will be picked there, once you took the more low ranked path.
-
- Developers
- Posts: 1798
- Joined: 05 Dec 2008, 05:42
- Noob?: Yes
Re: Plugin supporting immovable Monsters
Let's say we're moving from A to B via C. If an immobile monster blocks C, no further intermediate points would be useful as the whole route should go via D instead.
Then, if D is blocked too, we need the offscreen data about blocked C to not be stuck moving back and forth between C and D and try to go via E instead (unreliable data should be removed after a while, but it's needed).
Re: Plugin supporting immovable Monsters
Could you try to model using A* as a Rainbow on map?EternalHarvest wrote:
Let's say we're moving from A to B via C. If an immobile monster blocks C, no further intermediate points would be useful as the whole route should go via D instead.
Then, if D is blocked too, we need the offscreen data about blocked C to not be stuck moving back and forth between C and D and try to go via E instead (unreliable data should be removed after a while, but it's needed).
I can think of a solution, that from A to B should be the most short way. So if we picked Route A->C->B and C is blocked, the next most short way will be A->D->B, and if D is blocked too, then next short way should be A->E->B. Because we use already Calculated A* of out route, we do not need to remove 'Penalty' values of the current calculation. Only if we stuck, and need to recalculate the whole rote.