Playerbot (archive)

[mrelfire]

Did every step you posted and it just makes a blank patch file called playerbot.patch with 0kb size. and nothing inside that file.

instead of creating a patch, clone the directory from blueboy, or directly apply using git, the "git blueboy"'s branch above yours

[blueboy]

Did every step you posted and it just makes a blank patch file called playerbot.patch with 0kb size. and nothing inside that file.

Hi,

Did you use the script I provided. I have just tried it and it works perfectly. I can't make the instructions any simpler. Your script is wrong. Alternatively, do as mrelfire suggests and just clone the code on blueboy to your harddrive and build that.

If you are using windows, and a Bash emulator shell (Git Bash), perhaps that is not working correctly. However, I have used it myself without problems.

Cheers

[Unkle Nuke]

I use msysgit for Windows. I've never had any issues with the Git Bash. Scripts are a different matter. I've never figured out how to run those with Git Bash.

Either you're failing to create the branch or you're fetching the wrong revison/hash. That's all I can come up with as possible explanations.

Just try manually fetching playerbot and then creating your branch like this:

git remote add -f -t playerbot playerbot git://github.com/blueboy/mangos.git
git branch playerbot --track playerbot/playerbot

Then, if you need an earlier revision of playerbot you can either specify a hash when you're fetching or you can do a reset to revert the local branch.

Maybe Core Mods needs a Help Section so the developer topics can stick to information and issues about development and general use. This way, people who have troubles with pulling, fetching, merging, diffing (is that even a word?), and all the other "ings" can have more attention focused on their needs while leaving the code jockeys to develop, debate, and degenerate.

[deviljohn]

MaNGOS r9696

After summoning a bot, when you invite it to your party the server drops your connection.

logs show

2010-04-08 08:19:28 ERROR:ERROR: Attempted to get in ByteBuffer (pos: 12 size: 12) value with size: 4

2010-04-08 08:19:28 ERROR:WorldSession::Update ByteBufferException occured while parsing a packet (opcode: 110) from client 127.0.0.1, accountid=1.

btw:

this is using your current repository. and its the only core patch I use. YTDB and scriptdev2 and Acid updated to current revisions.

I believe the conflict is in GroupHandler.cpp

[mrelfire]

a smal conflict with latest core upgrade

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

* branch master -> FETCH_HEAD

Auto-merging src/game/CharacterHandler.cpp

Auto-merging src/game/Chat.cpp

Auto-merging src/game/Chat.h

Auto-merging src/game/ChatHandler.cpp

Auto-merging src/game/Group.cpp

Auto-merging src/game/GroupHandler.cpp

CONFLICT (content): Merge conflict in src/game/GroupHandler.cpp

Auto-merging src/game/Makefile.am

Auto-merging src/game/Player.cpp

Auto-merging src/game/Player.h

Auto-merging src/game/QueryHandler.cpp

Auto-merging src/game/QuestHandler.cpp

Auto-merging src/game/WorldSession.cpp

Auto-merging src/mangosd/mangosd.conf.dist.in

Auto-merging win/VC90/game.vcproj

Automatic merge failed; fix conflicts and then commit the result.

[blueboy]

Hi Guys,

The conflicts with GroupHandler.cpp were changes made to code comments, but are now sorted.

I have just updated the code on blueboy to be compatible with MaNGOS[9701] and the new 3.3.3. client update ( remember to change your dbc, maps & vmaps). I have tested the code with;

MaNGOS[9702]

ScriptDev2[1671]

The code compiles and runs without issue.

Hope this helps

[deviljohn]

Just pulled and recompiled with 9702. Playerbot is interacting with me but still will not join a party on invite. Same error for me as above, but now the server does not disconnect me, just doesn't join the party. Still get the error in logs however

2010-04-08 22:10:59 ERROR:ERROR: Attempted to get in ByteBuffer (pos: 12 size: 12) value with size: 4

2010-04-08 22:10:59 ERROR:WorldSession::Update ByteBufferException occured while parsing a packet (opcode: 110) from client 127.0.0.1, accountid=1.

[DaemonCantor]

Just pulled and recompiled with 9702. Playerbot is interacting with me but still will not join a party on invite. Same error for me as above, but now the server does not disconnect me, just doesn't join the party. Still get the error in logs however

2010-04-08 22:10:59 ERROR:ERROR: Attempted to get in ByteBuffer (pos: 12 size: 12) value with size: 4

2010-04-08 22:10:59 ERROR:WorldSession::Update ByteBufferException occured while parsing a packet (opcode: 110) from client 127.0.0.1, accountid=1.

