faramir118

I would be surprised if the dual spec thread DIDN'T show up when I used the search feature.

Those debuffs have a separate ICD for each person attacking the victim. This functionality isn't in mangos. Yet.

No apologies necessary. Discussion is open to all! The logic for grounded mobs will probably take a few tries to get right, but it seems doable at this point. Clamping them to the navMesh would be fast and easy, and we can make sure that mobs are confined to the path polygons. This would prevent them from walking up into the air or off cliff edges. Flying mobs will be easier, there are fewer checks that need to be made. It will be interesting to see that in action though, because they'll fly towards the ground, behave like someone that's walking, and then fly back up once they've gotten around the obstacle. Who knows, it may be better to just let flying monsters continue to go through obstacles? The cliff scenario may have been the wrong one to post There are other scenario's that are worse, like a player being thrown into the air. There's a chance findNearestPoly returns a polygon in a room above the current floor or something, so we'll waste CPU cycles finding a path there, and then waste even more cycles when the mob realizes that the player is still in the room. So, it's risky. And because it's CPU intensive itself, I'd like to use findNearestPoly only when we have no other way of finding out where something is on the navMesh. And having a delay during that initial evasive period seems beyond the scope of pathfinding... sorry

Oops! Must have fat-fingered my calculator. hunuza is right, its 12 bits for tileID and 10 for polyID. Is that better or worse than before? Seems that for most maps it wouldn't matter, but maps that have a lot of floors may have a lot of polygons?

No, haven't altered any sql. I can't think of any reason that we'd ever need to either!

Sorry, another long post... I think I figured it out. Each dtPolyRef is 32 bits, and is broken down into three parts * salt: 10+ bits Used to determine if the mesh has been altered, as in an obstacle has been added or removed. If salt changes, you should probably recalculate your path. * tileID: 1+bits The identity number of the tile that this polygon belongs to. * polyID: 1+ bits The identity number of this polygon. Now, the maps have been broken up into grids already: * 64x64 array, or 4096 cells * each grid cell is 533.333333f wide, 533.333333f deep edit: read hunuza's post below, I'm bad at math and calculators if you want to match the navmesh tiles to a map grid, then we'll need 4096 tiles, which means 2^11 bits for tileID. This leaves 2^11 bits for polyID, allowing 4096 polygons per tile. s = salt bit, t = tile bit, p = poly bit, spaces just make it easier to read/count (note: actual encoding might be different, I just am making an example) ssss ssss sstt tttt tttt tppp pppp pppp \\ 10 bits /\\ 11 bits /\\ 11 bits / \\4096 tiles/ \\4096polys/ It will be interesting to see if 4096 polygons is sufficient for all tiles. Since the loading and unloading of grids is already done, you would just need to add the tile loading code to what already exists for grids. Then as mangos loads grids, tiles are loaded into the navmesh for us. When (if) a grid is unloaded, mangos unloads the tile also. I don't think it would be terribly CPU intensive, but there would be some disk IO involved that would make it slow. It is a concern, but I don't see a way around it at the moment. I've done a bit of digging in the detour code... * findNearestPoly looks at every single polygon in the tile, and returns the nearest one even if the position isn't inside that polygon. waste of CPU when I only care about the polygons in the path 'nearest' polygon is risky, for instance if player jumps off a cliff it might to return the cliff edge and not the polygon player will land on * findStraightPath gives shortest path, in coordinates assumes that the path is reachable from startPos and endPos * moveAlongPathCorridor gives next coordinate on the path that is reachable from startPos, as well as which polygon that coordinate is on returns nearest point on portal edge, so path will be longer than it needs to be * distancePtPolyEdgesSqr returns true if a point lies within a polygon (ignores up/down, so point can be above/below polygon) Two ways to avoid findNearestPoly: * If I can get the right results from moveAlongPathCorridor, great! * If not, I'm prepared to write some code that uses distanctPtPolyEdgesSqr to find if the start and end polygon are on the previously-calculated path, then use findStraightPath to get the next coordinate to travel to As for progress, I've just been working on abstracting the pathfinding code. A peek at my changes: // change to class so it goes on the heap class PathInfo; // moved to make more abstract/convenient PathInfo* WorldObject::GetPathTo(WorldObject* targetObject); PathInfo* WorldObject::GetPathTo(float x, float y, float z); void WorldObject::UpdatePath(PathInfo* path); // easier to implement/read code void TargetedMovementGeneratorMedium<T,D>::_setTargetLocation(T &owner) { ... i_path = owner->UpdatePath(i_path); float x, y, z; i_path.GetNextPosition(x, y, z); i_destinationHolder.SetDestination(x, y, z); ... } Been a busy week, and my weekend will be as well. As soon as I get some free time, I'll write up something nice and make a new thread!

