Jump to content

[patch] flying check in Unit::isInAccessiblePlaceFor


Recommended Posts

Posted

This patch does two things:

  • * corrects spelling of accessible
    * adds a check for flying to Unit::isInAccessiblePlaceFor.
    This makes creatures not chase players (and other creatures) that are flying.

for [10407]: http://gist.github.com/548726

Three issues, need feedback:

  • * since this is called so often, does the pure virtual function call impact performance?
    * should there be a config option to use vmaps for the GetHeight call?
    * ranged attacks should still be used, but aren't (this seems more like a problem in SelectHostileTarget)
Posted

The thing is a lot of times mobs on retail will follow you on the ground and then they'll eventually return home after a certain distance. Unless something is in the way of course.

EDIT: I'm not sure if that's what this does, I didn't check the patch/test it as I'm about to head to bed. Just making sure it gets implemented correctly :)

Posted

In this text, reach means travel to.

Retail monsters will aggro, but then evade immediately if they can't reach the target.

Mangos monsters aggro only if they can reach the target. No aggro means they can't even make ranged attacks.

In order to make it more like retail, I think it would take some rewriting.

Selecting it, reaching it, and attacking it should all be separate steps. Then, if the selected target can't be reached you have to fall back to something else.

Posted

the bone giant guys attack me when i was on his knee, same from the guy at zul drak dont remember the name. i can fly around his chest face etc, is like maybe the size of the guy /3 at that high he attack me something like that.

Posted

Can't help with behaviour on retail...

but you can't seriously be concerned about the overhead of making a function virtual when it calls some of the most expensive core functions ^_^

I have my doubts about adding such expensive checks in this way.

For example, IsInWater() is effectively cached for Players from HandleMovementOpcodes().

But here you will repeat identical vmap queries for every unit that tries to attack the same target.

I think we should start this from the other end, improve movement related code first, cache relevant data and then let AI decide if it can reach a unit or not, otherwise vmap queries will just explode.

For example, won't you get the information as by-product when trying to construct a movement path with mmaps anyway?

Posted
but you can't seriously be concerned about the overhead of making a function virtual when it calls some of the most expensive core functions ^_^

Not concerned exactly, just curious.

I know lots of OOP principles and tons of syntax, but when you really get down to it I'm a C++ novice. I'm here to learn, and the performance impact of calls to a frequently used late bound function is something I want to know. ;)

I have my doubts about adding such expensive checks in this way.

For example, IsInWater() is effectively cached for Players from HandleMovementOpcodes().

But here you will repeat identical vmap queries for every unit that tries to attack the same target.

Honestly, I also had doubts for those same reasons.

I think we should start this from the other end, improve movement related code first, cache relevant data and then let AI decide if it can reach a unit or not, otherwise vmap queries will just explode.

This would definitely be better. I am not very familiar with Player-related movement code, so I can't really contribute to that part of the discussion (yet)

However, I can say that the creature-related movement needs a bit of a re-design (especially to take into consideration mmaps)

For example, won't you get the information as by-product when trying to construct a movement path with mmaps anyway?

mmaps will give this information, but I don'tthink it is the right way to get it. Determining location on the navmesh works in a similar way to vmaps (BSP tree of polygons/triangles), so there is going to be similar performance questions.

Ultimately, I felt that this was a very granular approach to figuring out if something is flying, so it can be used regardless of where or when is used.

  • 3 weeks later...
Posted
The thing is a lot of times mobs on retail will follow you on the ground and then they'll eventually return home after a certain distance. Unless something is in the way of course.

After recent getHeight changes all mobs work in this way. Follow by ground until evade from combat start point distance. So adding above patch it possible will make it work less correctly. Also mobs melee attack flying player if it at attack distance, Ranged attacks also work.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. Privacy Policy Terms of Use