Blueboy this is the byte I was referring to in my message to you that they are reversed...

[blueboy]

Just pulled and recompiled with 9702. Playerbot is interacting with me but still will not join a party on invite. Same error for me as above, but now the server does not disconnect me, just doesn't join the party. Still get the error in logs however

2010-04-08 22:10:59 ERROR:ERROR: Attempted to get in ByteBuffer (pos: 12 size: 12) value with size: 4

2010-04-08 22:10:59 ERROR:WorldSession::Update ByteBufferException occured while parsing a packet (opcode: 110) from client 127.0.0.1, accountid=1.

Hi,

I must admit I am very puzzled by your errors, I'm getting no problems with group invitation. Looking at the MaNGOS changelog, changes have been made http://github.com/mangos/mangos/commit/5ca7c18fe3117e6d2b6c80d1a9c0ecb7d3497833 to group invites. I had to comment out the line @ 169 below from GroupHandler.cpp to allow invites. Check that this is still commented out.

void WorldSession::HandleGroupAcceptOpcode( WorldPacket & recv_data )

// recv_data.read_skip<uint32>(); // roles mask?

The error

2010-04-08 22:10:59 ERROR:WorldSession::Update ByteBufferException occured while parsing a packet (opcode: 110) from client 127.0.0.1, accountid=1.

also suggests that your running the client on the same machine as the server, Is this true? Take a look at the commit I have referenced above and compare the changes with the code on your machine.

EDIT: How are you preparing the code for build? Are you downloading the code from blueboy, then merging with the MaNGOS head? If so, then that would account for the problems with group invites. The MaNGOS code will effectively reverse the changes I have made in GroupHandler.cpp.

Let me know how you get on.

[deviljohn]

Good to go here now Blueboy. It was just as you said. And yes to both counts on I do clone your repo as master and fetch updates from mangos/mangos master. I also run the client for testing on the same machine as the server.

What happened was just as you described. I was git'n it on from r9676 - 9696 on the pull that screwed my base here. On that pull, the master mangos fetch overwrote your patch and stuck the line right under the line you had commented out. I failed to notice this, and after editing GroupHandler.cpp I added and commited it.

Sorry for the delay getting back on this, was burned out and needed some sleep.

I started cloning Blueboy first a while back as that eleminated merge errors from pulling AHBot with it by reducing one of the merges. I used to run AHBot also, but since AHBot has had problems keeping up lately, I stopped using it. I only run this server for local testing anyways, AHBot is cool and all, but not something I have to have. PlayerBot actually keeps me interested. I always wanted to have this game as a single player game with multiple party members, and thats what PlayerBot gives us.

I use GNUwin32 for my shell on win7. Currently i create my local repo with

git clone git://github.com/blueboy/mangos.git mangos
cd mangos/src/bindings
git clone git://github.com/scriptdev2/scriptdev2.git ScriptDev2
cd ../../
echo "by-passing git pull git://github.com/Naicisum/mangos.git ahbot"
git pull git://github.com/mangos/mangos.git master
cd ../

then just work updates with

cd mangos
git pull git://github.com/blueboy/mangos.git master
git pull git://github.com/mangos/mangos.git master
echo "by-passing git pull git://github.com/Naicisum/mangos.git ahbot"
cd src/bindings/ScriptDev2
git pull origin master
cd ../../../../

Thanks for the help again, and for keeping this awesome feature alive and doing so well.

[blueboy]

Hi deviljohn,

Brilliant that you have got it working, I'm going to be away for the next few days and I was worried that I was going to leave playerbot broken. Hopefully, it will remain problem free, at least until I get back.

I built a windows test server and found GitBash useful in running the relevant scripts. Do you create and apply patches under windows. This might avoid this issue occuring again. I like to always start with a clean download of MaNGOS, and then apply the necessary mods. If you are interested I can post the adapted scripts I created under linux, to aid in building on windows.

Interesting, I didn't realise that ScriptDev2 was available on Github. I'm still pulling it from Subversion. I use the following script to pull a specific version of ScriptDev2, rather than always the branch HEAD (e.g ./scriptdev2.sh 1670).

#!/bin/bash

unset VERSION
unset DEST

VERSION=$1
DEST="E:\\mangos\\src\\src\\bindings\\ScriptDev2"
if [ -z "${VERSION}" ]; then
echo "No ScriptDev2 VERSION specified, assume latest VERSION";
else
VERSION="-r "${VERSION};
fi

if [ -d "${DEST}" ]; then
rm -R ${DEST};
fi