The comments for Call Stabled Pet say that its cooldown is reset whenever you change specs - should add that functionality to your patch, or make a note and wait for dual spec?

At this point, yes. Granted that someone is playing in the one small area that has the navmesh. We're still working on it, so there will be a lot of performance improvements to come. What docs are you talking about? All I have been able to find is the comments in the headers, and a few comments in the code. This creates a problem, because I was using findNearestPoly to determine whether or not they had left the previously-calculated path - buffering ruins that. I can work on finding a less-expensive way, but I think it will require storing a few additional things in the PathInfo. Once we settle on something that is fast, we'll definitely need to optimize memory usage. Right now, our memory usage for PathInfo: * 204 bytes for path (208 on x64) * 4 bytes for path length * 4 bytes for current index * 12 bytes for positions (start, end, next dest) * 4 bytes for navMesh pointer (8 on x64) TODO: * convert to dynamic memory allocation for the path, we'll save a lot of space. I'm terrible at this, will need some help * convert path length to unsigned char, that's still plenty long * get rid of current index, it's not being used right now Yes, we should I need to read the code to fully understand what he was saying in his response. From just his response, this is what I understand: larger tiles => more polygons per tile => need more space in polyRef for poly id number => less space available in polyRef for tile id number => fewer possible tiles (because you reduce the number of available ID numbers) or: smaller tiles => less polygons per tile => need less space in polyRef for poly id number => more space available in polyRef for tile id number => more possible tiles I don't know how his code handles this, will have to look at it.

I don't have a lot of time at the moment, so this will be relatively short. All the work I did was to optimize the pathfinding. My goal was to reuse a path as often as we could, so that we don't have to generate them that often. See Map::UpdatePath for the specifics. There should be plenty of comments. First, the code. This is a patch for mangos commit 9638. (also works for 9648) You need the mmap created by Gotisch. Easiest place to test it is at the house near this guy. My tests were thorough, but I can't promise that this is stable. Next, the results. If these videos look choppy, please don't worry about it being the pathfinding. I've got 2 instances of WoW, MySQL, mangos, 2 instances of visual studio, camtasia capture, and some other crap open. On a laptop. (At the time of posting, the videos are still being processed by youtube) * Short video where you can see the pathfinding in action. * A little more involved, just showing off. A good start, but there's more to be done: * Testing! * HomeMovementGenerator seems to pause for a second on some of the path vertices, definitely needs looked at. * Could really do with some memory management. I'm really not that good at dynamic memory, or C++ for that matter. * More abstraction. I feel that we can get it to the point where a MovementGenerator makes one call to get the next destination's x,y,z * A few comments in the code have some ideas, just can't remember them. * Other stuff

First, I'm just going to suggest we move this to a new thread. The original topic is a few years old, and I feel we've departed from the original spirit, seeing as Gotisch is using recast+detour. Would be easier to explain what this does, what we want it to do, track progress on a todo list, and keep a link to current versions of code and/or mmaps. Anyway, on to constructive discussion: You'll have to check to make sure you're only removing the ground that's under the water, and not ground that is on a lower floor. Take dalaran for instance: there is water on the top floor, but walkable floors below it. And way below that (but maybe not in same grid?) there's the surface of northrend. The implementation of the pathfinding using detour is more important - if it's done poorly, there won't be a point to even create navmeshes with recast because people won't want slow, inefficient, or crappy pathfinding! Don't worry though, there are ways to fix it. We just have to tweak recast navmesh creation parameters. * agent step height Defines the height of objects that agents are allowed to step up to. This will be tricky to get right, should be about the same as player jump height * navmesh height above the terrain mesh Would allow mobs to ignore low obstacles like rocks, logs, fences, etc. Short doorways might become impassable, would have to tweak agent height to compensate. On the other hand, it might make agents ignore objects that they shouldn't I vote no, until MaNGOS has a built in thread pool. Read on if you want to know why. There are two ways to handle multi threading: * block on a synchronized object until the pathfinding thread signals * makes debugging harder A crash in one thread may be caused by another thread, which is hard to track down * offers no performance benefit You suspend one thread and start another. This takes just as long as if you had done it in the current thread (technically it can take longer because of thread priority scheduling, context changes, etc) * defining a callback function for the pathfinding thread to call * makes debugging harder Same as above * only offers performance benefits if you have a multiprocessor system, and only if you execute the callback function on a thread other than the pathfinding thread (unless all threads are part of the thread pool) * complicates code it is hard to correctly implement (preventing concurrent access, avoiding/detecting deadlock and race conditions, etc)

