What makes NPCs randomly be "underground"?

So I’m curious why an NPC will randomly be “underground” when I start the server but other times they’re fine.

For example, Officer Brady who patrols around Stormwind. Sometimes when I start the server he is walking normally. Other times when I start the server he’s in the ground up to his knees and even a few times he’s been all the way up to his waist.

If I’m using the same core, the same maps and the same vmaps, why would the pathing functions seemingly return different values from one session to the next (no, I didn’t actually debug this)? It seems reasonable that if you always read in the same value from maps and vmaps that the calculations should also always be the same.

It doesn’t seem to be a waypoint problem because when this happens he’s “broken” for every waypoint on the path until I restart the server.

Note: This is without mmaps

what about with mmaps ?

I haven’t used mmaps in a long time but I can say I don’t remember it happening in the past when I did use them.

It’s really strange because it doesn’t appear to be a waypoint problem, like when a waypoint is in the wrong place and an NPC will bounce up and down. In my example above, he walked through the Dwarven District in the ground up to his knees but when I restarted the server he was fine.

Does the client have anything to do with pathing? Does it possibly save paths in a WDB file for quicker retrieval? I know it saves things like NPC names and other stuff that doesn’t change often.

WDB is template data. Why would paths be saved there? And no. paths and actions are server side in scripts.

I don’t know, that’s why I asked.

At any rate, it seems strange that the pathing functions would calculate different heights for the same input data (eg: if on Monday the result height is 28 then on Tuesday it shouldn’t be 27). If this were a waypoint issue it would make sense but the entire path seems to be modified by something causing the lower height for the whole path.

Imprecision, such as using integers to calculate floats, is the likely culprit, that, and race conditions causing some calculations to finish ahead of others, and be calculated in the wrong order, or something.

Try with mmaps enabled and see what happens

Yes, I was thinking about float vs int being a possibility. I hadn’t considered race conditions though.

I stopped using mmaps when I realized creatures couldn’t jump over fences. My mmaps are so old now I need to extract new ones which takes too long for my liking.

I don’t remember this issue happening with mmaps but since they had other issues I don’t see the benefit yet.

From expirence, there was a period of time where the vmap extractor map height had issues due to some cleanup commit which I can’t remember off the top of my head, it is likely the bug still exists today (though not certain as i have not checked).

A good way to check that i’ve noticed is it occurrs on only this section of blades edge bridge.

http://i.imgur.com/nc26XB1.png

If you .gps, if the bug still exists in today’s trinitycore you’ll notice FloorZ is considerably lower than your position Z.

Also, there is an unrelated comparison bug in Map::GetHeight which i’ve noticed to be the cause of several cases of serverside pathing to path to the wrong Z position.

http://i.imgur.com/aho4ptQ.png

Pretty sure I’ve fixed other similar bugs in the past, but can’t remember anymore, sorry.

OK, we need ideas, anyone have idea of how to make map-extractor to remove the zones marked on red without having to need a super computer cluster? :slight_smile:

http://i.imgur.com/oDu2kw1.png

it’s more a matter of improving the function above than changing data

@Aokromes do you mean during the generation process or during subsequent evaluations?

IMHO on generation process.