endless loop if 2 mobs infront behind a barrier

[Micke]

if this happens, my char is staying infront of the wall and is playing tennis :

mob1: attacking, couldnt cast , cancel
oh found another mob
mob2: attacking, couldnt cast , cancel
oh found another mob
mob1 .....

message in the game: "there is a barrier between u and the target"
- any ideas to avoid this ?

to bad that we cant ask the client whether target is visible or not

[rock5]

If they are behind a wall usually you would adjust the waypoints so they are not so close to the wall or temporarily adjust MAX_TARGET_DIST so it doesn't target mobs on the other side of the wall.

This should be fixed and a few ideas have been put forward, it just hasn't been fixed yet. The way I see it being fixed is, every time it fails to damage a mob it adds it to an ignore list. When it finally does damage a mob it clears the ignore list. I don't want to leave mobs on the ignore list longer because sometimes mobs move and become attackable so this way it will have the chance to try again if they are still in range.

[Micke]

better waypoints, of course ^^, but in my case the bot magically finds a way to this "bad" mob, through the chain of mobs

if u are looking for a betatester, give me a sign ^^

was my first thought too, to manage the ignorelist this way, maybe some modification - u could save the mob_id with the coordinates as combined key in this list. it wont harm the intension to recognize moving mobs, but it avoids useless tries to attack the mob at same bad Position.

but i dont know how much performance u have to pay for such a more complex search in lua

and iam not sure how to manage the case, if the mob can be attacked from other waypoint. by trend i would ignore the mob , cause if we loot at this "bad" Position, we will have again problems

[lisa]

yep had many posts about this now, trouble is that it's not just when you have a wall between you and the mobs. You could have a small rock and the game will say there is an obstruction but if you move slightly or mob moves slightly you can then kill it.

So adding more and more mobs to an ignore list isn't really going to do what you think it will.

Better waypoint creation is the way to go.
There are many KS scripts that manage this, there is also the killzone if you have rooms or walls to deal with.
There are many ways to deal with situations where you regularly have issues of not being able to attack a mob.

[rock5]

Still I think my idea is worth doing. It wouldn't be the most ideal solution but it would save you from getting permanently stuck and save you having to fiddle with your waypoint or muck around with killzones. Of course if waypoint speed is an issue you will want to "fiddle with your waypoint or muck around with killzones" but if speed is not an issue then my solution will handle it.

[Micke]

hi lisa,
the problem is similar to situation when bot cant reach the next waypoint, then he plays with some fallback strategies to solve this.
in worst case bot log off, but thats a solution.

with the 2 mobs behind a barrier we have only a endless Loop at non predictable cases, no way out

[Jandrana]

I know that with other scripts using the EventMonitor system it is possible to retrieve the messages printed on the screen. I'm asking myself, if it is not possible to get this information when fighting mobs. This would also speed up detecting the casting failures.

[rock5]

The event monitor uses RoMScripts which are relatively slow, too slow for combat. If we could get the messages directly from memory, that would be another story, but I've never been able to.

[lisa]

System messages are pretty much the only way you would be able to do it.

I spent many many hours testing on this subject and I can say for a fact the out of range and obstruction things come from serverside.

I deliberately caused a lot of server lag to the point that another character would look like it was directly in front of me but a buff skill would post the message out of range. So there won't be any part of memory client side that we would be able to read in order to work out if we can actually hit a target or not.

[rock5]

Which brings us back to the tried and true method of trying for a bit and then giving up if we don't do damage.

Which reminds me, I should do that ignore list now that I've committed my previous changes.

[rock5]

Ok I did the ignore list code and tested it around the outside of the limo room. It works the way it's supposed to but it does take a long time to finally give up on each mob. It wont be much of an issue if there are only 2 or 3 mobs to ignore but it's still a long time.

So I reconsidered the eventmonitor idea. If we use it cleverly then it shouldn't impact performance. I was thinking start the event monitor at the start of the fight then only check it if it fails to cast. It checks the last message only and if it's the "There is an obstacle between you and you target" then it immediately quits the fight and adds the mob to the ignore list. How does that sound?

