Hey. Good work on this, I know a lot of people have been waiting for this one.
I want to get this put into the code base, but I dont want to commit it in its current form, as its a bit too messy. I had hoped that I would be able to find the time to clean it up myself, but it dosent seem to be happening. So, I am gunna post the major things and have hope that you can clean it up so we can get it in.
First of all, I dont really like the way it is integrated with the existing LOS code. At first, I thought it was extending the existing stuff to add water detection. Not until I read the apathing stuff did it become clear that this is a completely seperate system. So the #1 most important thing to me is to break all the code apart.
The changes to azone are really completely seperate except that they use some of the same library code. I would like to see a seperate tool built for it in order to make this clear. In order to not duplicate code, either just make a new target (awater) in the azone makefiles or just make a "library.cpp" and "library.c" file, and #include "../azone/blah.cpp" all the files into the appropriate extension library file (its ghetto, but it works). Split all your code over into awater.cpp and off we go with that one.
Then we get into zone, where we have the same issue, but things are a bit easier since we all link together. Instead of tapping off the existing Map object, it needs to be an entirely seperate object. WaterMap would be fine. Just follow the leader the way Map was done.
Now, on to actual code. The number one concern I have again is performance. All of the checks for water need to be conditionalied on at least two rules (no, I dont like using the presence of the water file as the toggle). Minimum is "water for fishing" and "water for pathing". I would love to see the same sort of price/performance tradeoffs which were present in the BestZ code made for the water code, where a server op can choose to only check at waypoints or on a slow timer or something as opposed to checking continuously as each mob moves. The position code just gets called way too often for big servers to use it.
For future reference (will go away when you split from Map anyhow), void* bad... avoid at all costs.
Minor but important code quality thing. When you are using constant value numbers to mean things, like your RegionType field, you should use an enum (but leave the region field in the ZBSP_Node struct as a long).
Code:
typedef enum {
RegionTypeNormal = 0,
RegionTypeWater = 1,
RegionTypeLava = 2
} WaterRegionType;
And thus we arrive at the final and big question. One concern I have here is that we are loading up an entire copy of the zone geometry (at least I assume the BSP tree closely resembles the geometry in complexity). I cant say that there is any other good way to accomplish it for sure, but I wanted to raise the topic for conversation. If there is any way to combine this with the LOS data to reduce the amount of crap people need to load into ram, it would be a good thing.
-FNW
Hybrid Mode
