Bot gets stuck if multiple targets in range are not in sight

[Shogun]

It happens that the bot targets mobs behind walls or not in line of sight, after MAX_FIGHT_TIME it switches to the next and finally back to the first mob, the bot gets stuck. The common solution is to reduce MAX_TARGET_DIST but this does not really help in instances with lots of sight blocking objects like IDK.

How about remember unattackable mobs? Add these targets to a size limited queue or ringbuffer (max. 10 entries) and do not attack them again but of course fight back.

[silinky]

yes, this happens to me a lot too.
for example one time in KS my character got "obstacle in your way" idiotic frog message, because there was a little earthmound between me and the mob. i mean a 10 cm high earth mound. there was 2 mobs and for hours he just switched targets endlessly.

a stuck timer would help i guess. if there is one already can you tell me how to set it up?

[bokagavrilov]

i think today's patch its the problem..just wait for the next update

[lisa]

Actually they love their little obstruction error, todays patch is proof.

•Mage/Druid (primary/secondary) class skill Magma Blade:
•Client is now able to sense a collision with solid objects, and players are no longer able to attack through solid obstacles.

Magma Blade wasn't affected by the obstruction error and so in this patch they "fixed" it so that it is.

[silinky]

it is not today's patch, i get this for months now

[romaniac]

I'd like to pick up on this topic again. I also have the problem that occasionally the bot gets permanently stuck switching between two targets that are both hidden behind an obstruction (well, not really, but froggy believes that the fireball cannot penetrate a blade of grass).

Currently I try to work around this by modfiying attack distances and moving waypoints, but it is very difficult. It would be great if the bot could recognize such deadlocks and simply move on to the next waypoint if all targets are obstructed. Any chance to see such a mechanism?

[silinky]

another idea is to try to use the skill 1 on those mobs, which hits them with your stick/sword/dagger for a white damage to aggro the mob. after that you don't get the obstacle anymore. for melee this is ok, since shadowstab or slash does not get this error, but for example phantom stab does. weird game this RoM is.

[lisa]

I have been doing some thinking on this lately and there are a few scenarios

1. There are mobs in your path which you "should" be able to attack but because of the obstruction issue you just an't hit them unless you use melee.

2. The mobs are behind a solid object like a wall.



for 1. you could simply initiate a melee attack and then the fight will start and not really cause any issues, this would be very problematic for 2. though as you couldn't get to your target to be able to melee attack them.

So ideally I think we would need to change the existing ignore mobs system to use a table instead of a single mob. After digging deep into the coding used for the ignore target I have to say it is a big job =(

Firstly you would need to change it to use a table of course, you then need to update the table as required so you would also need to record the time the mob is added to the table and if enough time has passed them remove the mob from the table. If the mob is ignored again while still in the table you would also need to update the time to current time otherwise it would still use the old time.
You couldn't simply clear the table because you might need info of a mob previously ignored.

So in short there won't be a working solution any time for this issue.

Suggestions

If your issue is a staircase like in KS change the waypoint to "RUN" for those few coords, it will ignore targets until they agro on to it. That is how I do stairs in KS.

If the mobs are behind a wall, try adding them to friend list, bot won't initiate an attack on them but it will defend itself from "friends"

[silinky]

hey i have an idea maybe stupid, but worth to try.

the stucking happens on one waypoint, when the bot keeps switching targets, like forever.
so if a bot stays on a waypoint for too long, without any fighting going on, or damaging anything, just keep moving on. don't care about stuck list or anything. only time passed without any "action".

for me even a function to check this would help, i would integrate it where needed.

an unrelated question, not worth a new thread (although related to this somehow): how do i invoke the ATTACK skill on pullonly? i cannot find it in the skills section, and as usual i am writing from work

hope something helps

[lisa]

well the trouble is that it thinks it is using skills, it only checks targets HP to determine if you haven't done any damage. So you couldn't check if you haven't done anything ina period of time.

As for staying at 1 waypoint for a period of time I actually have a WP I use which has just 1 waypoint, so that wouldn't be that good of a way to deal with the issue.

[silinky]

hmm, yes, my dogmeat script is also 1 waypoint in fact
but this is not a problem since if i stay too long on WP nr 1, and it gets boring, and moves to next waypoint, that is also nr 1 so no biggie for me i guess.

do you have an idea for me to make a function to check the time spent in a WP, and if it is exceeded to move on to the next one? i would include this into the more risky waypoints.

thanks for the input!

[silinky]

ok here's an untested (and probably wrong) function i made, any correction is appreciated

Code: Select all

function timespent(ts_seconds)
	ts_start = os.time()
	while (ts_seconds < os.difftime(os.time(), ts_start)) do
		yrest(1000) -- or some "wait a second" function
	end
	__WPL:setWaypointIndex(nextnumber);
end

how can i find out what the nextnumber is? supposed it is a good approach

[EDIT] ts_seconds is the seconds after which the bot forces itself to the next waypoint not caring if other mobs are near

[lisa]

if you call that function you will do nothing at all for the specified time, so I don't think that is what you want.

[silinky]

another idea

in player.lua at line 806 there is a condition, and in line 811 self:clearTarget(), after this line we could add another condition, set in the profile as an option, to move to next waypoint, if true, after line 811 there would be a command to go to next waypoint. if false, only clear target and target something else.

how does this sound?

[Shogun]

So ideally I think we would need to change the existing ignore mobs system to use a table instead of a single mob. After digging deep into the coding used for the ignore target I have to say it is a big job =(

No, not a big job. There already exists an implementation to ignore the last targeted mob and it's just a couple of lines needed to extend that to a table. I sent the coding to rock about 2 weeks ago. My bot is running fine with the changes.

[silinky]

can you send it to me too?
thx!

[lisa]

So in your table you also took in to concideration

self.Last_ignore_target_ptr (6 occurances in bot)
self.LastTargetPtr (12 occurances in bot )
self.Last_ignore_target_time (8 occurances in bot)

for each ignored mob and removed the mob from the table after a specified amount of time?
If not then it's a bandaid job which will only cause issues in the end.

Or did you simply clear the table after killing a mob successfully, which would of course still try to attack the last ignored mob anyway.

[rock5]

Any idea about seeing how long you spend at a waypoint or making it move to the next waypoint, wont work. Mobs are found while moving too, so if you tell it to break and head to next waypoint, it will reaquire the targets as soon as it starts moving. Only an ignore table will work.

But I've never liked the idea of an ignore table. There have been numerous times I've seen the bot get blocked by a blade of grass or something. Then it moves to the next target, kills that, then goes back and kills the first target. If we use an ignore table, it would miss that first mob.

On the other hand, if I'm making a waypoint file where there are walls, I'll just reduce the MAX_COMBAT_DIST so it doesn't target mobs on the other side of the walls. I prefer this solution.

[Shogun]

silinky, you have pm. I will also send that to lisa.

[silinky]

nice, thx i will integrate into the scripts, and hope it will be included in the next revisions in some form.

my bot (the priest one) met another related error 10 minutes ago on my home pc. it was fighting iron rune warrior boss in ks, and noticed that the fight was taking too long. it hit only with melee attack, and while hitting it, my screen was spammed with the obstacle error... besides the fact that it is stoopid to say that when the mob is 1 foot away from you, it was also kind of annoying because priest with melee attack cannot do very good damage..

i made it step back 1 step and problem was solved. dunno maybe a grain of sand was between the bot and the mob...

can i somehow program this to take a step back when the obstacle message appears on screen?