Experimental Code: Stop mobs hopping when pathing - FindBestZ tweaks

[moydock]

Working great, only problem i've noticed is when a mob goes up a steep hill or maybe it's just a certain change in his z coordinate, he goes under the world. However he does pop back up after a couple seconds. Still a huge improvement.

I may have not set it up right though, not exactly sure what the 'rule system' is.

[Zandig]

Originally Posted by moydock

I may have not set it up right though, not exactly sure what the 'rule system' is.

It has to be set up in the database.

Here is how I have mine set up (working very well):

rule_sets


rule_values


Thats all there is to it!

[moydock]

Sweet thanks, got it working, still seeing them go under when climbing steep hills. Not sure if that's fixable. I haven't upgraded to the newest build though, didn't see any fixes in the log. Btw do you know what the Map:FixPathingZatWaypoints is for?

[Derision]

Originally Posted by moydock

still seeing them go under when climbing steep hills. Not sure if that's fixable.

I've seen this happen in Dreadlands where one waypoint is on one side of a large mountain
and the next waypoint is on the other side. The movement code plots a vector between the
two waypoints which goes right through the middle of the mountain (under the world).

The BestZ code as currently implemented takes the mobs current Z position and looks downward to find the ground. If the mob is already under the world, it will either do nothing, or in the worst case, e.g. Dreadlands, which for some reason has an invisible 'floor' under the world at Z=-210, it will push the mob even further down.

I just made a quick hack to the code to make the BestZ code look up instead of down, and in the
case of the particular mob I was looking at in Dreadlands which pathed over a steep hill, it seemed
to have the desired effect of stopping it going under the world, i.e. if it was under the world, it pushed
it back up to the ground level.

The next step is to have the code look up AND down and decide which direction to push the mob.

I don't have a lot of time to play with this much at the moment, but if I find something which seems
to work reliably, I'll post a further patch.

[Derision]

Originally Posted by moydock

still seeing them go under when climbing steep hills. Not sure if that's fixable.

If you're using the PEQ Ykesha DB could you give me some test cases of mobs that path under the world, i.e. which zone they are in, then target them and do #npcstats and #wpinfo and give me the NPCID and Grid number ?

[moydock]

Originally Posted by Derision

If you're using the PEQ Ykesha DB could you give me some test cases of mobs that path under the world, i.e. which zone they are in, then target them and do #npcstats and #wpinfo and give me the NPCID and Grid number ?

I'm actually using a custom db so no help there. But I can tell you this, there seems to be a height which they reach, and they always go through the hill at that height. It also seems to be the height they would normally 'hop' up to before the fix. I'm guessing this point is the z coord of the WP they're headed to.

So what if you forced the z coord of the waypoint a mob is headed to always be the highest point in the zone. Then they wouldn't go through hills and the z-fix already in place would keep them on the ground. Would that work?

[Derision]

Originally Posted by moydock

So what if you forced the z coord of the waypoint a mob is headed to always be the highest point in the zone. Then they wouldn't go through hills and the z-fix already in place would keep them on the ground. Would that work?

The first problem I see with that is zones with multiple ground levels, e.g. dungeons, or Kelethin, with the city in the trees.

The code does already try and compensate for a small movement under the ground. If it can't find a BestZ on the first attempt, it bumps the mob up by 10 Z units and tries again.

The amount it tries to move the mob up on the second attempt (10 units) is not currently configurable by the rules system. I'll see if tuning this number (increasing it) helps with the steep hill problem. This would be a less CPU intensive solution then my previous thought, and if it works, we could make this a configurable parameter in the rules system.

[Angelox]

This is a great Improvement over what we had -
It always seemed to me there were much more "hoppers" when the grids were packet spawned, than when I laid them out my self.
On thing still remains, is the water hoppers - a good example is in Dagnor's Cauldron, where there are many surface swimmers, all will bounce up and down constantly.
If you go to the small isle in the middle, you can follow the roamers into the water and watch them hop