mkdir ${DEST};
svn co [url]https://scriptdev2.svn.sourceforge.net/svnroot/scriptdev2/[/url] ${DEST} ${VERSION}

As far as auctionhousebot is concerned I am presently not using it, and I certainly wouldn't pull from the Naicisum's Github, that has now well and truly stagnated. Hopefully it will not be long before Xeross has his Github running with the latest MaNGOS.

Hope this helps

[nickless]

hey blueboy

is there any eta. on ur next update?

Regard Nickless

[Unkle Nuke]

I think blueboy is still away, out there in that terrible place, where even angels fear to read, called...the real world! <insert scary music of doom here>

You should still be able to merge playerbot with MaNGOS with few problems. You might have to complete a merge with git mergetool to resolve conflicts by hand, but most of those ought to be due to differences in line numbering.

Keep in mind that if you're using other patches and core mods, such as AHBot or Vehicles, to add in playerbot first to help minimize conflicts with other patches.

Off-topic, but relevant to a comment from blueboy:

AHBot has been fixed and should work just fine with new revisions of MaNGOS. After ~9603, there were major changes made to the core concerning SQL table schemas that had broken AHBot, but those have been resolved, thanks to xeross155 and other contributors. More info can be found in the topic for AHBot.

[blueboy]

Hi Guys,

Sorry for my absence, but it has given me a chance to examine this issue more closely, and also play the game

Issue - Premature reset on the current map - m_currMap

Whilst in an instance (Dungeon) with a group of bots. If the player dies and is removed from the instance to the nearest graveyard. The bots will try to follow, attempting teleportation. As they do, the following assertion error occurs,

Player Bean is being teleported to map 43

../../../src/game/Object.h:466: Error: Assertion in GetMap failed: m_currMap

Stack Trace:

/home/mangos/wow/bin/mangos-worldd(_ZN3Map16MessageBroadcastEP6PlayerP11WorldPacketb+0xb2) [0x822ee82]

/home/mangos/wow/bin/mangos-worldd(_ZN6Player16SendMessageToSetEP11WorldPacketb+0x45) [0x82acc35]

/home/mangos/wow/bin/mangos-worldd(_ZN4Unit15SendMonsterMoveEfff10SplineType11SplineFlagsjP6Playerz+0x29f) [0x83c8bbf]

/home/mangos/wow/bin/mangos-worldd [0x83a76a3]

/home/mangos/wow/bin/mangos-worldd(_ZN31TargetedMovementGeneratorMediumI6Player23FollowMovementGeneratorIS0_EE18_setTargetLocationERS0_+0x95) [0x83a8c35]

/home/mangos/wow/bin/mangos-worldd(_ZN12MotionMaster6MutateEP17MovementGenerator+0x6f) [0x824600f]

/home/mangos/wow/bin/mangos-worldd(_ZN12MotionMaster10MoveFollowEP4Unitff+0x220) [0x8246c10]

/home/mangos/wow/bin/mangos-worldd(_ZN11PlayerbotAI13MovementResetEv+0xd1) [0x8306671]

/home/mangos/wow/bin/mangos-worldd(_ZN11PlayerbotAI8UpdateAIEj+0x301) [0x830a181]

/home/mangos/wow/bin/mangos-worldd(_ZN6Player6UpdateEj+0x5d0) [0x82f7000]

/home/mangos/wow/bin/mangos-worldd(_ZN3Map6UpdateERKj+0x55) [0x8237ea5]

/home/mangos/wow/bin/mangos-worldd(_ZN10MapManager6UpdateEj+0x6a) [0x824430a]

/home/mangos/wow/bin/mangos-worldd(_ZN5World6UpdateEj+0x1d4) [0x83ee714]

/home/mangos/wow/bin/mangos-worldd(_ZN13WorldRunnable3runEv+0xb7) [0x81236b7]

/home/mangos/wow/bin/mangos-worldd(_ZN9ACE_Based6Thread10ThreadTaskEPv+0x1a) [0x849682a]

/home/mangos/wow/lib/libACE-5.6.6.so(_ZN21ACE_OS_Thread_Adapter6invokeEv+0x65) [0xb76ef595]

/home/mangos/wow/lib/libACE-5.6.6.so(ace_thread_adapter+0x11) [0xb769a2c1]

/lib/libpthread.so.0 [0xb6f496e5]

/lib/libpthread.so.0 [0xb6f49600]

