Problem - Attempting to pulls mobs that are off mesh.

[rhiza]

Hi guys, im just wondering what is the intended actions if there is a mob within pull radius however there is no mesh that gets to the target?

The area I am in for whatever reason nav thinks the best path to a target is to try run through a wall in an area I just do not want my chars going.

I have tried to remove sections of the mesh which did not work.
I tried to add in NO WALK zones to the tunnels I don't want him going down which did not work.

Reducing pull radius is not really an option as I want the puller to grab mobs from the opposite direction. Is there something in the macro that I can edit that will disregard a mob entirely if there is no path ?

Any help would be greatly appreciated.

 

[gse7en]

It's not a good answer, but for situations like that, do " /plugin mq2nav unload noauto " (no quotes) before running KA on the puller. Beast's Domain and Plane of Shadow are two zones that come to mind that I just have to unload MQ2Nav. If KA doesn't detect MQ2Nav, it will then try to pull using MQ2AdvPath. If neither are loaded, it pulls using old fashioned line of sight. I'm guessing someone has a better answer, but for now, this might get you by.

 

[ctaylor22]

After creating your no walk areas, are you regenerating the Mesh? I do this all the time to restrict my characters from running through areas I don't want them to run through.

 

[rhiza]

After creating your no walk areas, are you regenerating the Mesh? I do this all the time to restrict my characters from running through areas I don't want them to run through.

thanks for the response. i haven't tried that so will give it a jam tonight.

i am still curious as to what the behaviour of KA should be. does it identify a target within pull radius , see its in a no walk zone and then ignore it ? or does it identify target, attempt to move to target until it hits the no walk zone then aborts the pull? .... if that makes sense?

 

[ctaylor22]

Well. What kiss will do is search for mobs based on several factors, primarily being the Maxradius from your camp location. I don't see anywhere where it is checking for a 0 length pathlength. I am not sure what is returned if you try and use the Navigation.PathLength function on a mob in a non meshed area. I would have to try and test it. If you have a chance try targeting a mob that you know is in an area that is not on the mesh and try this. /echo ${Navigation.PathLength[locxyz ${Target.X} ${Target.Y} ${Target.FloorZ}]} and let me know what you find. If that returns 0(zero) it would be easy to add the code to ignore those mobs.

 

[plure]

If you've got the mob targeted, so much easier to type:

/echo ${Navigation.PathLength[target]}

also you can do:

/echo ${Navigation.PathExists[target]}

 

[geEQ]

After creating your no walk areas, are you regenerating the Mesh? I do this all the time to restrict my characters from running through areas I don't want them to run through.

Are there instructions for this somewhere? I would like to try this.

 

[ctaylor22]

Are there instructions for this somewhere? I would like to try this.

This is the best place to start:

https://www.redguides.com/community/threads/42249-MQ2Nav

 

[william12]

look for sub pullvalidate and add

| Check spawn for Pathlength
/if (${Navigation.PathLength[id ${Spawn[${PVPullMob}].ID}]}>${MaxRadius}) {
/return 0
}
/if (!${Navigation.PathExists[id ${Spawn[${PVPullMob}].ID}]}) {
/return 0
}

in there. Tested it and it works. Been using it for months.

 

[ctaylor22]

Will add this check to the findmobstopull routine, so it excludes the mobs from the list and will never have to validate them in the first place... If there is no path to the mob, then why even include them in the list of mobs to pull?

 

[ctaylor22]

I found that the:

/if (${Navigation.PathLength[id ${Spawn[${PVPullMob}].ID}]}>${MaxRadius})

is a tricky one. The mob could be standing right next to you(on the other side of a wall) but the path length could be greater than MaxRadius. So would you want to exclude the mob? Yes that's a question I expect everyone to answer. So don't be shy...

 

[plure]

I found that the:

/if (${Navigation.PathLength[id ${Spawn[${PVPullMob}].ID}]}>${MaxRadius})

is a tricky one. The mob could be standing right next to you(on the other side of a wall) but the path length could be greater than MaxRadius. So would you want to exclude the mob? Yes that's a question I expect everyone to answer. So don't be shy...

I loop through the nearest mobs by actual distance and pull the smallest nav distance. I stop looping once the actual distance becomes greater then smallest nav distance seen so far.

An example:

3 mobs
mob 1, distance = 10, nav distance = 100
mob 2, distance = 12, nav distance = 14
mob 3, distance = 15, nav distance = 20

Mob 1's nav distance is 100. I check the distance for mob 2, it is 12 so I check it's nav distance that is 14. I check the distance for mob 3 that is 15, so I bail and pull mob 2.

This means your always pulling the shortest mq2nav distance.

 

[ctaylor22]

I loop through the nearest mobs by actual distance and pull the smallest nav distance. I stop looping once the actual distance becomes greater then smallest nav distance seen so far.

An example:

3 mobs
mob 1, distance = 10, nav distance = 100
mob 2, distance = 12, nav distance = 14
mob 3, distance = 15, nav distance = 20

Mob 1's nav distance is 100. I check the distance for mob 2, it is 12 so I check it's nav distance that is 14. I check the distance for mob 3 that is 15, so I bail and pull mob 2.

This means your always pulling the shortest mq2nav distance.

That's all good and dandy, but what if the navigation distance is zero(0) because the mob can not be pathed too?

 

[plure]

I check if the path exist with:

${Navigation.PathExists[id ${Spawn[${PVPullMob}].ID}]}

 

[william12]

I found that the:

/if (${Navigation.PathLength[id ${Spawn[${PVPullMob}].ID}]}>${MaxRadius})

is a tricky one. The mob could be standing right next to you(on the other side of a wall) but the path length could be greater than MaxRadius. So would you want to exclude the mob? Yes that's a question I expect everyone to answer. So don't be shy...

