How ignore works

[MiesterMan]

Naturally, though I've seen many posts about this in the past, I couldn't search for them to find if there was already a solution.

The case is where you're grinding in a tight spot but there are two mobs near each other and both are the best targets in range. The bot alternates between them and continues to do so indefinately because they are behind a wall (lol).

Ok, my idea was to change the way ignore works. That is to say, to make the list longer but not such that it's a huge problem where we aggro hordes of mobs we ignored.

Instead of just remembering the pointer (I don't know how ignore works but I imagine it's something like that) you could remember the position of the player and the position of the mobs and have them stored in a short table. If the player and the target haven't moved, then it will continue to be ignored. I further suggest that the required move distance of either the target or the player be at least half the distance between them (I'm not sure why, there's some mathematical concept I'm forgetting applies to this).

Now I do know the reccomended solution in the past has always been "just change the target distance for these waypoints" but that's a lot of maintenence that I don't think should be necessary. The bot should be at least this smart, rather.

Just my opinion though, if someone else can think of something easier, please do post.

[lisa]

Ultimately the best would be to get an indicator of when you can't hit target. there has to be something that tells server you can't hit target. Now I think on it the server probably uses the coords of player and target and sees if the line is dicrupted by an object. Or maybe the check is done on client side and not serverside.
I seem to remember something about models and if you remove a model for something then you no longer have the line of site issue from that object anymore, so it would have to be client side.
Needs testing.


As for the recording locations of player and target and if in those positions again then to ignore, really nore sure it is best way to go. The table created would become huge as you keep botting and more and more locations of not being able to hit target are added. Then doing calculations of distance for every location compared to current location, it would exponentially (bad speller) get worse and worse.

[MiesterMan]

Origionally I was thinking this table would be cleared after each waypoint is reached but now that you mention it, that would add a lot of times where you still waste time not shooting through walls.

How about a table that records ignore position for "after each waypoint" then we'll know again if we run into the same places for the next iteration of the waypoint not to bother trying to shoot from point A to point B.

The targetting system and skills system do a lot of distance calcs already so I'm not sure how much that would slow them down. Now if we were just making a larger and larger list and comparing every position to it, that would definately slow it down, but that's why we have the deviation. Maybe half the distance between is too much but I'm sure we can come up with a fast enough calc to make this work.

if (x1-x2 < 50) and (z1-z2 < 50) and (y1-y2 < 50) then pos1 is the same as pos2 end;

Or we could reduce the deviation even more and go with rounded numbers. Just devide everything by 10 and truncate it then compare using ==, that should be fast enough. Really though I feel there should be a bit more intelligence behind the bot mechanic for ignoring though. At the very least it should be able to get from waypoint to waypoint without nitpicking the targeting distance.

I can't remember the removing object thing either. I tested it in the past but it's been a while. The problem is that would only be viable in a dungeon and this issue crops up in world waypoint files quite often.

[lisa]

I can't remember the removing object thing either. I tested it in the past but it's been a while. The problem is that would only be viable in a dungeon and this issue crops up in world waypoint files quite often.

The importance is if it is client side then there must be an indication to tell the server you can't attack. If the decision is made serverside then it will be very hard to find such an indicator.

So if it is client side then things are looking easier, easier then impossible lol

[rock5]

I think you are describing 2 different issues.
1. It gets stuck alternating between 2 differnt unattackable targets.
2. You want it to "learn" which targets are unattackable so it doesn't attack them in the future.

1. Needs a fix.
2. I think is too complex to do and probably would adversly affect the bots performance.

My idea for fixing 1. is to have an ignore list with time of ignore. So after a period of time the ignored addresses are removed from the list.

[lisa]

I think you are describing 2 different issues.

My idea to fix both issues was to detect if you can actually attack the target, I know it seems mythical but there must be something to tell server/client that you can't actually hit the target, if we found an indicator for that then it would solve both issues in 1 go.

[rock5]

Personally I don't think there is an indicator. I think it is calculated as needed. So when you try to attack a mob it calculates if you can see it or not, at that time, then attacks if you can.

[MiesterMan]

I think what lisa means is that there might be some value in the game that we can look at that will tell us if it can be attacked. Like, the current status of our current target has 'these' flags. That would be ideal and very efficient. If both of your ideas could be used that would be perfect.

I'd reccomend instead of the timing thing to use a waypoint, never know how much combat you'll run into in varying waypoints. After each waypoint is reached we'd wipe the slate so if we did round the corner, we'll try again. But that's only if there is an efficient method to detect these issues like the one suggested by lisa. Otherwise, with the current ignore method, timing would be a good choice (since it would prevent multiple instances of the same failed combat attempts in a short time).

I've never looked at the target info and though I can imagine what the rendering info looks like I wouldn't know where to start looking to find these so I'm kinda lost on is lisa, sorry.

[lisa]

if you do a search for
SYS_CASTSPELL_TARGET_COLLISION
in CE and you will get 1 address, do a find what accesses this address debugger.

Each time you cast a spell watch it,
if you can hit target there is no change,
if you can't hit target the numbers go up by 7, well they did for mage spells anyway.

It only does it for when you get the obstruction error on screen. I figure it might be a function for checking if obstructed or not, or might just simply be the text it has to show on screen.
A bit like our language file with
[41] = "Failed to read memory"

--=== confirmed ===--

It is just the text to display, I replaced it with NOP at 0x0072AB00 and I no longer get the message on screen but I still can't attack through obstacles, of course.
If we could tell when the address is accessed though then we would know if we can't hit target, no idea how to do that though.

Looks like this anyway.

[MiesterMan]

Not sure about those procs but sounds like you might have found an iterator value. In LOTRO I found an iterator value for the mouse that continuously incremented when the mouse was in motion. I assumed that was some sort of record of mouse activity and was generally useless.

If you're sure that the number you're looking at only increments when the collision name is accessed it could be a very good indicator. Might even be able to find something like this for other warning messages.

[rock5]

If it does increment then we could use it. Just check it before attacking and then after. Even better would be to know what message it is because it might be possible that it increments for any system message.

[lisa]

I probably didn't explain myself properly, nothing new lol

Ok so at address 0x***** there is a text value of
SYS_CASTSPELL_TARGET_COLLISION
This is like our language files
[41] = "Failed to read memory"

but in this case it is
SYS_CASTSPELL_TARGET_COLLISION = "There is an obstruction between you and your target."

When I do a what accesses this address the number of times it is accessed in the debugger goes up when I try to use as skill and I get the system message that says "There is an obstruction between you and your target."

The part of memory that accesses is probably a function but I don't understand how to convert memory code in to the actual function code and you probably can't. Anyway so this function checks if it can use the skill or not and if it can't it then prints to screen the value of SYS_CASTSPELL_TARGET_COLLISION


So there is no actual counter going up in memory but we can see when the part of memory that has SYS_CASTSPELL_TARGET_COLLISION is being accessed via the CE debugger.

So if we could work a way into MM for checking when a an address is being accessed just like CE does then we could easily make use of this.

As to how to make MM check when an address is being accessed I would have absolutely no idea lol

So yes the Debugger count only goes up when you try to use a skill and server won't let you attack target because it has decided there is an obstruction because that is the only time the part of memory which is the error message is accessed.

a bit like

Code: Select all

errormessage = "We are not mounted"

if not player.Mounted then 
print(errormessage)
end

So the only time the part of memory with "We are not mounted" is accessed is when the print is done.