Jump to content

Playerbot (archive)


Recommended Posts

This part fixes the Priest resurrecting:

diff --git a/src/game/playerbot/PlayerbotPriestAI.cpp b/src/game/playerbot/PlayerbotPriestAI.cpp
index 9ac7c54..38aba57 100644
--- a/src/game/playerbot/PlayerbotPriestAI.cpp
+++ b/src/game/playerbot/PlayerbotPriestAI.cpp
@@ -388,7 +388,7 @@ void PlayerbotPriestAI::DoNonCombatActions()

    // buff master
    if (POWER_WORD_FORTITUDE > 0)
-        (!GetMaster()->HasAura(POWER_WORD_FORTITUDE, EFFECT_INDEX_0) && ai->CastSpell(POWER_WORD_FORTITUDE, *(GetMaster())));
+        (!GetMaster()->HasAura(POWER_WORD_FORTITUDE, EFFECT_INDEX_0) && GetMaster()->isAlive() && ai->CastSpell(POWER_WORD_FORTITUDE, *(GetMaster())));

    // mana check
    if (m_bot->getStandState() != UNIT_STAND_STATE_STAND)

Apparently, buffs are removed when dead, so the bot was trying to rebuff which prevented the resurrect spell from being cast.

Link to comment
Share on other sites

  • Replies 1.8k
  • Created
  • Last Reply

Top Posters In This Topic

Thought I would add a bit more to the PriestAI and the resurrection thereof:

diff --git a/src/game/playerbot/PlayerbotAI.cpp b/src/game/playerbot/PlayerbotAI.cpp
index 53b1f44..5444ead 100644
--- a/src/game/playerbot/PlayerbotAI.cpp
+++ b/src/game/playerbot/PlayerbotAI.cpp
@@ -827,6 +827,34 @@ void PlayerbotAI::HandleBotOutgoingPacket(const WorldPacket& packet)
            return;
        }

