faramir118

http://www.wowwiki.com/Threat

Your current working directory is wrong, try cd %wowInstallLoc% %dbcmapExt%

DestinationHolder::UpdateTraveller() eventually calls relocate, so the positions are good. One case where the creature will be between two path points is when their speed changes. The path will still be valid, we just have to recalculate dist to the next node in order to update travel time.

I'm just slow, I'll get to it! Thanks, will do these easy fixes. Just in case findNearestPoly (in BuildFreshPath) returns a polygon that doesn't contain the destination position. We can probably prevent this by tweaking the extents (they are arbitrary numbers right now). For cases where the monster is between two path nodes. I can't point out one scenario where it happens, but I was planning to put the travel time calculation back into SendMonsterMoveByPath, and it should make sure that the first spline's length is accounted for. Also, we know that the path nodes sent are [startIndex ... endIndex] but the travel time is [startIndex-1 ... endIndex] - others may use the SendMonsterMoveByPath function in some other part of mangos and not realize it. Abstraction is good in this case! Good point. I'll change it back without waiting for TOM_RUS... The client expects FLYING or CATMULLROM splines in a specific format, so they should always be sent that way.

Most of them are in already. I'll add the others soon.

Fixed issues: * In SendMonsterMoveByPath, mid point was being calculated with first path node instead of current location. Fixing this made the function a lot more predictable, easier to use, and fixed monster speed (I think... these things don't come with handy speedometers) * The difference between the previous and current GetClosePoint causing the path to be recalculated. Always call setEndPosition() in PathInfo::Update() Might be hacky, could have some unknown consequences... New issues: * If monster speed changes after the path is sent, things get really messy. Client-side, monster kind of stops, then disappears, then reappears, etc. We probably need to check for speed changes in TargetedMovementGenerator functions, and force a resend with updated travel time. Overloading MovementGenerator::unitSpeedChanged() might be necessary - can't send path from there though, because it is called for inactive movement generators. * With smooth paths, monsters overshoot the corners. This can be seen easily with the new .debug mmap path. This should be a simple thing to fix, I just haven't looked at the findSmoothPath function. I had a lot of debug output in there - if you see any I forgot to remove, please let me know. edit: forgot to mention that I didn't include the most recent additions from qsa (Waypoint and flying stuff)

Found a bug at the last minute, been trying to find/fix it. I found one for sure, just not sure if it's what was causing the problem... Good news is that I enhanced the .debug mmap path command - it now places a marker at each point along the path!

Tank skill, gear, talent build, and fight mechanics are big variables in the threat/second equation. You may be comparing apples to oranges. However, I do know that there are some DK spells that don't work right.

Hm, recast doesn't have this built in. Instead, it only builds polygons which have a specified vertical clearance above them. I suppose it could be done with some modifications, as it might allow for easier 3D navigation (flying and swimming). I'll add it to the end of the list No, I think it was caused when GetClosePoint selects a point that doesn't lie on/near the path due to obstacles. As the monster follows the path, GetClosePoint eventually picks a point that is nearer to the path, but far enough from the old dest point that targetMoved is set to true. A good example is the last room in scarlet monastery armory - the initiates all recalculate their path when they circle around the player to get to the stairs in the back of the room. Setting the destination point to the target's actual location will provide a better result. This would require that the PathInfo class handle angle and offset values, instead of TargetedMovementGenerator. Do you think this kind of change is worth it? I also did a bit of testing with ACE_High_Res_Timer, with smooth paths, on a 2.4 ghz core 2 duo. Most of the time it was less than 300 microseconds to build a path, but I saw a few around 600. Updates that didn't require changing the poly or point path were 2-3 microseconds. @qsa I've made some changes to your code... * clarified that m_pointPathPointer is an index to the point currently being travelled to, it should be >= 1 * set m_type in BuildPath * changed path send algorithm in TargetedMovemengGenerator, a bit simpler * in SendMonsterMoveByPath, check unit flags to determine if unit is on a taxi (instead of splines) I'll push the changes when I wake up in the morning..

Just finishing up implementing the smooth path patch on my repo. I noticed some recalculations in TargetedMovementGenerator::_setTargetLocation() due to GetContactPoint()/GetClosePoint() changing the destination position. Probably something we want to handle better, maybe set the endPosition equal to the target creature's exact location, then stop short?

An example is the best answer: Bob is a melee-only creature. Bob enters combat. If Bob cannot reach a target, it is not an attackable target. Bob must evade+reset when he has no attackable targets. The evasion code is tied to aggro, in Unit::selectHostileTarget() By the time Bob MovementGenerator is active, we are already finished with selectHostileTarget() and can't see if another target on the threat list is reachable if there is no path (and can't enter evade mode if there are no reachable targets).