Edit: I just had an idea. I should add a distance check to when it clears the ignore list. So if it hasn't moved far when it finally kills a mob then it wont clear the list until it moves further away.

[rock5]

Try these 2 files out.

• -- Includes an ignore list that clears when you kill a mob if more than 50 away from the last ignore.
  -- Includes monitor for "There is an obstacle between you and you target" so it disengages after the first failed cast. I don't know if we will need to add support for other messages or not.

[rock5]

I still want to hear how these files worked but I'm thinking they still need more work. Firstly it should also check the system message if it can't damage the target during battle (after aggroing the target) so it steps back more quickly. Also there are other reasons for not being able to target a mob eg. "Must face target". So I'm thinking a general function that is called whenever it fails to cast and checks for different messages and act accordingly.

I had a lie down to think about this some more and it occurred to me that maybe we should have an eventmonitor running all the time for warning and alert messages. It could be used for anything. If you just did an action and want to see if it cause a warning, then just check.

As the eventmonitor is written now, it will accumulate messages in it's log if not cleared. I think what we need is specific code in the ingamefunctions addon that always keeps just the last warning and alert message. It would always be running so you wouldn't have to start it, and at anytime, in your code, you could do something like

Code: Select all

Do some action or command
msg= GetWarningMessage(5) -- 5 means ignore message if older than 5s
if msg and msg == "what you are expecting" then
    react to message
end

Now I'm thinking, "do we want to automatically clear the message when it's checked?". I'm thinking what if the bot gets the chance to check the messages before you can? Then the message you were expecting would be gone. I'm thinking the addon should always hold the last message, only overwriting it with new messages. So how do we avoid acting on the same message twice? We could have it return the time along with the message. That way if it has a different time then it's a different message.

How does that sound?

[lisa]

Looks like I am the only one to d/l those files so far, I haven't done any fighting yet though, just been working on my buff thingy.

Sounds like it is going to get complicated though.

[rock5]

But what do you think of the idea of being able to check for system warning/alert messages any time, simply? I'm quite excited by it. And once I implement that, it will actually make the check for the obstacle message easier.

[Jandrana]

But what do you think of the idea of being able to check for system warning/alert messages any time, simply? I'm quite excited by it. And once I implement that, it will actually make the check for the obstacle message easier.

Looks good in my opinion. Perhaps we can group events message in different categories:

fighting category: -> obstacle, must face target, out of range, out of ammo, being stunned/rooted, skill cooldown..
inventory: -> backpack full (when looting, completing quests)
quest: -> quest completed
general: -> phirius shell limit reached, public event started,...

So if we the bot will provide handlers for certain categories this would allow a complete different style how to write scripts which would allow to create scripts that look less bottish.

[rock5]

It's a good idea except, like I said before, checking the event monitor is relatively slow so should only be used where no other solution is possible. Most of what you mentioned is already handled by the bot by reading values directly from memory which is the fastest way to do it.

rooted/stunned sounds interesting. Do you get a rooted/stunned message if you try to use a skill when rooted/stunned?

[Jandrana]

Do you get a rooted/stunned message if you try to use a skill when rooted/stunned?

There is a red message, when you try to use a skill while being stunned. But I can't remember what it is. Maybe something simple like: "You cannot do that" or similar.

[lisa]

Try these 2 files out.

• -- Includes an ignore list that clears when you kill a mob if more than 50 away from the last ignore.
  -- Includes monitor for "There is an obstacle between you and you target" so it disengages after the first failed cast. I don't know if we will need to add support for other messages or not.

I accidently commited these to rev 749, hope they work

[rock5]

As is, they work and shouldn't cause any problems but they still needed more work to be optimal. And of course I have plans to make it a lot better with other messages monitored and using the general purpose warning/alert message system.

How do you accidentally commit files while at the same time add a comment saying you accidentally added them? Do you know a way to edit a comment after committing the files?