faramir118

For qsa's way: update cycle 1: Creature::Update() Unit::Update() MotionMaster::UpdateMotion() MovementGenerator::Update() (1) evadeWhenCan() (call stack eventually goes back to Creature::Update) unit is not evading yet, so UpdateAI() SelectHostileTarget (*) pick new target using pathfinding, set evadeWhenCan to false (*) AttackStart() (*) MotionMaster.MoveChase() update cycle 2: Creature::Update() Unit::Update() (2) m_evadeWhenCan is true, so CreatureAI::EnterEvadeMode() nothing else matters, we are in evade mode (new MovementGenerator, leave combat, etc) The stuff with (*) is not implemented yet. Without it, everything between (1) and (2) is guaranteed to not matter (except if creature dies to aura damage). So it can be made to work, but only if you generate and validate paths in SelectHostileTarget - this is functionally the same as what I proposed. However: From a design-oriented viewpoint, I feel that deciding to enter evade mode should solely be the responsibility of AI. Evade mode has a lot of implications besides just movement. MovementGenerator should only generate movement. It is a more logical separation of functionality, IMHO. This is easy, just store path in Unit instead of MovementGenerator. I don't know how often this will actually happen... In most cases, players are solo and monsters will just reset (or attack the pet if there is one). In raids, players are always right in the fight. I can't think of any realistic scenarios where more than one or two extra paths will need to be generated. Is it big enough problem to base design decisions on? As a proof of concept, your implementation works well. I have no problem adding it as long as there are concrete plans for an agreed-upon, proper implementation!

I see two Report links on each post.

Go with the custom MovementGenerator. Random calls to StopMoving and SendMonsterMove mess with the improved SendMonsterMoveByPath function in mmaps.

I think we should plan this all now, so that everybody is on the same page. This is going to be a long post. Current mangos implementation updates MovementGenerator before it calls SelectHostileTarget: Creature::Update() Unit::Update() process events (might die here, damage aura or something) MotionMaster::UpdateMotion() active MovementGenerator::Update() (1) if (not evading) UpdateAI() Unit::SelectHostileTarget() (2) Calling evade at (1) means we don't properly look for other attackable targets, because it prevents the AI from updating. Currently, mangos master calls evade at (2), only when it has targets but can't attack them (for example, mob that can't swim vs player that is in water). IMHO, it should happen the other way around - SelectHostileTarget before MovementGenerator::Update. This is how I think it should work, and has been my long-term plan for a while: Creature::Update() if (not evading) UpdateAI() Unit::SelectHostileTarget() (3) Unit::isInAccessiblePlaceFor() verify target is reachable with pathfinding Unit::Update() process events (might die here, damage aura or something) MotionMaster::UpdateMotion() active MovementGenerator::Update() Now evade is only called from (3). We are always giving Creatures a chance to pick a target (ie, not forcing them to evade when they have other options). This can be optimized a bit by moving the event processing into Creature::Update. That way if the creature dies from an event, we don't waste cpu cycles finding a path to something the creature won't get to attack. My rationale (and other random stuff) about why this way is good: Creature::Update() no longer wastes an update on the wrong target when it should have switched due to threat/taunt/death/whatever. bonus bug fix We can guarantee that we evade only if there are 0 reachable targets (reachable is an ugly word, thanks to ranged attacks and spells - not a huge problem, just something to be aware of) As Schmoozerd said, we can add a param to SelectHostileTarget for ignoring pathfinding. This will help ensure that bosses don't reset due to a faulty navmesh or something. Could also help with maps that have problems, like SFK's spiral staircase. For 100% retail behavior, where monster follows for a while before evading: SelectHostileTarget should save the best target, regardless of reachability If it doesn't find a reachable target, it should move toward the best target and start the evade timer if it later finds a reachable target, it should reset the evade timer if the evade timer reaches 0, evade (duh) Feedback (or criticism) welcome!

Still not much time to fully test, working on other stuff. I have concerns about evading from within movement generators: Alice(player) attacks Eve(monster), does some damage Bob(player) stands somewhere Eve can't go, like on a roof Bob uses ranged taunt on Eve Eve paths to Bob, stops at end of path Eve can't reach Bob, so evade timer is started Bob randed attacks Eve, and Alice melee attacks Eve Eve either evades due to evade timer, or dies from players attacking Eve's movement generators has no way to know she can attack Alice instead Some other changes look good, but separating them is slow.

You can try this. Reference: wowdev wiki I can't test it, because I don't have the destructible GO patch. If it works, Lynx can make it work well. I will probably play around with this stuff for mmaps, because these invisible models will most likely interfere with pathfinding...

Only if you apply the patch yourself.

See this commit.

Spawned GOs aren't part of the vmap, so there is nothing to collide with below the monsters.

Wild Quiver works for me at [10584] with a clean core. You can try something like http://gist.github.com/616013 to see what spells are being blocked by server-side gcd.

No, I apparently didn't read that closely. That part is already in FeatherFall, but still needs to be added to druid flight form and probably flying mounts.

You need that snippet for when auras are removed, not applied. Safe-fall type of auras can use it, plus druid flight form also.

Busy with work and class, but I'll look at the diff and merge it as soon as I get an opportunity! edit: I started work on WMO liquids, but got extremely sidetracked. Managed to figure out how to find auras that liquids should apply, but it only works for ADT liquids (aka liquid from .map, not from .vmap): Wintergrasp Water for Lake Wintergrasp Magma for Obsidian Sanctuary If anyone wants to take this up as a separate core mod, I can start another thread with the relevant details and hand it off so I don't get distracted anymore

Any chance you are able to dump some of my recent PMs and send them to me?

http://www.worldofwarcraft.com/moltencore/

lazy compiler... try this: m_pathPointsSent = std::min(uint32(10), uint32(pointPath.size() - startIndex));

Well I figured out why the monster wanders around on the ledge when you are in a place it can't walk to - the path returned by Detour does not include the destination point - it stops at the nearest reachable location. You can see this easily with [.debug mmap path] when you are standing in a location that the monster can't reach. Static analysis of findStraightPath tells me that it's always supposed to include the destination at the end of the path... Am I way off base, or is this not the way I had it working before? I'm confused...

Also updated to master [10553]

updated repo with qsa's changes

The second error is intentional until we complete the aggro part. In cases of no complete path to the target, we can easily prevent the monster from moving all the way to the target - just omit the last point on the path. But then the monster would move to the end of its path, but not reach the target. This could be exploited by ranged classes, so for now I just made monsters move through walls rather than stand still and die. The first error is a puzzle. Path length has a hard limit... I don't know how it possibly got over that limit.

Miscellaneous places that probably need pathfinding: * Spell::EffectCharge * Spell::EffectCharge2 * PointMovementGenerator * FleeingMovementGenerator (replace the 'primitive pathfinding') * Creature::IsOutOfThreatArea (not sure if it is retail-like) * Unit::isInAccessiblePlaceFor (for detecting impeding terrain) * AssistDelayEvent::Execute (to generate one path for a group of creatures at aggro)

Pushed qsa's changes, as well as a couple of my own. Please review, especially commit e793aec3

Mangos isn't parallelization friendly, so I don't think it would scale any better on a PS3 than it would on an i7.

I agree with Lynx, we would just be fixing a display bug. There are other things missing that affect real threat, which unfortunately just have to be searched for and fixed individually. Tedious work!

I made a few changes to handle the movespeed changes. Might need some improvements, but for now it's handling things well. Also moved SendMonsterMoveByPath out of the Unit header. Got really tired of recompiling everything because I added or changed some debug output in that function.