Jump to content

[patch] flying check in Unit::isInAccessiblePlaceFor


Guest faramir118

Recommended Posts

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)
Link to comment
Share on other sites

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 :)

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 3 weeks later...
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.
Link to comment
Share on other sites

×
×
  • 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