You wouldn't want to pull that mob though because there might be mobs between you and him that it should pull first. Pulling based on pathlength is the best way to pull. It should always pull the closest mob to you based on pathlength not radius because radius doesn't know a wall is there.

 

[ctaylor22]

You wouldn't want to pull that mob though because there might be mobs between you and him that it should pull first. Pulling based on pathlength is the best way to pull. It should always pull the closest mob to you based on pathlength not radius because radius doesn't know a wall is there.

Yes. Understood, but would you want to exclude the mob?

If you are going to pull all mobs in MaxRadius, checking so you pull the mob with the shortest Navigation.PathLength first, then moving on to the next closest mob(based on Navigation.PathLength) until you get to the last mob, now the last mob is within MaxRadius of you, but the Navigation.PathLength is greater than MaxRadius, do you want to pull that mob or exclude that mob?

 

[plure]

In my code I use a maxradius to just define the area to pull from. I don't have a maximum mq2nav path length, but you can do your code any way you want.

 

[ctaylor22]

I loop through the nearest mobs by actual distance and pull the smallest nav distance. I stop looping once the actual distance becomes greater then smallest nav distance seen so far.

An example:

3 mobs
mob 1, distance = 10, nav distance = 100
mob 2, distance = 12, nav distance = 14
mob 3, distance = 15, nav distance = 20

Mob 1's nav distance is 100. I check the distance for mob 2, it is 12 so I check it's nav distance that is 14. I check the distance for mob 3 that is 15, so I bail and pull mob 2.

This means your always pulling the shortest mq2nav distance.

Plure, I swear sometimes I can be slow and, miss the most obvious things, but your logic, being ever so simple is ingenious.

When revisiting this thread, I was re-reading the posts, and I am glad I did. I realize in your logic you are using an assumption, but it is a valid one. The assumption is. The mobs Distance(As the crow flies) will always be Less than or equal to the Nav distance. Basically the shortest distance between two objects is a straight line. The Navigation path will rarely be a straight line.

So, if you check the last shortest nav distance against the current mobs distance, and the current mobs distance is greater than that last shortest Nav distance, then your done..

Now here is the kicker, and the part you deserve MUCHO KUDOS for. The mobs have to be in order by Distance(As the crow flies/straight line thing), but that is where ${NearestSpawn[]} comes to the rescue. ${NearestSpawn[]} returns mobs in order by nearest to farthest. This does all the heavy lifting for you.

I know, I know. Plure your probably thinking Duhhh any one should know that. Well I did know it, I just never realized it could be applied in this manner.

So Plure Thank You, Thank You, Thank You. This will make some of the things I have been working on a lot easier..

 

[plure]

Plure, I swear sometimes I can be slow and, miss the most obvious things, but your logic, being ever so simple is ingenious.

When revisiting this thread, I was re-reading the posts, and I am glad I did. I realize in your logic you are using an assumption, but it is a valid one. The assumption is. The mobs Distance(As the crow flies) will always be Less than or equal to the Nav distance. Basically the shortest distance between two objects is a straight line. The Navigation path will rarely be a straight line.

So, if you check the last shortest nav distance against the current mobs distance, and the current mobs distance is greater than that last shortest Nav distance, then your done..

Now here is the kicker, and the part you deserve MUCHO KUDOS for. The mobs have to be in order by Distance(As the crow flies/straight line thing), but that is where ${NearestSpawn[]} comes to the rescue. ${NearestSpawn[]} returns mobs in order by nearest to farthest. This does all the heavy lifting for you.

I know, I know. Plure your probably thinking Duhhh any one should know that. Well I did know it, I just never realized it could be applied in this manner.

So Plure Thank You, Thank You, Thank You. This will make some of the things I have been working on a lot easier..

Np, good luck on updating your pulling code.

 

[rhiza]

just want to say thanks to all in this thread for contributions. i have found the problem i was having with ctaylor22 but learnt a bit from everyone.

cheers!

 

[william12]

Yes. Understood, but would you want to exclude the mob?

If you are going to pull all mobs in MaxRadius, checking so you pull the mob with the shortest Navigation.PathLength first, then moving on to the next closest mob(based on Navigation.PathLength) until you get to the last mob, now the last mob is within MaxRadius of you, but the Navigation.PathLength is greater than MaxRadius, do you want to pull that mob or exclude that mob?

You want to exclude it because if you try and pull him you will leave your radius and kiss will return and do it all over and keep trying over and over to pull it.

 

[aspire2008]

You wouldn't want to pull that mob though because there might be mobs between you and him that it should pull first. Pulling based on pathlength is the best way to pull. It should always pull the closest mob to you based on pathlength not radius because radius doesn't know a wall is there.

This, sorta.

Yes. Understood, but would you want to exclude the mob?

If you are going to pull all mobs in MaxRadius, checking so you pull the mob with the shortest Navigation.PathLength first, then moving on to the next closest mob(based on Navigation.PathLength) until you get to the last mob, now the last mob is within MaxRadius of you, but the Navigation.PathLength is greater than MaxRadius, do you want to pull that mob or exclude that mob?

I would prefer to still pull it if its inside the MaxRadius but on the other side of the wall and 10 locs away, but be one of the last mobs to pull i.e PathLength exceeds length of other mobs near you before you can get to that mob. Didn't user joojoobee solve this issue?


For example, if the mob is on the other side of the wall and 5 locs away, but there are 20 mobs in the way to get to that mob that are closer, I'd want to pull those first.



Also, while we are discussing this there is some guy on the macroquest2 forum that uses a different type of logic on pulling, recent post in last 1-2 months of his pull mac. But his logic uses some type of cone radius pulling. May want to look at that code too.