Can you get the water surface polygons? It would be awesome if you could flag them (with rcPolyMesh.flags) so that we have an easy way of finding fishable water, for instance.

I've thought it over, and this is the best I can come up with for the pathing algorithm: * Create Map::findPath(source, destination), should return entire path * Create Map::findStraightPath(path), should pull string * Current path stored in TargetedMovementGeneratorMedium * i_DestinationHolder stores current destination node So, pseudo code for what TargetedMovementGeneratorMedium<T,D>::_setTargetLocation(T &owner) would do: if (path) // path exists because _setTargetLocation is being called from Update source = path.EndNode destination = target.position path.append( Map::findPath(source, destination) ) else // path does not exist, start from scratch source = owner.position destination = target.position path = Map::findPath(source, destination) if(!path) // need to handle case where path doesn't exist // clean up and shorten path, set destination Map::findStraightPath(path) i_destinationHolder.SetDestination( traveller(owner), path.StartNode ) I would really like to see this in action, I just don't have the resources to bring up a test server at the moment. As for pathing between Tiles, a TiledNavMesh would work. I haven't looked at how the path is formed with Tile links, and I'm concerned that the link itself is used as a node in the path. This would create some very awkward paths. For the above reason, I am favoring overlapping tiles. This forces you to keep track of which Tile your path is for (and paves the way for one mmap per dungeons instead of one mmap per instance). You can add logic to setTargetLocation to detect when you have moved into a new mmap, and start a new path with new data. Potential pitfalls: * A too-small overlap will limit the distance creatures can path. This can manifest in a few different ways: * creature may not see a path to the character at all, such as when the stairs up to the character are just across the tile boundary. * overlap is small and players are moving fast, player might move out of overlap area before creature enters it - creature won't be able to find path to player * A too-large overlap will waste resources. Some potential distances are Aggro range, creature follow range, update interval * max player speed In any case, I think dungeons should be one big Tile.

I would store the path in the unit. When it needs to recalculate because target moved, do pathfinding from the end of the previous path, add new path on to the end of previous path, then call dtNavMesh::findStraightPath(). This should be faster, because the new path is most often going to be a very short, straight line. findStraightPath will then straighten out the path, removing any excess nodes. Worst case would be teleporting mobs, like Arugal in Shadowfang Keep - you would lose a bit of performance, because you generate a whole new path, then findStraightPath has even more work to do. Try these: * dtNavMesh::connectExtLinks() * dtNavMesh::connectIntLinks() I don't know about maps or vmaps, but if nobody replies we can use: * dtNavMesh::connectExtOffMeshLinks() * dtNavMesh::connectIntOffMeshLinks()

Updated original post. Added it back in, BUT: How do you know it wants the additional byte after actual data? Is that information correct for client 3.2 and later? Anyway, until now we were sending 3 bytes fewer than the client needed to even display correct information, and it still worked. It's not a big deal, but I don't think sending that last byte matters.

Didn't seem to change behavior with or without it. Also, http://www.wowwiki.com/API_COMBAT_LOG_EVENT indicates that only source, target, spell, amount, overheal, absorb, and critical are needed on the client. If there's a reason it SHOULD be there, I can add it back in. Thank you! I couldn't find a spell with the heal-absorb effect. I'll start working on implementing it.

3.2 added: * heal absorb effects * new field for combat log heal events to handle heal absorb This patch implements both. patch for rev. 9559: http://pastebin.com/raw.php?i=xB17iiTf Examples of spells this handles: * Incinerate Flesh * Necrotic Strike Example of combat log with patch: Testadin's Necrotic Strike hits Testadin for 3587 Physical. Testadin's Flash of Light heals Testadin for 0.(1737 Absorbed) Testadin's Flash of Light heals Testadin for 0.(1730 Absorbed) Testadin's Flash of Light heals Testadin for 0.(1718 Absorbed) Testadin's Flash of Light heals Testadin for 0.(1736 Absorbed) Testadin's Flash of Light heals Testadin for 0.(1750 Absorbed) Testadin gains 92 Mana from Testadin's Illumination. Testadin's Flash of Light heals Testadin for 0.(2655 Absorbed) (Critical) Testadin gains 92 Mana from Testadin's Illumination. Testadin's Flash of Light heals Testadin for 0.(2644 Absorbed) (Critical) Testadin gains 92 Mana from Testadin's Illumination. Testadin's Necrotic Strike dissipates from Testadin. Testadin's Flash of Light heals Testadin for 1523.(1030 Absorbed) (Critical) Testadin's Flash of Light heals Testadin for 1736. Testadin's Flash of Light heals Testadin for 134.(1683 Overhealed)