Someone suggested this (it was many pages back, sorry for not giving credit): When a monster aggros, mangos core finds and aggros all nearby creatures. Tie into that mechanism, and generate a path for all of them at once. Just some things to look out for: * Need to check the filter that was applied to the path, just in case a walking-only creature is grouped with a swimming creature. * Need to copy path, not use the same one. This should reduce the number of paths that need to be generated, is selective, and means we don't have to create a cache/pool mechanism.

This touches on another subject: The aggro logic will need to be able to create paths, select a complete one, then store it where the movement generator can access it: * Store the path in Unit class (easy way) * Store the path in a PathPool class Creatures could ask the PathPool for a path to their target. The PathPool could check to see if a path has already been found which has similar start and end locations, modify it with prefix/suffix heuristics, and return it. If no suitable path exists, PathPool just builds one from scratch. This would work very efficiently in a lot of cases - in most instances monsters are in a tight group (similar start position) going toward the tank (exact same end position). I had come to the same conclusion, but wanted to leave options open if we can't solve this issue at mmap generation: How do you make it so that recast doesn't see a door as an immutable obstacle? Perhaps flag all triangles that it touches, then remove the door? Other cases will be simple, like the bridge in Gundrak - just flag the walkable surfaces like normal. And currently there are only 6 bits of area flags to work with (for the input mesh). We can safely increase this, generator only uses 40mB on average.

We can know the path type using just the poly path... it can go wherever, just makes more sense (to me) to update type as soon as the path has changed. Also, I think setting type should be this: if (polyPath.lastPoly == endPoly) pathType = PATHFIND_NORMAL; // path is complete else if (polyPath.Length == MAX_PATH_LENGTH || queriedNodes == MESH_MAX_NODES) pathType = PATHFIND_INCOMPLETE; // path is assumed to be incomplete else pathType = PATHFIND_NOPATH; // path doesn't reach dest, search didn't exeed limits => definite fail Without knowing if the A* open set reached MESH_MAX_NODES limit, we can't determine for sure if there is no path. However, I don't think it's is possible without some modifications to detour. Nice find! If we ever handle runtime navmesh modification, we will already be making sure we're not traversing parts of the mesh that have changed. We should also overload isPointInPolyBounds() so that we re-use the tile and poly from getPathPolyByPosition(). re: SendMonsterMoveByPath You or someone should submit this as a patch separately. Probably need to come up with a better/cleaner way to handle movespeed and travel time calculation though.

Made a few revisions to qsa's first contribution, please check them over and give me some feedback. In the meantime I'll work on adding the new stuff!

Nice work, this is promising. I would think that there is a better way to build a smooth path... those intervals are so inefficient. Just two things: * What are you using Recast.h for? * It's coerce

This is a lot of good work. I'm going to commit these changes, probably broken into smaller pieces. RE: suffix optimization There are some circumstances where the destination isn't just a small detour from the old path, like teleportation or jumping over gaps/ledges. In these cases, keeping the previous polyRefs could slow down findStraightPath, maybe even create a bad detour in the path. I can't think of a good way to detect this kind of thing, and I don't know how often it happens. Thoughts?

Does it compile without Recast? Recast isn't necessary for core, and isn't used on Win32 edit: pushed a detour-only version of the above, please test

Added what I hope is a working automake config for Detour. Can gcc users please test?

392 is still the most recent: http://unifieddb.svn.sourceforge.net/

Merged with 10434

vmaps are not related to movement

Not concerned exactly, just curious. I know lots of OOP principles and tons of syntax, but when you really get down to it I'm a C++ novice. I'm here to learn, and the performance impact of calls to a frequently used late bound function is something I want to know. Honestly, I also had doubts for those same reasons. This would definitely be better. I am not very familiar with Player-related movement code, so I can't really contribute to that part of the discussion (yet) However, I can say that the creature-related movement needs a bit of a re-design (especially to take into consideration mmaps) mmaps will give this information, but I don'tthink it is the right way to get it. Determining location on the navmesh works in a similar way to vmaps (BSP tree of polygons/triangles), so there is going to be similar performance questions. Ultimately, I felt that this was a very granular approach to figuring out if something is flying, so it can be used regardless of where or when is used.

The lawsuit talks a lot about the TOS and EULA, and makes the argument that clicking the Accept button makes it an enforceable contract. It would have been interesting to see it play out in court, instead of a default judgement.

On retail, tall monsters definitely attack you from the ground. (like this guy, or these things) Can anyone confirm that normal sized creatures do attack you if you're flying, but not out of reach?