Experimental Code: Stop mobs hopping when pathing - FindBestZ tweaks

[Derision]

Originally Posted by cavedude

As for mobs in the water... there currently is no way for us to tell where water exists in the map.

I spent a couple of days working on the water detection and it's looking good (albeit frustrating
at times working with the WLD data!).

I modified Azone to build the BSP tree from the 0x21 fragment as well as process the 0x22 and 0x29 region
fragments. I then wrote a function which given hard-coded X,Y,Z co-ordinates would walk the BSP tree to
the leaf node those co-ordinates are in and return whether or not the co-ordinates are in a special region (water, lava).

I then transplanted the code into Daeken's Openeq (aka freaku) source so I could fly around
zones and test it better with a visual on-screen indication of whether the code thought I was under water.
It seems to work well (I would say flawlessly, but it needs more testing).

Next step is to optimise it/tidy up the code , mod azone to write out a 'water map' file and then put some code
into EQEmu to make use of it. This could be used for fishing quite easily by projecting forward and down from
the player and testing whether the hypothetical end of the fishing line is under water.

One thing I noticed is that although some zone files have the 'special regions' flagged as either water
or lava, some don't, so I will probably have to make azone accept another parameter telling it whether
to mark the regions as water or lava by default if there is no indication in the WLD file of what the region
is.

I have only tested zones in S3d format so far, so I don't know whether this can be adapted to work with newer zones in EQG format.

[Derision]

Well, the creation of the 'water maps' by azone and the processing of them in the emulator is done. I modified the existing #bestz command to tell you whether the code thinks you are in water/lava or nowhere special (on the ground) for debugging purposes:

Ground


Water



Lava



I modified waypoints.cpp to not use BestZ when the mobs where in water or headed to a point in water, but they are still hopping in the Cauldron. Not sure why that is, but I will look into further to see whether it is fixable in code.

If it isn't, I'll post what I've done anyway, as I'm sure it will come in handy for fishing at least!

[cavedude]

I've been waiting for this for ages, top notch work!

[Derision]

Originally Posted by Angelox

Cavedude had mentioned one temporary solution was to give the swimmers the levitation spell - This keeps them steady at what ever grid they are on.

I only just realised what a problem pathing in water was, even without the BestZ code. I.e. the client appears to make all the mobs sink to the bottom of the water. You can see this in powater at -232.25,-699.5,-98.125 ... mobs being put in a particular spot by the server, then sinking, and then popping up again when the server sends the next movement update.

I added an extra field to the Mob class, inWater, initialised to false. In the waypoint movement routine, I put a check to see if the mob is underwater and it wasn't previosly (Mob->inWater==false). If this is the case, it puts flymode 1 on the mob and sets Mob->inWater=true.

Likewise if the mob is not in water when it was on the last check, it turns the flymode off.

This seems to help in Powater and Kedge. The mobs hop once after the zone is loaded until they pass through the waypoint routine the first time, and then they swim as they should without the client making them sink. It won't help with static mobs which aren't on grids. They will just spawn and fall to the bottom and stay there. I guess I could put some code in the NPC spawn routine to check if they are in water and turn the flymode 1 on at that point. This would work for the static spawns and stop the initial hop for the wanderers.

I don't know whether there is any downside to doing this. Needs more testing. I wonder how the live servers handle it?

[Derision]

I had a PM about when I am going to release these changes I have been working on. I will put something out this week. It may not be in a form that is ready for merging into CVS, but at least it will give people who are interested a chance to test the changes and report on any issues etc.

[KLS]

If a solution like this were to come into usage I think we'd need to inevitably figure out how to create a water map from an .EQG file too.

[moydock]

Not sure if this has been fixed since build 1070 but my mobs still go under the world when trying to go through a hill, the hill can be little more than a bump too. What i've found is if you give precise waypoints, that only take him on a straight line, polygon to polygon, he will never go under the world. They can climb giant mountains like this without falling under the world. Is there a way a mob could calculate this himself when he sees there's a mountain in his way?

[Derision]

Originally Posted by moydock

My mobs still go under the world when trying to go through a hill, the hill can be little more than a bump too. What i've found is if you give precise waypoints, that only take him on a straight line, polygon to polygon, he will never go under the world.

The issue with some zones is that the Verant/SOE designers put in a base ground mesh and then put mountains on top of that, so if a waypoint sends a mob under the ground, the BestZ code looks down and sees the lower ground level under the mountain and sends the mob down there.

I had experimented with further fixes to the BestZ code to look up and down and decide which was the more likely ground level the mob should be it, but it was getting messy, so I stopped work on that.

The tool I am currently working on it plots the paths between waypoints, looks for collisions and inserts extra waypoints to avoid the collisions. In very uneven terrain, it will put an extra waypoint on both edges of a polygon to lead the mob safetly across it. It also inserts extra waypoints to keep the mob close to the ground and not attempt to path through the air.

This is done 'offline' to reduce the overhead at runtime, however a grid that has, say 20 waypoints, can easily turn into one that has 200+ when processed like this, so there is extra overhead for the server in terms of extra memory to store the waypoints and CPU to process them, although I can't really quantify the latter.


It is really only designed for auto-fixing outdoor paths at the moment, but I haven't got an ETA as yet as although it fixes paths well in a lot of cases, there are still some cases where I set it off fixing a zone and it will find some unhandled set of geometry conditions or a bug where it gets into a loop. The job is then to analyse the set of conditions that causes that and put in logic to either to be able to fix that waypoint or to safetly exit the auto-fix routine to tell the user he will have to manually insert waypoints to get around it.

[moydock]

Great to hear man, this would be wonderful for designing new content. My #1 headache is waypoints. Don't give up! Don't let the hills win! <3

[Derision]

Originally Posted by moydock

Don't give up! Don't let the hills win! <3

I've not given up, although there have been frustrating days that I wanted to, in fact I have worked on this every day for almost a month, often in work, when there is a quiet moment. It's taking
a lot longer than I thought, especially the outdoor auto-fix features which I am a concentrating most on. It's largely a case of one step forward, two steps back, although I am slowly
getting there. I've had to make a couple of mods to azone to fix some issues with the map files, and also to the LineIntersectsFace/Zone functions to cater for intersections right on the edge of a polygon (I've learned a LOT about 3D geometry doing this ... I didn't know what a Normal vector was a month ago )

I think I made a bit of a breakthrough today with a (on the face of it) reliable method of detecting if a point
is 'under the world', rather than just underground, based on the algorithm used for back-face culling. I am hoping this may lead to a reduction in the number of waypoints that need to be inserted
to make the path follow the ground, but I need to try this out next week.

Forgive the rambling, all I wanted to say was I am still on the case, but still no ETA (still several weeks off). What I will say is you will need Python/pygame installed to
use this (because OpenEQ uses those for it's UI, and I kept it, because although I didn't know Python, it was easier than building a new UI from scratch), and also you will
need to build new MAP files with a patched version of azone (I posted in the Development/Bugs section about one of the fixes required about a month ago, but there is one
more azone patch required that I haven't got around to posting yet).

For what it's worth, here's some current screenshots:



I added a mode to display the polys instead of textures:



And also an overhead view: