[discussion] Movement generators - allow real stacking

[Schmoozerd]

Hi all,

-- unfortunately I have atm(before next year) not the time to improve this --

I wrote some changes to MMGens to allow real stacking of MMGens.

http://paste2.org/p/1091266 (lines 1 - 377 are only rename stuff because I changed MMaster from stack to deque)

-- comments about _this_ patch below --

Features:

* better selected return position (depending on the last MMGen with valid position), not the top-most

* Support for having stacked MMGens when evading (this result that it is possible to pause a waypoint-movement with adding an Idle MMGen, and this Idle survives combat.

This has the idea, that we pause not by changeing a flag, or setting a variable, but to just add a new way of movement (could also be random movement)

This also has the effect, that it should be possible to let a mob walk from pointA to pointB, and let him have RandomMovement there (as indeed needed for a few rare occasions (ie Gahz'rilla in ZulFarrak: move out of water, then random movement)

* A function to remove unneeded Idle MMGens (=> unpause movement)

* as this conflicts heavily with the way EventAI handles CombatMovement, I introduced a new var, to define a "combat MMGen" -- and these are the only ones that are removed on evading

This should in the longterm makes it easier to use following MMGens with normal mobs (stacked on ie idle movement)

There is a _bug_ with the return-home position, as this one still depends on the first MMGen, and not on the lastone yielding a position, this is noted as TODO point - infact the patch will be conflicting with current src at this point, but with current code this TODO point is just more important before it can be used. (but should still be rather easy to fix)

I really would appreciate any feedback, I know these MMGens are hard stuff, but the changes shouldn't be too hard to understand

[X-Savior]

This is critical for planned work to complete some Instance Events (Such as Zul'Farrak).

I fully support that this patch please be reviewed in a reasonable amount of time so any changes/fixes can be addressed so we can continue the development of our work in UDB/ACID.

Thank You!

[Schmoozerd]

yes, vladimir already was so very kind to give me a deep feedback

-- see below --

* he pointed to programming weaknesses

* he strongly suggested to first solve the problems with EventAi combat movement handling

* also he provided some other possible ideas to handle MMaster differently

so, in the moment I do

- think about a new MMGen supporting ranged chasing (movement of hunters, casters) (especially to make your life easier )

- having such possibility it should be possible to make EventAi CombatMovement code easier, which then also makes the changes I thought about easier

- explore the idea to provide different stacks (or deques) for different types of MMGens - ie one stack for normal movement, one for combat movement and perhaps another for funny stuff (like transport)

bascily main points here are, that we need to very carefully think of every change as this might have quite impact on speed

in case anyone is intereted about the RangedChaseMMGen:

MMGen providing Min and Max-distance:

if the target is > max-distance, then chase till <= max-distance

if the target is between min and max distance, then don't move

if the target is < min distance, then chase

I suspect that this system will need to trigger two events for CreatureAI, EnemyEnterNear and EnemyEnterRange, which then can be used ie for hunters to equip or unequip a weapon and set phases

Unfortunately implementation of a MMGen is not too easy

-- Status downdate --

It is more than unlikely I will find time for improving the ideas I had here this year, so in case someone want's to do something here, I think it is ok to forward the notes vladimir gave me about my first patch!

Nov 26 07:57:33 <vladimir_afk> [00:29:52] as i read deque isn't safe for elements adding removing applied to iterator invalidation

Nov 26 07:57:33 <vladimir_afk> [00:30:24] in diff from map/set/list it can invalidate (if i remmber right) iterator pointing to different deque element

Nov 26 07:57:33 <vladimir_afk> [00:35:04] maybe this not important for used code, another thing related deque is page increasing way workL so it allocate (in some way similar vector) memory with some blocks

Nov 26 07:57:33 <vladimir_afk> [00:36:19] this can be not effecttive memory use for creature cases that mostly have 1 movegen always

Nov 26 07:57:33 <vladimir_afk> [00:36:47] in past we discuss another way (with small memory increase:

Nov 26 07:57:33 <vladimir_afk> [00:37:08] just fix size movgens stacks to fixed array

Nov 26 07:57:33 <vladimir_afk> [00:38:04] with prioritive increse: 1) for default 2) for script constrolled like quest/escort

Nov 26 07:57:33 <vladimir_afk> [00:38:58] 3) normal fight 4) fear 5) disordered