mangos-worldd: ../../../src/game/Object.h:466: Map* WorldObject::GetMap() const: Assertion `"m_currMap" && 0' failed.

Solution

Essentially the function GetMap is being called. The current map (m_currMap), has a NULL value. This then causes the assertion.

I first scattered flags in the code to follow the program flow.

I traced the issue to bool Player::TeleportTo(uint32 mapid, float x, float y, float z, float orientation, uint32 options) located @ line 1648 in Player.cpp.

Initially I thought the following might be the cause, @ line 1754

// far teleport to another map

Map* oldmap = IsInWorld() ? GetMap() : NULL;

The flags at this point showed that m_currMap has a valid map location. However at line 1848 in Player.cpp, the function,

// remove from old map now

if(oldmap)

oldmap->Remove(this, false);

void Map::Remove(Player *player, bool remove) is called from Map.cpp @ line 719. This ultimately resets the current map to NULL @ line 764 with a call to the function ResetMap()

UpdateObjectsVisibilityFor(player,cell,p);

// player->ResetMap();

if( remove )

DeleteFromWorld(player);

}

Later GetMap() is called again, but this time m_currMap is NULL and the assertion occurs. All I have done is to comment out the call to ResetMap() in Map.cpp;

I have tested the solution by completing the 'Wailing Caverns' dungeon, without any server crash. I would appreciate it if you Guys could do the same in a dungeon of your choice and give me some feedback.

I will shortly update the code on blueboy, with this solution included for you to test.

P.S. Since commenting on the difficulties on the auctionhousebot thread, Xeross has updated his Github and I can confirm that it works fine with the latest MaNGOS. As UnkleNuke correctly points out, both playerbot and auctionhousebot will work, with a little adjustment for core changes.

Hope this helps

[blueboy]

Hi Guys,

Since posting the fix for this issue I have experienced further crashes without warning, when the player and bot(s) are separated between instances.

WORLD: Recvd MSG_MOVE_SET_FACING (218, 0xDA) opcode

STORAGE_SIZE: 32

01 35 01 00 00 00 00 00 | 58 34 AA 00 A3 30 2C C6

7C D0 BD 44 AA DD 2B 42 | 1F BF 3E 40 0F 00 00 00

Warning: Program '/home/mangos/wow/bin/mangos-worldd' crashed.

After several crashes, it was clear that the crash only occurs if the player is dead and in transit between the graveyard and it's corpse. If the bot(s) then try to teleport from the instance to the player, BANG!:mad: Logically there is no advantage in the bot(s) teleporting to the player's ghost. So in the FollowCheckTeleport function @ line 2546 in PlayerbotAI.cpp

bool PlayerbotAI::FollowCheckTeleport( WorldObject &obj )

{

// if bot has strayed too far from the master, teleport bot

if (!m_bot->IsWithinDistInMap( &obj, 50, true ) && GetMaster()->isAlive())

{

m_ignoreAIUpdatesUntilTime = time(0) + 6;

PlayerbotChatHandler ch(GetMaster());

if (! ch.teleport(*m_bot))

{

ch.sysmessage(".. could not be teleported ..");

//sLog.outDebug( "[PlayerbotAI]: %s failed to teleport", m_bot->GetName() );

return false;

}

}

return true;

}

I have included a condition to prevent the bot(s) teleporting, while the player is dead. They will now remain by the player's corpse or at least in the same instance as the player's corpse.

I have tested this update with instance (The Deadmines, Westfall) and so far so good. I would welcome feedback, good or bad.

EDIT: I will update the code on blueboy shortly

Hope this helps

[blueboy]

Hi Guys,

Looks like it's just me testing this fix. I have found a loophole in my fix. The fix works fine if the player continues to return to the instance, after death. However, if the player chooses to be resurrected by the spirit healer, we again have the situation where the player and bot(s) are separated between instances. As soon as the bot(s) then try to teleport to the player, the server will crash.

Solution

I have found that the instability has something to do with group membership. If the group is disbanded, no crash occurs.

I thought that it would be fitting to reward the player's treachery in using the spirit healer, by triggering a breakup of the group. I have written code that will capture the CMSG_SPIRIT_HEALER_ACTIVATE opcode and direct member bots to leave the group. The bot(s) will still travel to the players location, but the server no longer crashes. Once all bots are assembled, you can again invite them (if they forgive you :rolleyes:) to form a new group.

I will update the code on blueboy shortly, so you can test it.

Hope this helps

[deviljohn]

Greets Blueboy! Hope your trip went well

I pulled the repo this eariler this morning after you pushed up the first or second fix for the teleport fix. I recieved an error in PlayerbotAI.cpp from the following lines

507 and 517.

//    && (pSpellInfo->EffectApplyAuraName[2] == SPELL_AURA_MOD_INCREASE_FLIGHT_SPEED))
     { if((pSpellInfo->EffectBasePoints[1] == master_speed1)
            && (pSpellInfo->EffectBasePoints[2] == master_speed2))
         {  spellMount = spellId;
            break; }
      }
      else if(pSpellInfo->EffectApplyAuraName[2] == SPELL_AURA_MOD_INCREASE_MOUNTED_SPEED)
//    && (pSpellInfo->EffectApplyAuraName[1] == SPELL_AURA_MOD_INCREASE_FLIGHT_SPEED))

I just commented out the lines and adjusted the parenthesis to compile.

this is building in Win with VS2k8. Something must have changed in Core with SPELL_AURA_MOD_INCREASE_FLIGHT_SPEED

I'll pull your last push and recompile now. Thanks again and good to see you back home!

[Unkle Nuke]

Something did change. In revision 9754, a fix for Druid's Swift Flight Form was added to the core. The patch directly affects those lines of code you listed, deviljohn.

[deviljohn]

Thanks UncleNuke, looked at that change you pointed me to and took a stab at it.

I updated line 507 from

&& (pSpellInfo->EffectApplyAuraName[2] == SPELL_AURA_MOD_INCREASE_FLIGHT_SPEED))

to

&& (pSpellInfo->EffectApplyAuraName[2] == SPELL_AURA_MOD_FLIGHT_SPEED_MOUNTED))

and line 517 from

&& (pSpellInfo->EffectApplyAuraName[1] == SPELL_AURA_MOD_INCREASE_FLIGHT_SPEED))

to

&& (pSpellInfo->EffectApplyAuraName[1] == SPELL_AURA_MOD_FLIGHT_SPEED_MOUNTED))

This compiles and runs, but needs testing. I'll give it a shot later tonight.

[mrelfire]

I have tryed to ocmpile this morning with latest mangos core and I have this problem :

10>..\\..\\src\\game\\PlayerbotAI.cpp(507) : error C2065: 'SPELL_AURA_MOD_INCREASE_FLIGHT_SPEED' : undeclared identifier

10>..\\..\\src\\game\\PlayerbotAI.cpp(517) : error C2065: 'SPELL_AURA_MOD_INCREASE_FLIGHT_SPEED' : undeclared identifier

[vladex]

just apply the things deviljohn said and it should work, at least it works for me

[blueboy]

Hi Guys,

I have revised the 'free' command. I'm not sure whether you use it at present, but I thought I could improve upon the information it provides. I have also renamed it to something more appropriate. The new name is 'stats'.

/w botname stats // statistic for single bot

/p stats // statistics for all group members

e.g

[Jock] has 2g9s2c bag slots 1 & item damage cost 0g0s55c

[Lutz] has 4g70s98c bag slots 0 & item damage cost 0g1s25c

[Pascal] has 52g 43s48c bag slots: 11 & item damage cost 0g44s95c

[Bean] has 4g53s70c bag slots 16 & item damage cost 0g0s80c

First Feature: Have you ever needed to know how much money the bot(s) has. At present, the only way to do this is by trading. The bot(s) will list available money and all inventory items (can be many). The trade dialog also pops up over this info. You then have to close the dialog and scroll back to find the amount. You will appreciate that this can be a real pain. The revised 'stats' command displays all info in a single line, so you can easily view statistics on all group members, without fuss.

Second Feature: Free bag slots are displayed, as they were with the 'free' command.

Third Feature: It is easy to view personal item damage and the cost of item repair, at the NPC anvil. But, you can't at present determine the damage for the bot(s) or easilty evaluate whether the bot(s) can afford repair. The new stats command allows you to do this from anywhere.

I will update the code on blueboy shortly to include this revision. I have also been testing the repair patch without fault and I have not receive any bad reports, so I propose to include this in the update too. Thanks to UnkleNuke & deviljohn for the info on recent changes with 'flight speed' auras. I will include these changes in the update.

NOTE: Do not pull the merge, pull the commit that follows

Hope you like the changes

[nyko]

git pull failed

mangos.conf.dist changed

[blueboy]

git pull failed

mangos.conf.dist changed

Hi,

It will pull now , I have just updated the code on blueboy

Hope this helps

[Unkle Nuke]

Thanks much, blueboy!

I hope your time away was productive and/or enjoyable, since it wasn't stated if it was related to business or pleasure. Either way, it's good to see you back in the asylum.