+        // if someone tries to resurrect, then accept
+        case SMSG_RESURRECT_REQUEST:
+        {
+            if (!m_bot->isAlive() && m_botState != BOTSTATE_DEADRELEASED)
+            {
+                WorldPacket p(packet);
+                uint64 guid;
+                p >> guid;
+                uint32 namelen;
+                p >> namelen;
+
+                std::string name;
+                p >> name;
+                p >> Unused<uint8>();
+
+                uint8 isPlayer;
+                p >> isPlayer;
+
+                WorldPacket* const packet = new WorldPacket(CMSG_RESURRECT_RESPONSE, 8+1);
+                *packet << guid;
+                *packet << uint8(1);                        // accept
+                m_bot->GetSession()->QueuePacket(packet);   // queue the packet to get around race condition
+
+                // set back to normal
+                SetState(BOTSTATE_NORMAL);
+            }
+        }
+
            /* uncomment this and your bots will tell you all their outgoing packet opcode names
               case SMSG_MONSTER_MOVE:
               case SMSG_UPDATE_WORLD_STATE:
diff --git a/src/game/playerbot/PlayerbotPriestAI.cpp b/src/game/playerbot/PlayerbotPriestAI.cpp
index 38aba57..69938d3 100644
--- a/src/game/playerbot/PlayerbotPriestAI.cpp
+++ b/src/game/playerbot/PlayerbotPriestAI.cpp
@@ -437,7 +437,7 @@ void PlayerbotPriestAI::DoNonCombatActions()
                continue;

            // first rezz em
-            if (!tPlayer->isAlive() && !tPlayer->GetPlayerbotAI())
+            if (!tPlayer->isAlive())
            {
                std::string msg = "Resurrecting ";
                msg += tPlayer->GetName();

This makes it possible for a bot to accept resurrection and for a bot to resurrect a bot within the party. It tested fine for me, but test it for yourself as well; it is easy to miss something. I suppose it might be nice if the bot was to be thankful...

Link to comment
Share on other sites

Hi, BThallid

Thank you for your contribution. Code looks ok but a bit redundant. I'd change it:

1) Use readPackGUID() instead of >> to get GUID

2) There is no need to read anything but GUID from incoming packet.

3) Add

SetIgnoreUpdateTime(0);

in the end to reset AI delay.

4) You used

m_botState != BOTSTATE_DEADRELEASED

Can't we resurrect player when he's a ghost?

Link to comment
Share on other sites

1) Use readPackGUID() instead of >> to get GUID

In server code, I do not see on either SMSG_RESURRECT_REQUEST or CMSG_RESURRECT_RESPONSE where it uses a packed guid.

4) You used
m_botState != BOTSTATE_DEADRELEASED

Can't we resurrect player when he's a ghost?

If a player releases, then no resurrection is possible. Or at least shouldn't be.

Link to comment
Share on other sites

Sorry, I was wrong on GUID format. Regarding resurrection I can't check it right now, but from my experience on retail you can revive player anytime, even after release. The only thing that stopped players from release was death during boss fight cos they were losing their rolls on loot.

Link to comment
Share on other sites

Sorry, I was wrong on GUID format. Regarding resurrection I can't check it right now, but from my experience on retail you can revive player anytime, even after release. The only thing that stopped players from release was death during boss fight cos they were losing their rolls on loot.

That's how i remember it too. If player have released the corpse can still be used to do resurection by any class have resurection spell.

Greetings

Link to comment
Share on other sites

No, you are not :D I've just pushed compilation fix to portal repo, grab it now. Can't update blueboy repo as well due to very slow internet connection. I guess its time to learn cherry-pick feature in git...

Fix is known only to compile, report bugs if you find any.

Link to comment
Share on other sites

No, you are not :D I've just pushed compilation fix to portal repo, grab it now. Can't update blueboy repo as well due to very slow internet connection. I guess its time to learn cherry-pick feature in git...

Fix is known only to compile, report bugs if you find any.

Hi,

Cheers mate, I was working on the problem but you pipped me to the post ;) I was too tired this morning at 3 to continue...

The recent commits to portal seem to work fine. If you like I'll merge portal into blueboy repo

Hope this helps

Link to comment
Share on other sites

Alright, I am really sorry but I have to resort to asking. This may not be all that complex, and it may just boil down to me not understanding git and the way it works. I am far more familiar with svn and cvs.

I haven't been around for a while, and things have changed in the overall project but info should translate I'm sure.

What I am used to being able to do is this:

1: go to DB forum and find the most recent release. This gives me a MaNGOS version to work towards building.

side note: I have been able to successfully reset my local version to match this version and build it successfully with SD2

2: download mangos source and build

3: go home, be happy.

the problem I am running into is when I try to add in support for playerbot... no other core mod tried, so I assume I would have difficulty with any of them. Am I right in understanding that when looking at the git commits in the blueboy branch I am seeing clean mangos commits AND commits of playerbot code? for example: on 2010-09-26 there is commit in history 750c4f7. This is build number 10545 which matches my db version. This commit does not include (from what I can tell, correct me if i'm wrong) support for playerbot. I need to create a patch to get this commit to support the bots.

The patch is where I am running into issues. What I have been trying to do is create a patch from 5c1fe508 to the 10545 revision. I am able to build fine after applying what I think is the patch I created using gitk, but I am getting errors on server start after building that I have the wrong version of DB. Any help is appreciated.

Link to comment
Share on other sites

Hi, Famine

Blueboy's repository includes support for Playerbot. There is no need to patch it.

If you want to build your own flavor of MaNGOS with custom patches and addons, then I'm afraid you must learn how git works. Because almost all the forks are on github too. When you do it, you'll see how powerful this tool is.

Link to comment
Share on other sites

Hi Famine,

I agree with kyle1 that it will be better once you get to grips with git. Once you've tried git, you don't go back :lol:

But here is something to get you started.

Firstly you must choose a database (UDB, PSMDB, etc). Check the contents of table 'db_version' for update compatiblity with your server. Right, so you have a db compatible with MaNGOS[10545].

This will work either with *nix or gitbash (windows) systems.

git clone git://github.com/blueboy/mangos.git

cd mangos

or

create an empty local git repositiory and pull the code

mkdir mangos

cd mangos

git init

git pull git://github.com/blueboy/mangos.git

Use 'git log' to get commit history (snippet shown below has been edited to protect commiter's privacy)

commit 9c8043644bf5af1c1971ebb70dc17bc294d69b04
Author: Laise 
Date:   Tue Sep 28 15:40:32 2010 +0200

   [10554] Fix wrong procs when spell hits with no damage

commit e467b12ab63bcc670111d1e95b6d9a7b46e9f62c
Author: chelobaka 
Date:   Tue Sep 28 14:56:15 2010 +0400

   Check line of sight on spell cast.

   Also fix possible segmentation fault.

commit 3bedf90d5045ca2d10760c8ab42bef2a6f9f287f
Author: zergtmn 
Date:   Mon Sep 27 11:48:21 2010 +0200

   [10553] Two more cases where AURA_REMOVE_BY_EXPIRE mode can be used

   Signed-off-by: Laise 

Select the required commit and copy the commit hash.

git allows you to select (switch) the code to a particular commit. If you were to select the code pertaining to commit [10545] you would find no playerbot code, because this is a MaNGOS commit. If you want compatible playerbot code, you need to select the next playerbot commit after [10545]

N.B. MaNGOS commits invariably have a version number in square brackets and playerbot commits don't

To create a new local (branch) repositiory with the desired code

syntax: git checkout -b <branch name> <commit hash>

from the commit snippet above

git checkout -b my_new_branch e467b12ab63bcc670111d1e95b6d9a7b46e9f62c

Switched to branch 'my_new_branch'

Now to double check you have playerbot code, look in folder 'src/game'. You should have a sub-folder called playerbot that hold the bulk of playerbot code.

You may now need to update your database with the appropriate 'sql/updates'. As you can see from info below, in your case it is not necessary as there have been no updates to the db since before [10545]. Your server should load with your database without issue.

10503_03_mangos_creature_respawn.sql

10503_04_mangos_gameobject_respawn.sql

Makefile.am

README

/home/mangos/compile/temp/mangos/sql/updates #

now just build your code as normal and have fun :D

Creating a standalone patch is great to get snapshot of the code, compatible with the latest MaNGOS commit (HEAD).

#!/bin/bash -x
git clone git://github.com/mangos/mangos.git blueboy_patch
cd blueboy_patch
git fetch git://github.com/blueboy/mangos.git master:blueboy
git checkout blueboy
HASH=`git log --pretty=oneline | grep -m 1 '\\[1[0-9]\\{4\\}]' | cut -d " " -f 1`
git diff $HASH > playerbot.patch

This patch can be then archived by you and applied later to clean download of the same MaNGOS commit. It is not easy to create a patch from earlier commit (If you created a patch from the latest playerbot code, it may not work with MaNGOS[10545]. Chances are that you will get merge conflicts, that will cause you further headaches). You need to use the method given above.

Hope this helps

Link to comment
Share on other sites

Hi, Famine

Blueboy's repository includes support for Playerbot. There is no need to patch it.

If you want to build your own flavor of MaNGOS with custom patches and addons, then I'm afraid you must learn how git works. Because almost all the forks are on github too. When you do it, you'll see how powerful this tool is.

Yea, no I appreciate the power of the tool, and I am attempting to learn all the ins and outs of it. I really am not trying to avoid it, just attempting to understand the logic.

Hi Famine,

Firstly you must choose a database (UDB, PSMDB, etc). Check the contents of table 'db_version' for update compatiblity with your server. Right, so you have a db compatible with MaNGOS[10545].

This will work either with *nix or gitbash (windows) systems.

git clone git://github.com/blueboy/mangos.git

cd mangos

Right, you may have said it a little better than I did, but this is exactly where I started as well.

...

git allows you to select (switch) the code to a particular commit. If you were to select the code pertaining to commit [10545] you would find no playerbot code, because this is a MaNGOS commit. If you want compatible playerbot code, you need to select the next playerbot commit after [10545]

See... now that is how I understood the commits when I was browsing through the code. (btw I am using git reset as opposed to creating a new local branch... This may be part of my problem.)

This patch can be then archived by you and applied later to clean download of the same MaNGOS commit. It is not easy to create a patch from earlier commit (If you created a patch from the latest playerbot code, it may not work with MaNGOS[10545]. Chances are that you will get merge conflicts, that will cause you further headaches). You need to use the method given above.

Hope this helps

This is the problem right here... In an attempt to avoid having any part of the DB ahead of the core I am trying to fit 10#'s of crap in a 5# bag. Pushing the core to anything [10550] or above forces me to update the db. I realize that doesn't sound like a big deal, but in 4 months when I finally get around to updating my db I have the feeling im going to forget that a portion of the db is ahead. It avoids headaches.

Just so I can say I partially understand, Long story short, If I want to create a version of MaNGOS with this or any other project, find their commits ahead of the revision I am interested in. If I want to start combining projects, if there isn't a commit that is on the same version across the board I am going to come into issues.

And lesson is to stay up to date on the commits because it's easier to create a patch against the head revision than it is with something earlier.

Thanks for your time and effort blueboy, that took a while to get out i'm sure.

Link to comment
Share on other sites

I noticed that the HasPick function was checking database when the core already has compatible function.

diff --git a/src/game/playerbot/PlayerbotAI.cpp b/src/game/playerbot/PlayerbotAI.cpp
index 9fc8d4b..ab9e6de 100644
--- a/src/game/playerbot/PlayerbotAI.cpp
+++ b/src/game/playerbot/PlayerbotAI.cpp
@@ -2532,80 +2532,8 @@ bool PlayerbotAI::PickPocket(Unit* pTarget)

bool PlayerbotAI::HasPick()
{
-    QueryResult *result;
-
-    // list out equiped items
-    for (uint8 slot = EQUIPMENT_SLOT_START; slot < EQUIPMENT_SLOT_END; slot++)
-    {
-        Item* const pItem = m_bot->GetItemByPos(INVENTORY_SLOT_BAG_0, slot);
-        if (pItem)
-        {
-            const ItemPrototype* const pItemProto = pItem->GetProto();
-            if (!pItemProto)
-                continue;
-
-            result = WorldDatabase.PQuery("SELECT TotemCategory FROM item_template WHERE entry = '%i'", pItemProto->ItemId);
-            if (result)
-            {
-                Field *fields = result->Fetch();
-                uint32 tc = fields[0].GetUInt32();
-                // sLog.outDebug("HasPick %u",tc);
-                if (tc ==  165 || tc == 167) // pick = 165, hammer = 162 or hammer pick = 167
-                    return true;
-            }
-        }
-    }
-
-    // list out items in backpack
-    for (uint8 slot = INVENTORY_SLOT_ITEM_START; slot < INVENTORY_SLOT_ITEM_END; slot++)
-    {
-        // sLog.outDebug("[%s's]backpack slot = %u",m_bot->GetName(),slot); // 23 to 38 = 16
-        Item* const pItem = m_bot->GetItemByPos(INVENTORY_SLOT_BAG_0, slot); // 255, 23 to 38
-        if (pItem)
-        {
-            const ItemPrototype* const pItemProto = pItem->GetProto();
-            if (!pItemProto)
-                continue;
-
-            result = WorldDatabase.PQuery("SELECT TotemCategory FROM item_template WHERE entry = '%i'", pItemProto->ItemId);
-            if (result)
-            {
-                Field *fields = result->Fetch();
-                uint32 tc = fields[0].GetUInt32();
-                // sLog.outDebug("HasPick %u",tc);
-                if (tc ==  165 || tc == 167) // pick = 165, hammer = 162 or hammer pick = 167
-                    return true;
-            }
-        }
-    }
-
-    // list out items in other removable backpacks
-    for (uint8 bag = INVENTORY_SLOT_BAG_START; bag < INVENTORY_SLOT_BAG_END; ++bag) // 20 to 23 = 4
-    {
-        const Bag* const pBag = (Bag*) m_bot->GetItemByPos(INVENTORY_SLOT_BAG_0, bag); // 255, 20 to 23
-        if (pBag)
-            for (uint8 slot = 0; slot < pBag->GetBagSize(); ++slot)
-            {
-                // sLog.outDebug("[%s's]bag[%u] slot = %u",m_bot->GetName(),bag,slot); // 1 to bagsize = ?
-                Item* const pItem = m_bot->GetItemByPos(bag, slot); // 20 to 23, 1 to bagsize
-                if (pItem)
-                {
-                    const ItemPrototype* const pItemProto = pItem->GetProto();
-                    if (!pItemProto)
-                        continue;
-
-                    result = WorldDatabase.PQuery("SELECT TotemCategory FROM item_template WHERE entry = '%i'", pItemProto->ItemId);
-                    if (result)
-                    {
-                        Field *fields = result->Fetch();
-                        uint32 tc = fields[0].GetUInt32();
-                        // sLog.outDebug("HasPick %u",tc);
-                        if (tc ==  165 || tc == 167)
-                            return true;
-                    }
-                }
-            }
-    }
+    if (m_bot->HasItemTotemCategory(TC_MINING_PICK))
+        return true;
    std::ostringstream out;
    out << "|cffffffffI do not have a pick!";
    TellMaster(out.str().c_str());

The core's function also calls another function, IsTotemCategoryCompatiableWith, that checks if the item is compatible with the current TotemCategory, so it only has to be called for the specific category.

Link to comment
Share on other sites

I noticed that the HasPick function was checking database when the core already has compatible function.

The core's function also calls another function, IsTotemCategoryCompatiableWith, that checks if the item is compatible with the current TotemCategory, so it only has to be called for the specific category.

Thanks for that, I wrote HasPick() to service the 'survey - get' features I introduced :rolleyes:

Well spotted sir!

EDIT: One small change to the patch, so all possible mining picks will be considered

+ if (m_bot->HasItemTotemCategory(TC_MINING_PICK))

changed to

+ if (m_bot->HasItemTotemCategory(TC_MINING_PICK || TC_HAMMER_PICK || TC_BLADED_PICKAXE))

I have updated the portal repo

Link to comment
Share on other sites

HasItemTotemCategory() has single argument of uint32. Boolean expression will give you true of false. So in this case it is equivalent of calling HasItemTotemCategory(true).

There is also Gnomish Army Knife, which has its own totem category.

We have two options: 1) Call HasItemTotemCategory() for all pickaxe categories, or 2) write own method which would check all types of picks in single iteration.

Link to comment
Share on other sites

HasItemTotemCategory() has single argument of uint32. Boolean expression will give you true of false. So in this case it is equivalent of calling HasItemTotemCategory(true).

There is also Gnomish Army Knife, which has its own totem category.

We have two options: 1) Call HasItemTotemCategory() for all pickaxe categories, or 2) write own method which would check all types of picks in single iteration.

Hi kyle1,

Your absolutely right, sorry I made the change early this morning and I wasn't thinking straight :P We'll need to call HasItemTotemCategory three times for each option.

EDIT:

+ if (m_bot->HasItemTotemCategory(TC_MINING_PICK) || m_bot->HasItemTotemCategory(TC_HAMMER_PICK) || m_bot->HasItemTotemCategory(TC_BLADED_PICKAXE))

I'll update portal ASAP

Cheers

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. Privacy Policy Terms of Use