Nov 26 07:57:33 <vladimir_afk> [00:39:33] maybe 3.5) player control

Nov 26 07:57:33 <vladimir_afk> [00:40:43] then can be lot simplifed control of stack becase will cleary when what can be remove and used

Nov 26 07:57:33 <vladimir_afk> [00:43:28] i not say that last way better, just inform what has been discussed havy in past by devs

Nov 26 07:57:33 <vladimir_afk> [00:45:57] it = begin()++;

Nov 26 07:57:33 <vladimir_afk> [00:46:08] lol, waht you want by this call?

Nov 26 07:57:34 <vladimir_afk> [00:46:46] it will point to "begin()" after, and temp iterator copy with ++ will dropped atfer ;

Nov 26 07:57:34 <vladimir_afk> [00:47:05] so ++ in expression not affect anything

Nov 26 07:57:34 <vladimir_afk> [00:49:24] for (Impl::iterator itr = begin(); itr != end(); itr++)

Nov 26 07:57:34 <vladimir_afk> [00:49:53] never use itr++ in for(), this at least useless way and in some cases more slow way for do same

Nov 26 07:57:34 <vladimir_afk> [00:50:34] let see generic "for ( init; check; step ) body"

Nov 26 07:57:34 <vladimir_afk> [00:51:11] this is same as "init; while(check) { body; step; }"

Nov 26 07:57:34 <vladimir_afk> [00:52:34] in expr itr++ post=increment make sense _only_ if exprasion result used: itr++ == { Iter temp = itr; ++itr; return temp} "

Nov 26 07:57:34 <vladimir_afk> [00:53:10] so in case "itr++;" as it used in for(), it just more slow version of ++itr

Nov 26 07:57:34 <vladimir_afk> [00:54:00] i agree that EventAI idle use is just too hackish

Nov 26 07:57:34 <vladimir_afk> [00:54:41] maybe we must just have 2 chase movegen version, and maybe adding its as first step can cleanup code: for melee attack and for ranged attack

Nov 26 07:57:34 <vladimir_afk> [00:55:06] ranged version just must attemp preserve distance in some range

Nov 26 07:57:34 <vladimir_afk> [00:55:53] like follow wihtout angle but witj min dist

Nov 26 07:57:34 <vladimir_afk> [00:56:38] then in eventai we can just replace movegens for current mode, this can simplify eventAi code also

Nov 26 07:57:34 <vladimir_afk> [00:59:08] les clear part: if allow melee/ranged movegens auto switched with some infor about ranged attack possibility can let drop horibale multi-command used way as this done in ACID, X can happy from it lot ^^

[kyle1]

Thank you for your work. Once again you're fixing stuff I'm interested in Playerbot mod will greatly benefit if you implement RangedChaseMMGen, cos right now there is no clean way to make ranged combat bots to follow their targets.

[darkstalker]

you can do ranged chasing via scripts, but would be nice if the core handled it for you

[VladimirMangos]

- explore the idea to provide different stacks (or deques) for different types of MMGens - ie one stack for normal movement, one for combat movement and perhaps another for funny stuff (like transport)

Just clarify: i not meaning array of stacks of movegens. I not see where this can be need...

I think more simple fixed size movgen pointers array can work fine. Don't known cases when similar type (same priority) movement can be need stacked instead replaced. In array we have have specialized slots for default movegent (or idle), scripted activated for long time (for escort/long walking case), fighting chase (including ranged if will created), confused, fear slots, short movement (knock, etc)

Each slot expect have single movgen that prio (like current way work) above all < slots or NULL if this type movgens not active.