cyberium

Yes i talk for the second point. This point is important for the choice of new target. Must be done as fast as possible. Here is my plan, current victim reachability will be tested by GetMotionMaster()->IsReacheable(spell/melee). If not reacheable second way will be used to find new target without create his path (this will be done in other part of the code (StartAttack))

It make sense Faramir. For caching purpose, here is my point of view. ThreatManager of one creature need to know every update what Unit is reacheable or not. By spell or melee. It's not acceptable to make PathFinding every update. This will take too much cpu. What choice we have? - Verify if Unit (victim) have moved enought from the last PathFinding before calculate new one. - Keep any result of PathFinding from creature to any victim in a tab for determined time. Creature can not be realy to far from their last point after 500ms. - Combine two above point? Important for pathfinding is to know if path is created completly to access victim for Spell or Melee. Kind of test like actual unit method CanReachWithMeleeAttack() and add CanReachWithSpellAttack().

Thanks for your answear. Is this mean i cannot check if there is path juste after something like m_creature->GetMotionMaster()->MoveChase(m_creature->getVictim()); if (!m_creature->GetMotionMaster()->IsReacheable()) { // Do something } Because MoveChase is threaded?

humm iam not sure it's same function.

@Faramir or Qsa, or anyone else can help. Hi Thank you Faramir for your link http://www.parashift.com/c++-faq-lite/const-correctness.html#faq-18.13 Iam trying to understaind it. There is some other point iam trying to understaind. Ex: why we can't use GetMotionMaster()->operator->()->IsReachable() in CreatureEventAI class? Or add method like bool IsReacheable() { return top() ? top()->IsReachable() : false; } to MotionMaster is not possible? Olso what do you think about caching system of path? In TargetedMovementGeneratorMedium::_setTargetLocation() add table of i_path for all generated target and check if one exist before calculate it. All path generated will have like 500 ms of life and automitacaly be deleted after.

I think we'll have more input soon about big server owners

Yeeeeesssssss!!!!! Thanks to all of you!.

Hi all, First, if i not using sd2, is all creature ai are in mangos/creatures_ai_scripts? If yes, iam trying to understaind what function are called when creature disapear from script. (ex : Warp chase in outlands, id 18884) Creature disapearing this way loose their target. I forget lot of game mecanism, didn't remember if we can found it from any spell or if some class can see it in invisible mode. Nevermind, Schmoonzerd helped me allot

First i whant to say thanks to Faramir, Qsa and all member who help with MMAPS. Thank you guy! Some warning : - This require MMAPS to work correctly. (integrated now to official git !!!) - The status of the post is DEVELOPEMENT so don't expect working solution before any status change. - This patch need test to maximum situation to be validated. - I have some time actualy to work on it but tomorrow it's another day... What's the purpose exactly? MMAPS is a real improvement for game experience. All creature following terrain, not flying and other stuff like this are more fun to play with. But that features require to have a good aggro system to get all the avantage of MMAPS. Actual system is pretty limited. So here is the list off thing will be implemented. - use MMAPS to check reachability of creature target. - limit MMAPS calculation to save CPU. - allways keep threatlist position of player no mater if player is reachable or not. - implement PreEvadeMode. Before any creature goes to Evade we need wait xx sec (actualy 26s. Is it blizzlike?). Creature is invincible during this labs. If player becomes attackable the creature simply exit PreEvadeMode. - Correctly handle caster. - Select prefered target (without or with some aura) and probably other you'll tell me To see how it work look off my actual testing.Last Update (08 02 2012) After played a little with threat management, trying to understaind how it work i have conclued it's little bit more complex than i was imagined. We must make the best using of PathFinding and i must learn a little bit more of it. My first intention was only to select correct target and test it's reachability. If not reachable so enter in PreEvadeMode. (for 1 player) - Player is not reachable with spell and melee - Go to PreEvadeMode for 26 sec. - If Player becomes reachable before timer expire return to normal combat mode else go to evade mode. But after some research : (for 1 player) - If player is not reacheable by mele but the creature can attack with spell, considere player is reacheable. (but it's not always true mostly all creature can do spell damage an melee attack but do more damage at melee) - If creature is OOM and player is still unreacheable MoveChase() is called. Creature must go to PreEvadeMode at this point. Where is the best place to do it? In CreatureEventAI::ProcessEvent() - If creature is only melee, test is done in Creature::CanReach() and work not bad. But why generate new PathFinding when somewhere in StartAttack() we already do it via MoveChase() call? - Olso i have seen some case where player is considered like reachable but not in melee range. I must identify why exactly. So finaly all of this to say, to limit PathFinding call i need to understaind how MoveChase work and if it's possible to get just after its call something like IsPathFounded(). Olso i must migrate all the decision for PreEvadeMode in CreatureAI to get more consistant and olso open way to personalise every creature if needed. (Perhaps some creature does'nt need PreEvadeMode and or is normal situation and creature have script to handle it) Actual branch is updated in my repo but considere it only for information. Ill just restarted new branch to start with my conclusions.

Hi blueboy and other, just a little advise if you want to make your patch more readable.. use [co de=diff]code[/co de] ofc without space for 'code' but olso without space after code and after equal. to post your patch diff --git a/src/game/playerbot/PlayerbotAI.cpp b/src/game/playerbot/PlayerbotAI.cpp index b29c909..ff30c42 100644 --- a/src/game/playerbot/PlayerbotAI.cpp +++ b/src/game/playerbot/PlayerbotAI.cpp @@ -543,6 +543,11 @@ void PlayerbotAI::AutoUpgradeEquipment(Player& /*player*/) // test for autoequip void PlayerbotAI::AutoEquipComparison(Item *pItem, Item *pItem2) { + const static uint32 item_armor_skills[MAX_ITEM_SUBCLASS_ARMOR] = + { + 0, SKILL_CLOTH, SKILL_LEATHER, SKILL_MAIL, SKILL_PLATE_MAIL, 0, SKILL_SHIELD, 0, 0, 0, 0 + }; + // get itemlevel for current item equipped in slot ItemPrototype const *pProto = pItem2->GetProto(); // equipped item if any @@ -567,11 +572,13 @@ void PlayerbotAI::AutoEquipComparison(Item *pItem, Item *pItem2) } case ITEM_CLASS_ARMOR: { - if (pProto->ItemLevel < pProto2->ItemLevel && pProto->Armor <= pProto2->Armor && IsItemUseful(pProto2->ItemId)) // itemlevel + if (pProto->ItemLevel < pProto2->ItemLevel && pProto->Armor <= pProto2->Armor && + m_bot->HasSkill(item_armor_skills[pProto2->SubClass]) && !m_bot->HasSkill(item_armor_skills[pProto2->SubClass + 1])) // itemlevel + armour + armour class EquipItem(pItem); // now in case they are same itemlevel, but one is better than the other.. - if (pProto->ItemLevel == pProto2->ItemLevel && pProto->Quality < pProto2->Quality && pProto->Armor <= pProto2->Armor && IsItemUseful(pProto2->ItemId)) + if (pProto->ItemLevel == pProto2->ItemLevel && pProto->Quality < pProto2->Quality && pProto->Armor <= pProto2->Armor && + m_bot->HasSkill(item_armor_skills[pProto2->SubClass]) && !m_bot->HasSkill(item_armor_skills[pProto2->SubClass + 1])) // itemlevel + armour + armour class EquipItem(pItem); break; }

Schmoon is this already needed? And what is the difference with https://github.com/mangos/mangos/commit/093953955f7cb1c8bee5fa5d82eeca9bdffc878f#src/game/ThreatManager.cpp

Unfortunatly the idea is not so simple. We need to generate path and after test if that path is generated. bool Creature::IsReacheable(Unit* pVictim) { GetMotionMaster()->MoveChase(pVictim); if (GetMotionMaster()->operator->()->IsReachable()) return true; return false; } I only know movechase to try to generate path. But this cannot be used in Unit::SelectHostileTarget because that call is done every update. The best is to have fast but accurate fonction who can result with reacheable or not.

I understaind, hope you one day you change your mind and reinstall mangos source to take your hand on it Cheers

Thank for your comment Vladimir. Anyway we talk about _addMember(...) This method is only for add member dynamicaly to group (after accept invitation) This method are not called when any already member of an group goes offline/online. When member is added he is already in data group and showed correcttly online/offline in group-->sendUpdate(). At loggin group pointer is simply assigned to player because player is already on it. This is how i understaind actual code, am i wrong? If not thats why i think if player is null during _addMember so simply return false for this case instead to add player with some data not initialised. But we are ok it's simple way not the good way. With respect.

And i think for that part too or mysterious problem can occur //on Group.cpp _addmember if (player) { player->SetGroupInvite(NULL); //if player is in group and he is being added to BG raid group, then call SetBattleGroundRaid() if (player->GetGroup() && isBGGroup()) player->SetBattleGroundRaid(this, group); //if player is in bg raid and we are adding him to normal group, then call SetOriginalGroup() else if ( player->GetGroup() ) player->SetOriginalGroup(this, group); //if player is not in group, then call set group else player->SetGroup(this, group); // if the same group invites the player back, cancel the homebind timer if (InstanceGroupBind *bind = GetBoundInstance(player->GetMapId(), player)) if (bind->state->GetInstanceId() == player->GetInstanceId()) player->m_InstanceValid = true; } This code assumed player is online and will be added to the group. Why (in original method) if for some case player is null we not execute this part??? I think something wrong here. I think de best is to return false if player is null. It's the easyest way and secure.