Water Detection Patch

[Derision]

Originally Posted by fathernitwit

So, I am gunna post the major things and have hope that you can clean it up so we can get it in.

I'll clean it up as you suggested, probably at the weekend.

The BSP tree is equivalent in function to the 'Nodes' quadtree in the normal map files, i.e. it subdivides the zone into boxes, however the water map files contain only the BSP tree with the leaf nodes marked if they are water/lava, there is no 'face' information in there, so you couldn't use it for LOS, or BestZ.


I'm sure a single map could be created that could be used for Water/LOS/BestZ, but it's not something I personally feel motivated to look into


I'll get back to you when I have had a chance to do the other cleanup work.

[narcberry]

Why do it as a tree? Wouldn't it be much faster to hold the water/lava data as a 3d matrix that is quickly addressable by map position (each matrix entry representing a block of size x)? You should be able to entirely avoid the tree traversal that way. It should also reduce the size of your data (but just slightly).

Sorry if I misunderstand the problem.

[Derision]

Originally Posted by narcberry

Why do it as a tree? Wouldn't it be much faster to hold the water/lava data as a 3d matrix that is quickly addressable by map position (each matrix entry representing a block of size x)? You should be able to entirely avoid the tree traversal that way. It should also reduce the size of your data (but just slightly).

Sorry if I misunderstand the problem.

This is how the EQ zone geometry is stored in the zone S3D files that come with the client. You sound like you know a lot more about 3D geometry than me, but there is an article over at Wikipedia explaining why BSP trees are used in 3D games (more for rendering and stuff):

http://en.wikipedia.org/wiki/Binary_space_partitioning

I just extracted the relevant bits of data in the same tree format it was organised in the zone files. I'm sure it could be optimised just for the purposes of water detection, but once I get something that 'works' for me, my interest kinda stops there

[narcberry]

If I sounded smart, I had you fooled.

I don't think that BSP trees are the best data model for lava and water since we aren't trying to reduce the computation time of transforming from 3d space to 2d space. We just want to check an attribute of any specific point in 3d space. But I struggle with BSP trees, so maybe I'm just wrong. To me, it begs the question, "why did SOE use BSP trees for their water and lava?" Maybe it's a good way to go, I just think a 3d matrix is simpler and faster since you can check for lava or water without any traversals or transforms.

Maybe I should be quiet since, admittedly, I have 0 BSP experience other than that wiki you linked me (thanks).

[Derision]

Originally Posted by narcberry

I don't think that BSP trees are the best data model for lava and water ...

Well, my thinking is that the client has to traverse the BSP tree when it renders the graphics, checks for collision detecion, Line of sight to mobs etc, so it is no extra overhead 'for the client' to check for water/lava, since it has already traversed the tree to the leaf node for those purposes.

Now, maybe/quite possibly the SOE *servers* have a different, more efficient mechanism for water detection, perhaps 3D Matrices as you suggest, but we can't know, (unless any ex-SOE programmer's who are reading this would like to add something )

[narcberry]

Originally Posted by Derision

Well, my thinking is that the client has to traverse the BSP tree when it renders the graphics, checks for collision detecion, Line of sight to mobs etc, so it is no extra overhead 'for the client' to check for water/lava, since it has already traversed the tree to the leaf node for those purposes.

That makes sense.

[Derision]

I PM'ed FNW details of the reworked patch for this along the lines he asked for, but I don't think he's been around for the last week, so I will post it here as well in case anyone
else wants to test the updated version.

----------------------------------------

I reworked the Water Detection patch. Diffs against the 1070 source are at:

http://www.rama.demon.co.uk/Reworked-water.patch

It affects these files

entwisd@rama ~/EQEmu-0.7.0-1070 $ patch -p0 < /tmp/Reworked-water.patch
patching file ./common/ruletypes.h
patching file ./utils/azone/Makefile
patching file ./utils/azone/awater.cpp
patching file ./utils/azone/awater.h
patching file ./utils/azone/wld.c
patching file ./utils/azone/wld.h
patching file ./zone/command.cpp
patching file ./zone/forage.cpp
patching file ./zone/makefile.common
patching file ./zone/mob.cpp
patching file ./zone/mob.h
patching file ./zone/watermap.cpp
patching file ./zone/watermap.h
patching file ./zone/waypoints.cpp
patching file ./zone/zone.cpp
patching file ./zone/zone.h

And adds these rules:

+RULE_BOOL ( Watermap, CheckWaypointsInWaterWhenLoading, false ) // Does not apply BestZ as waypoints are loaded if they are in water
+RULE_BOOL ( Watermap, CheckForWaterAtWaypoints, false) 		// Check if a mob has moved into/out of water when at waypoints and sets flymode
+RULE_BOOL ( Watermap, CheckForWaterWhenMoving, false)		// Checks if a mob has moved into/out of water each time it's loc is recalculated
+RULE_BOOL ( Watermap, CheckForWaterOnSendTo, false)		// Checks if a mob has moved into/out of water on SendTo
+RULE_BOOL ( Watermap, CheckForWaterWhenFishing, false)		// Only lets a player fish near water (if a water map exists for the zone)
+RULE_REAL ( Watermap, FishingRodLength, 30)			// How far in front of player water must be for fishing to work
+RULE_REAL ( Watermap, FishingLineLength, 40)			// If water is more than this far below the player, it is considered too far to fish

I thought about adding a test in zone.cpp so that if none of the rules where true, it wouldn't
try and load the water map, but I didn't do that.

Originally I only had the water detection in waypoints.cpp in CalcPosition2 and UpdateWaypoint, however
while I was reworking it, I also put it in the other places BestZ is calculated.

This caused an issue in the SendTo routine. What my code does is turn flymode 1 on when a mob is in water to
stop it sinking to the floor.

It appears the SendTo routine can be (always is) called before the spawn packet has been removed from the
queue and sent to the clients. In this case, the client ignores the flymode packet because the mob doesn't
exist for it yet.

This causes problems because all the water checks assume that if the mob has remained in water since the
last check, that the flymode 1 has already been put on the mob. This is so that unnecessary appearance packets aren't sent to the clients.

I therefore don't attempt to set flymode or set the mob's inWater flag in SendTo.

The other bug I noticed while reworking this is that the DeltaZ
in the spawn update packet is being ignored. I.e. if you watch the mobs pathing in water, they always
move horizontally and then jump up or down when they get to their waypoint (or when another position update packet is sent).

I don't know whether this is a side effect of flymode 1, or whether it's something else, e.g. maybe the offset
for DeltaZ in the spawn struct is not correct and it's something that is only noticeable in water. I
only have the 6.2 client so don't know if it works differently with Titanium. Whatever the problem is,
I couldn't find a way around it.