blueboy

Thanks for the replies, It shouldn't be necessary to compile a debug version of MaNGOS, normally if there is a serious problem with the server, something is echoed to the server terminal at the time of the crash. I had nothing on mine:( I guess the first step, as policent suggested would be to remove all code pertaining to botguy. Then monitor for any crashes. I'm still running with 3.2.2a & MaNGOS [8965]. I am at present running as a druid, leading a group consisting of a paladin, shamen and a mage. I haven't had problems with melee, but the group loot is messed up, if you haven't got a free inventory slot. The client refuses to issue the item to the winner, saying that is is still being rolled for! and then the item is lost. The server stability is the priority issue as always though and I will look into this. @erazare Are you using the code from blueboy? I have examined NPCHandler.cpp and 'pCreature' pointer is definitely declared. void WorldSession::HandleGossipHelloOpcode(WorldPacket & recv_data) { sLog.outDebug("WORLD: Received CMSG_GOSSIP_HELLO"); uint64 guid; recv_data >> guid; Creature *pCreature = GetPlayer()->GetNPCIfCanInteractWith(guid, UNIT_NPC_FLAG_NONE); if (!pCreature) { sLog.outDebug("WORLD: HandleGossipHelloOpcode - Unit (GUID: %u) not found or you can't interact with him.", uint32(GUID_LOPART(guid))); return; } // remove fake death if (GetPlayer()->hasUnitState(UNIT_STAT_DIED)) GetPlayer()->RemoveSpellsCausingAura(SPELL_AURA_FEIGN_DEATH); // Playerbot mod if(pCreature->isBotGiver()) { GetPlayer()->TalkedToCreature(pCreature->GetEntry(),pCreature->GetGUID()); _player->PrepareGossipMenu(pCreature,GOSSIP_OPTION_BOT); _player->SendPreparedGossip(pCreature); pCreature->StopMoving(); } else if (!pCreature->IsStopped()) pCreature->StopMoving(); if (pCreature->isSpiritGuide()) pCreature->SendAreaSpiritHealerQueryOpcode(_player); if (!Script->GossipHello(_player, pCreature)) { _player->TalkedToCreature(pCreature->GetEntry(), pCreature->GetGUID()); _player->PrepareGossipMenu(pCreature, pCreature->GetCreatureInfo()->GossipMenuId); _player->SendPreparedGossip(pCreature); } } Like I said in my previous post it is necessary to ONLY use the playerbot patch with MaNGOS [8965] from blueboy. They are shifting code around with every commit. (e.g in Player.cpp PrepareGossipMenu() @ 12221, I had to add a declaration of 'pCreature' just for the playerbot mod. They had moved the original declaration further on down the function, presumably to optimise the code) You should not get any compiler issues if you use the code as is Hope this helps, blueboy

Hi, * When your server crashes, are there any error messages? * Does your server crash now you have stopped using botguy? I do not normally use botguy, but I applied the sql files for test purposes, after I uploaded to my repo. Interesting my server also occasionally crashes, with no error messages.:huh: Out of interest, what is his purpose? and where do you find the bot recruiter 'Pappy Looter' ?:confused: I must apologise to policent, in reply to his last post.:rolleyes: He did refer to 'mangos_botguy.sql', but I couldn't fathom what his issue was. His post ended... I was not about to chop out code without some justification. I gather from the recent commits associated with GOSSIP menus, that they will be handled differently in the future. GOSSIP menus that were controlled inline are being shifted to more towards the database, to allow flexibility in scripting. The botguy code may have to be rewritten. Great to hear that playerbot works with the new wow client. I didn't think MaNGOS supported that yet? * Did you modify it in anyway? * Are you using the code from blueboy or playerbot? Thanks for the feedback

Hi, The adjustment of playerbot in MY repo (address given in my last post) allows for the migration of GOSSIP functions from the Creature class to the Player class (after 8900). The code is on test. Do not pull from playerbot at present, but from blueboy. I have tested the code and it is compatible with MaNGOS[8965]. I would only use the code with this version of MaNGOS. If you try to merge with earlier code you will probably experience conflict. The problem is that they did not make the move in one go, but over several commits. As far as I know the code for GOSSIP has been moved, nothing has been removed. i.e a chunk of code was moved from Creature.h to GossipDef.h, and from Creature.cpp to Player.cpp. Some functions were renamed in the process and I had too compensate in the playerbot code. I agree that mangos_botguy.sql needs updating. If you check the updates to the MaNGOS database (data/mangos/sql/updates) you will see that they have altered the creature_template. You will get a column count mismatch error. You could alter this yourself in mangos_botguy.sql. 8923_01_mangos_gossip.sql:ALTER TABLE creature_template ADD gossip_menu_id mediumint(8) unsigned NOT NULL default 0 AFTER IconName; I must admit that I have never used this, but if there were issues with the sql file, the database server (MySQL) would not use it. It would not cause a crash:) The sql update above tells us that a new column 'gossip_menu_id' has been added to 'creature_template' after field 'IconName'. IconName field is the 13th column from the start of the table, just add another VALUE after IconName. The default value is zero, so add '0', after NULL, mangos_botguy.sql INSERT INTO `creature_template` VALUES ('99002','0','0','0','0','0','20','0','20','0','Pappy Looter','The Bot Recruiter',NULL,'59','61','6700','24000','5598','5875','20','35','35','1','1.48','0','0','181','189','0','158','1','1400','1900','0','0','0','0','0','0','0','0','0','0','100','7','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','','1','3','1','1','0','0','0','0','0','0','0','0','1','0','0','0','bot_giver'); regards blueboy

At last I have managed to get the hang of commiting work to github. Thanks to everyone for their help;) I can't count the number of times I have created and deleted forks. Anyway a slight change, the code is compatible with the latest MaNGOS commit [8965]. I have checked the repo on my server; MaNGOS [8965] Latest version SD2 [1513] PSMDB [274] auctionhousebot patch autobroadcast patch No problems compiling, and it is ready for you guys to test out before I get permission to pull to the main playerbot branch. You can get the code from my repo @ git pull git://github.com/blueboy/mangos.git

I am trying to commit a patch to playerbot, without any success. Before you direct me to the first post http://wiki.github.com/playerbot/mangos, that is what I have been trying to use. * request contributer access on the forum. Who do I ask? I have examined other contributor profiles and they appear to use repos that fork off the main mangos branch, rather than playerbot. Yet they commit regularly to playerbot? I notice that most merge with the mangos branch prior to commiting to playerbot. I would like to commit properly; can anyone give me an ' idiots guide' :rolleyes: Thanks

I am trying to commit a patch to make playerbot compatible with MaNGOS [8917]. I am still testing it and if it's O.K, I will be uploaded to the main playerbot hub.

Hi, You haven't provided any information as to code versions? (i.e MaNGOS, SD2, or patches used). However you always begin troubleshooting compiler issues by asking the question, What has changed? The error shown above suggests that there is something missing from the Creature class, and there are several references to Gossip. I would always look in the http://www.manground.org/mangosChangelog.html?logpage=15 to see if the core has been changed. I see that commit [8900] Move most gossip related functions from Creature to Player class. I would try using a version of MaNGOS prior to this, or edit the code of any patches used. Perhaps update these patches. I don't know what database you use. I use http://svn.assembla.com/svn/psmdb_wotlk/ and they suggest which versions of MaNGOS & SD2 are compatible with the current db release (I'm using PSMDB:271 , MaNGOS: 8874 & SD2 1508). The current release of playerbot compiles fine with this Hope this helps

Like I said, I'm no expert and there are many that are. I have not yet got the courage to commit my code for the worry of messy up the github rep :huh: I have a good rapport with a senior member of this forum who kindly commits the patches I publish. It allows others to test the code before commiting, and reduces the number of commits, reducing possible code conflicts. Ask and I am sure someone will publish yours too

@LordPsyan You have downloaded playerbot from github, and it does not work with the latest MaNGOS core. Yes!. if it helps I will explain how I do it, it works!, if a little unorthodox. I will be the first to admit that I am no expert at using git. My bro gave me a crash tutorial on his last visit from the States. For each change to the playerbot I like to do a full server compilation (On my box it take approx one hour). First, visit github/playerbot and determine from the commit history the latest version of MaNGOS core, at the time of the lastest playerbot commit. This is shown as a commit with a version in square brackets i.e [8898]. I use this as a yardstick for compatibility. Often changes made with the MaNGOS core will break playerbot, particularly if you use versions that differ greatly from that shown in the github/playerbot. I create one large playerbot patch that I then merge with a clean download, pulled from github/mangos. If there is any compatibitly issues, they will show up when you try to apply the patch. I like to create a snapshot patch, for each change made to playerbot. I have them catalogued according to the MaNGOS version found above. Scripts to Automatically create playerbot.patch (Sorry! I use a Linux box, so these are Bash scripts) Originally I created the patch manually, as it required me to copy and paste the SHA HASH code for the appropriate MaNGOS version. I then developed two Bash scripts that would create the patch automatically. It takes about ten minutes, so you have plenty of time to go and make yourself a coffee. Script 1 ** pbot.sh ** main script to run #!/bin/bash -x # create empty .git repository mkdir playerbot cd playerbot git init # get hash for latest mangos release [XXXX], associated with playerbot release git pull git://github.com/playerbot/mangos.git master ../gethash.sh # read hash into 'line' variable { while read line do echo $line done } < hash.txt # cleanup & remove unwanted .git repositiory cd .. rm -R playerbot # create empty .git repository mkdir playerbot cd playerbot git init # pull mangos master branch git pull git://github.com/mangos/mangos.git master # change to mangos branch associated with hash git checkout -b mangos $line # add remote playerbot branch to compare with local mangos branch git remote add playerbot git://github.com/playerbot/mangos.git #merge remote branch with local branch git pull playerbot master # difference between merged local branch & mangos hash branch git diff $line > playerbot.patch Script 2** gethash.sh ** script called by pbot.sh #!/bin/bash [ -f "hash.txt" ] && rm hash.txt git log --pretty=oneline > commit.txt { while read line do echo $line > line.txt while read -r -n1 char do [ "$char" == "[" ] && exit echo -n $char >> hash.txt done < line.txt rm hash.txt done } < commit.txt Patch is created and stored in a directory called playerbot. To apply the created playerbot.patch, execute the following in the MaNGOS source root. patch --dry-run -p1 < playerbot.patch // This will test the patch against the MaNGOS core without actually applying it. Check for conflicts? patch -p1 < playerbot.patch // To apply and make changes. @warrior As far as my work is concerned, all but the following patch has been applied to github GroupLoot Update (Change 'rollType' to 'choice' & remove switch group->GetLootMethod() statement to simplify) diff --git a/src/game/PlayerbotMgr.cpp b/src/game/PlayerbotMgr.cpp index 1d15ab7..cf8c466 100644 --- a/src/game/PlayerbotMgr.cpp +++ b/src/game/PlayerbotMgr.cpp @@ -280,65 +280,49 @@ void PlayerbotMgr::HandleMasterIncomingPacket(const WorldPacket& packet) } return; } - case CMSG_LOOT_ROLL: + + case CMSG_LOOT_ROLL: + { + + WorldPacket p(packet); //WorldPacket packet for CMSG_LOOT_ROLL, (8+4+1) + uint64 Guid; + uint32 NumberOfPlayers; + uint8 rollType; + p.rpos(0); //reset packet pointer + p >> Guid; //guid of the item rolled + p >> NumberOfPlayers; //number of players invited to roll + p >> rollType; //need,greed or pass on roll + + + for (PlayerBotMap::const_iterator it = GetPlayerBotsBegin(); it != GetPlayerBotsEnd(); ++it) { - WorldPacket p(packet); //WorldPacket packet for CMSG_LOOT_ROLL, (8+4+1) - uint64 Guid; - uint32 NumberOfPlayers; - uint8 rollType; - p.rpos(0); //reset packet pointer - p >> Guid; //guid of the item rolled - p >> NumberOfPlayers; //number of players invited to roll - p >> rollType; //need,greed or pass on roll - - - for (PlayerBotMap::const_iterator it = GetPlayerBotsBegin(); it != GetPlayerBotsEnd(); ++it) - { - - uint32 choice = urand(0,2); //returns 0,1,or 2 - - Player* const bot = it->second; - if(!bot) - return; - - Group* group = bot->GetGroup(); - if(!group) - return; - - switch (group->GetLootMethod()) - { - case GROUP_LOOT: - // bot random roll - group->CountRollVote(bot->GetGUID(), Guid, NumberOfPlayers, choice); - break; - case NEED_BEFORE_GREED: - choice = 1; - // bot need roll - group->CountRollVote(bot->GetGUID(), Guid, NumberOfPlayers, choice); - break; - case MASTER_LOOT: - choice = 0; - // bot pass on roll - group->CountRollVote(bot->GetGUID(), Guid, NumberOfPlayers, choice); - break; - default: - break; - } - - switch (rollType) - { - case ROLL_NEED: - bot->GetAchievementMgr().UpdateAchievementCriteria(ACHIEVEMENT_CRITERIA_TYPE_ROLL_NEED, 1); - break; - case ROLL_GREED: - bot->GetAchievementMgr().UpdateAchievementCriteria(ACHIEVEMENT_CRITERIA_TYPE_ROLL_GREED, 1); - break; - } - - } - return; + uint32 choice = urand(0,2); //returns 0,1,or 2 + + Player* const bot = it->second; + if(!bot) + return; + + Group* group = bot->GetGroup(); + if(!group) + return; + + group->CountRollVote(bot->GetGUID(), Guid, NumberOfPlayers, choice); + + switch (choice) + { + case ROLL_NEED: + bot->GetAchievementMgr().UpdateAchievementCriteria(ACHIEVEMENT_CRITERIA_TYPE_ROLL_NEED, 1); + break; + + case ROLL_GREED: + bot->GetAchievementMgr().UpdateAchievementCriteria(ACHIEVEMENT_CRITERIA_TYPE_ROLL_GREED, 1); + break; + } + } + return; + } /* Hope this helps!

Sorry guys, I found a small fault in my HasPet function. If the pet dies the conditional statement where the function is used is too ridge to allow the hunter to revive it. I believe I have solved this by broadening the query of the 'character_pet' table in HasPet() function. I have tested thiis for only a short time, and it seems to work. I suggest you test the patch first yourselves before commiting to github. HasPet update diff --git a/src/game/PlayerbotHunterAI.cpp b/src/game/PlayerbotHunterAI.cpp index c9829d3..0ca2fff 100644 --- a/src/game/PlayerbotHunterAI.cpp +++ b/src/game/PlayerbotHunterAI.cpp @@ -73,7 +73,7 @@ PlayerbotHunterAI::~PlayerbotHunterAI() {} bool PlayerbotHunterAI::HasPet(Player* bot) { - QueryResult* result = CharacterDatabase.PQuery("SELECT * FROM character_pet WHERE owner = '%u' AND slot = '%u'",bot->GetGUIDLow(),PET_SAVE_AS_CURRENT); + QueryResult* result = CharacterDatabase.PQuery("SELECT * FROM character_pet WHERE owner = '%u' AND (slot = '%u' OR slot = '%u')",bot->GetGUIDLow(),PET_SAVE_AS_CURRENT,PET_SAVE_NOT_IN_SLOT); if(result) return true; //hunter has current pet

LordPsyan identified a problem with his hunter bot continually whistling. His hunter had a pet, but it was stabled. The hunter bot can not determine this and so it tries over and over again to summon the pet. I have created a simple function 'bool HasPet(bot)' to query the character database, and determine whether the bot has a summonable pet or not. This function can be used in a conditional statement to prevent a summoning spell loop. I have created a patch for everyone to try out. You will be pleased to see that I no longer use the standard linux diff utility to create my patches, but the git diff utility. HasPet.patch diff --git a/src/game/PlayerbotHunterAI.cpp b/src/game/PlayerbotHunterAI.cpp index 2f01602..f366c65 100644 --- a/src/game/PlayerbotHunterAI.cpp +++ b/src/game/PlayerbotHunterAI.cpp @@ -71,6 +71,17 @@ PlayerbotHunterAI::PlayerbotHunterAI(Player* const master, Player* const bot, Pl PlayerbotHunterAI::~PlayerbotHunterAI() {} +PlayerbotHunterAI::bool HasPet(Player* bot) +{ + QueryResult* result = CharacterDatabase.PQuery("SELECT * FROM character_pet WHERE owner = '%u' AND slot = '%u'",bot->GetGUIDLow(),PET_SAVE_AS_CURRENT); + + if(result) + return true; //hunter has current pet + else + return false;//hunter either has no pet or stabled +}// end HasPet + + void PlayerbotHunterAI::DoNextCombatManeuver(Unit *pTarget) { PlayerbotAI* ai = GetAI(); @@ -280,7 +291,7 @@ void PlayerbotHunterAI::DoNonCombatActions() } // check for pet - if( PET_SUMMON>0 && !m_petSummonFailed ) + if( PET_SUMMON>0 && !m_petSummonFailed && HasPet(m_bot)) { // we can summon pet, and no critical summon errors before Pet *pet = m_bot->GetPet(); diff --git a/src/game/PlayerbotHunterAI.h b/src/game/PlayerbotHunterAI.h index 774e3f8..3434112 100644 --- a/src/game/PlayerbotHunterAI.h +++ b/src/game/PlayerbotHunterAI.h @@ -16,6 +16,7 @@ class MANGOS_DLL_SPEC PlayerbotHunterAI : PlayerbotClassAI public: PlayerbotHunterAI(Player* const master, Player* const bot, PlayerbotAI* const ai); virtual ~PlayerbotHunterAI(); + bool HasPet(Player* bot); // all combat actions go here void DoNextCombatManeuver(Unit*); Can I apologise to PostgreSQL users. I am not sure whether the query formats are compatible? I use MySQL and have created the database query to work with my server. If there is anyone familiar with MySQL and PostgreSQL, maybe they can post a translation for others. Cheers

Hi, I gather from one of your previous posts that your running quite a few other patches. These maybe effecting the bots response. Try running the server with only playerbot. If that works, add the others one by one and see if there is any change. Bots often disappear inside walls and trees, where you cannot follow. If they seem to get stuck, check that they aren't caught in combat. '/p orders' I have found that although there are no hostiles present, occasionally bot show up as being in combat. Don't logoff, just reset the bots '/p reset'.

Hi, Most strange. I usually use a player account to test. However I've just changed it to a 'gm' account, I tried '.tele goldshire' with bots summoned. All arrive and npc are spawned too. I tested with '.start' with the same results. I think something else might be causing your conflict. Keep me posted. My present system; MaNGOS: 8847 SD2:1504 PSMDB 267 Latest playerbot from github Latest auctionhousebot from github & autobroadcast I am not sure whether your hunter pet issue has anything to do with my recent pet feed patch. If your only pet is in the stables, the hunter may still try to summon it. Thus the whistling. It sound like a conditional statment needs to be added to the code, where pets are summoned ( if pet in stable do not summon). Occasionally bots go haywire, and the following usually shuts them up, '/w [bot] reset'. Hope this helps.

Hi, Are you using the recent submission on github? rrtn has only reversed the change I made in my last patch. To get the bots to spawn with you after teleport, PlayerbotAI.cpp requires the 'appendPackGUID' update. Cheers blueboy

Thanks for your kind words. Its nice to give something back occasionally, rather than sitting back , letting you guys do all the work;) I know the default: has 0 'cases' options before it. That was intentional. I was not quite sure which of the many loot methods required a need or greed roll. If none of the 'case' options apply, use the default:. Not the most conventional way of using a switch statement, I know. Also make sure that 'rollType' is changed to 'choice' in the second switch statement. I do not use the git diff utility to produce patches on my local machine. I only use git diff to create the main playerbot patch, from github. Patch creation I create two parallel dir paths, with roots 'a' and 'b'. 'a' contains original files and 'b' contains the changed files. I use the standard linux diff utility. diff -crB a/src/game b/src/game > my.patch The output differs from the git diff, but both resulting patches work with the 'patch' utility. I agree my patches are more verbose, but they do work. The '!' character might throw some people. It is not erroneous, it signifies line change rather, than '+' line addition or '-' line subtraction. I will make sure all future code submissions are contained within hello world! [code] bracketsCheers

Sorry, I'm new to this forum. Do you mean a link to the file? I do not have or a member of a ftp site (e.g pastebin), and my server is only on for part of the day. If getmangos.eu has means to store files, let me know? I know my messages can be longwinded, but that me P.S Is the code patch broken? I used the patch on my server before submitting this, and it worked. (copy & paste to file. Execute in source root, patch -p1 < my.patch) Cheers

I have a much better solution for the MSG_MOVE_TELEPORT_ACK issue, and one that does not cause the spawning issue on teleportation. I had narrowed the cause down to the data in the 'guid' variable, from HandleMoveTeleportAck(WorldPacket& recv_data) in MovementHandler.cpp. The player's data originates from the client, but the bots data is pass from PlayerbotAI::HandleTeleportAck(). I tried to use extractGUID from PlayrebotAI.cpp, and several other approaches without any success. In the end I looked for the definition of readPackGUID(guid), in the hope I could understand how the data was formatted. While examining this in ByteBuffer.h, I came across the associated sister function appendPackGUID(guid). This allows you to write 'guid' data to the world packet, Bingo! If vladimirmangos has used readPackGUID to resolve player teleportation issues, it make sense that appendPackGUID would work for Playerbot. What this means is that my recent fix needs to be reversed, and a small, but vital change made to PlayerbotAI.cpp. I have included the patch below so you can try, before you buy! I would hate this revision to be integrated into the github code, before it is fully tested by everyone. Hopefully this will be a long term solution. Teleportation patch: diff -crB a/src/game/MovementHandler.cpp b/src/game/MovementHandler.cpp *** a/src/game/MovementHandler.cpp 2009-11-21 05:10:29.000000000 +0000 --- b/src/game/MovementHandler.cpp 2009-11-21 05:15:51.000000000 +0000 *************** *** 175,181 **** uint64 guid; uint32 flags, time; ! recv_data >> guid; recv_data >> flags >> time; DEBUG_LOG("Guid " UI64FMTD, guid); DEBUG_LOG("Flags %u, time %u", flags, time/IN_MILISECONDS); --- 175,183 ---- uint64 guid; uint32 flags, time; ! if(!recv_data.readPackGUID(guid)) ! return; ! recv_data >> flags >> time; DEBUG_LOG("Guid " UI64FMTD, guid); DEBUG_LOG("Flags %u, time %u", flags, time/IN_MILISECONDS); diff -crB a/src/game/PlayerbotAI.cpp b/src/game/PlayerbotAI.cpp *** a/src/game/PlayerbotAI.cpp 2009-11-21 05:11:15.000000000 +0000 --- b/src/game/PlayerbotAI.cpp 2009-11-21 05:13:21.000000000 +0000 *************** *** 2401,2407 **** if (m_bot->IsBeingTeleportedNear()) { WorldPacket p = WorldPacket(MSG_MOVE_TELEPORT_ACK, 8 + 4 + 4); ! p << m_bot->GetGUID(); p << (uint32) 0; // supposed to be flags? not used currently p << (uint32) time(0); // time - not currently used m_bot->GetSession()->HandleMoveTeleportAck(p); --- 2401,2407 ---- if (m_bot->IsBeingTeleportedNear()) { WorldPacket p = WorldPacket(MSG_MOVE_TELEPORT_ACK, 8 + 4 + 4); ! p.appendPackGUID(m_bot->GetGUID()); p << (uint32) 0; // supposed to be flags? not used currently p << (uint32) time(0); // time - not currently used m_bot->GetSession()->HandleMoveTeleportAck(p);

I've had this issue for sometime. Using the gm command '.start' or using of hearthstone. I was wondering whether the bots teleporting to the master player, maybe the cause. Hovever, it also happens if no bots are present. I agree that this is a issue that should be addressed. MaNGOS: 8803 SD2:1498 PSMDB 266 Latest playerbot from github Latest auctionhousebot from github & autobroadcast I can reproduce the glitch, with debug info at the server. I got two of my characters to teleport (.start) to their homes. One long distance teleport and the other short. 1. Draenei Shaman, Goldshire to Azuremyst Isle was good with no glitch. Spell: Effect : 84 Spell Effect: Stuck Player Hans (guid 46) used auto-unstuck future at map 0 (-9381.839844, -103.833000, 60.792599) Player Hans is being teleported to map 530 Player Hans is being teleported to map 530 WORLD: got MSG_MOVE_WORLDPORT_ACK. CHARACTER: Sent Initial Spells Initializing Action Buttons for '46' Action Buttons for '46' Initialized Loading map /home/mangos/wow/maps/5303958.map VMAP loaded name:Outland, id:530, x:39, y:58 (vmap rep.: x:39, y:58) ------------------------------------------------------------------------ 2. Human Warlock, Westfall to Northshire with glitch, nothing spawning. Spell: Effect : 84 Spell Effect: Stuck Player Lane (guid 52) used auto-unstuck future at map 0 (-10531.400391, 1073.530029, 51.768650) Player Lane is being teleported to map 0 Player Lane is being teleported to map 0 MSG_MOVE_TELEPORT_ACK ERROR: Attempted to get in ByteBuffer (pos: 8 size: 10) value with size: 4 WorldSession::Update ByteBufferException occured while parsing a packet (opcode: 199) from client 192.168.2.100, accountid=13. Skipped packet. Dumping error causing packet: STORAGE_SIZE: 10 01 34 00 00 00 00 B9 E6 | 71 02 WORLD: Recvd MSG_MOVE_FALL_LAND (201, 0xC9) opcode Looks like a problem with the world packet while parsing opcode (199), (transfering data from packet to associated variables). Opcodes.cpp: /*0x0C7*/ { "MSG_MOVE_TELEPORT_ACK", STATUS_LOGGEDIN, &WorldSession::HandleMoveTeleportAck }, Opcodes.h: MSG_MOVE_TELEPORT_ACK = 0x0C7, (199) I hate to say this, but I might have been partly responsible for this issue, with my recent fix. Using recv_data >> guid; allows bots to be summoned to master location (No MSG_MOVE_TELEPORT_ACK loop at server). However, player Near teleport(2) glitch occurs, requiring a logout & login. Player Far teleport(1) doesn't appear to be effected. or if(!recv_data.readPackGUID(guid)) return; allows players to teleport without glitch, but bots get lost in transist and server gets caught in a MSG_MOVE_TELEPORT_ACK loop. vladimirmangos made this change to the MaNGOS code [8601], to resolve player teleport issues. No consideration was made for playerbot. Until this issue is resolved, you can either use my fix or do without bots. Hopefully, now I have identified the issue, someone can come up with a long term solution.

Hi Roflnap, Sorry for any misunderstanding on my part. In truth, if I had seen your solution first, I would never had written mine I didn't think 'bind on pickup' items were offered on need or greed rolls? I am sure your aware that the random feature of my patch can be changed. Can you set 'Master looter' as the default loot method at the client? I have just found something which may help you use 'Master Looter' as the default loot method, In GroupHandler.cpp there is a function HandleLootMethodOpcode( WorldPacket & recv_data ) this checks for group membership and set the loot method with info from the client. Rather than accept the client choice, you could force your own 'lootMethod' at the server. Hope this helps! My next project will be to try and improve the bot interaction with certain quests. It's a real pain to login in and out, for every bot, each time a quest item requires 'selection' to recover, (i.e opening a chest to get the item). I know some quests provide copies of an item to each looters. If you got any ideas, I would be grateful:)

I believe it is important to strive to improve the AI realism of playerbot. roflnap's suggestion got me thinking about my submission. If the bots were outside the interaction distance to loot a corpse, would they be included in the roll or not? Often bots are waylaid by combat, during player flight. I as a player would not expect to gain, if a roll was required on a npc corpse in this situation. I was concerned because in my patch all group members are considered. Should I include a conditional statement, to exclude absent bots? Test I tested this by first assembling a group. I then instructed one bot to '/w [bot] stay'. The remainder of the group then went off plundering. Eventually a corpse required a need or greed roll. Interestly the client intelligently identifies the reduced number in the group, and excludes the bot left behind from the roll. No addition code is required to handle this. I have revised my patch to handle all loot methods, requiring a roll. As 'default:' in the GetLootMethod() switch statement. In addition, I had ommited to change the value supplied to the GetAchievementMgr() switch statement. There are two achievement milestones in the game, 'NEEDY' and 'GREEDY'. If these are not updated correctly then individual bots will not get the credit they are due. The value in the 'rollType' variable represents the chioce made by the player and not the bot. I have changed this to the bot's choice. Revision to previous patch diff -crB a/src/game/PlayerbotMgr.cpp b/src/game/PlayerbotMgr.cpp *** a/src/game/PlayerbotMgr.cpp 2009-11-18 16:23:32.000000000 +0000 --- b/src/game/PlayerbotMgr.cpp 2009-11-18 16:26:01.000000000 +0000 *************** *** 308,332 **** switch (group->GetLootMethod()) { ! case GROUP_LOOT: ! // bot random roll ! group->CountRollVote(bot->GetGUID(), Guid, NumberOfPlayers, choice); ! break; ! case NEED_BEFORE_GREED: ! choice = 1; ! // bot need roll ! group->CountRollVote(bot->GetGUID(), Guid, NumberOfPlayers, choice); ! break; ! case MASTER_LOOT: ! choice = 0; ! // bot pass on roll ! group->CountRollVote(bot->GetGUID(), Guid, NumberOfPlayers, choice); ! break; default: break; } ! switch (rollType) { case ROLL_NEED: bot->GetAchievementMgr().UpdateAchievementCriteria(ACHIEVEMENT_CRITERIA_TYPE_ROLL_NEED, 1); --- 308,322 ---- switch (group->GetLootMethod()) { ! //case GROUP_LOOT: ! //case NEED_BEFORE_GREED: ! //case MASTER_LOOT: default: + group->CountRollVote(bot->GetGUID(), Guid, NumberOfPlayers, choice); break; } ! switch (choice) { case ROLL_NEED: bot->GetAchievementMgr().UpdateAchievementCriteria(ACHIEVEMENT_CRITERIA_TYPE_ROLL_NEED, 1); P.S In response to roflnap's messege. I am sorry if you don't like my approach to group loot. You can either delete my addition or set 'choice' variable to zero, so the bots pass on everything. As I pointed out in my original message, if you loose out on a roll, you can always get the item back later by trading with the bots. Another advantage to my method is that the bots act as additional baggage.

Interesting! Correct me if I'm wrong, your method bypasses the bots on a NEED or GREED roll altogether. I thought it would be nice if the bots appeared to interact with the roll process. As far as I know the patch works 100% I have included NEED before GREED, and MASTER loot options, although this maybe redundant code. Master loot option does not require a roll? My patch is a prototype, and I'm sure it could be improved. Thanks for your contribution, I'll try it out on my server.

Overview Is anyone tired of using 'Master Looter' as the default loot method. I create bot guilds and it is a real pain to dish out the booty to my bot groups, slowing the adventuring right down. I have created a patch to randomly decide NEED or GREED for each of the bots. The rolls are returned almost immediately, for each item being rolled for! Advantages No need to change the looting method each time you log on, and never loose a unique item because you forgot to make the change. If you loose the roll, get it back by trading with the bots. They are most accommodating.... How it works The patch intercepts the CMSG_LOOT_ROLL from the client. When a NEED or GREED dialog box pops up, you make your choice, and this is captured at the server. There is a random choice made for each bot and each item being rolled for. This is then passed to the CountRollVote function. That's it! Many thanks to rrtn for his work in commiting my last patch: Pet feeding for hunters. Here is the patch, diff -crB a/src/game/PlayerbotMgr.cpp b/src/game/PlayerbotMgr.cpp *** a/src/game/PlayerbotMgr.cpp 2009-11-16 22:11:49.000000000 +0000 --- b/src/game/PlayerbotMgr.cpp 2009-11-16 22:16:02.000000000 +0000 *************** *** 280,286 **** } return; } ! /* case CMSG_NAME_QUERY: case MSG_MOVE_START_FORWARD: case MSG_MOVE_STOP: --- 280,347 ---- } return; } ! ! case CMSG_LOOT_ROLL: ! { ! ! WorldPacket p(packet); //WorldPacket packet for CMSG_LOOT_ROLL, (8+4+1) ! uint64 Guid; ! uint32 NumberOfPlayers; ! uint8 rollType; ! p.rpos(0); //reset packet pointer ! p >> Guid; //guid of the item rolled ! p >> NumberOfPlayers; //number of players invited to roll ! p >> rollType; //need,greed or pass on roll ! ! ! for (PlayerBotMap::const_iterator it = GetPlayerBotsBegin(); it != GetPlayerBotsEnd(); ++it) ! { ! ! uint32 choice = urand(0,2); //returns 0,1,or 2 ! ! Player* const bot = it->second; ! if(!bot) ! return; ! ! Group* group = bot->GetGroup(); ! if(!group) ! return; ! ! switch (group->GetLootMethod()) ! { ! case GROUP_LOOT: ! // bot random roll ! group->CountRollVote(bot->GetGUID(), Guid, NumberOfPlayers, choice); ! break; ! case NEED_BEFORE_GREED: ! choice = 1; ! // bot need roll ! group->CountRollVote(bot->GetGUID(), Guid, NumberOfPlayers, choice); ! break; ! case MASTER_LOOT: ! choice = 0; ! // bot pass on roll ! group->CountRollVote(bot->GetGUID(), Guid, NumberOfPlayers, choice); ! break; ! default: ! break; ! } ! ! switch (rollType) ! { ! case ROLL_NEED: ! bot->GetAchievementMgr().UpdateAchievementCriteria(ACHIEVEMENT_CRITERIA_TYPE_ROLL_NEED, 1); ! break; ! case ROLL_GREED: ! bot->GetAchievementMgr().UpdateAchievementCriteria(ACHIEVEMENT_CRITERIA_TYPE_ROLL_GREED, 1); ! break; ! } ! ! } ! return; ! } ! ! /* case CMSG_NAME_QUERY: case MSG_MOVE_START_FORWARD: case MSG_MOVE_STOP: execute above patch in source root, patch -p1 < my.patch

Symptom: Bots would not teleport to the master. When forced with the 'follow' command, the client would say '[bot] is already being teleported, could not teleport'. Meanwhile the server would be going ballistic with MSG_MOVE_TELEPORT_ACK, over and over again. Solution: I have been using a patch to reverse a change made by vladimirmangos in [8601] (Fixed some movement *_ACK packets structure after switch). The fix appears to alter the way 'guid' is read from the world packet. Before; this value was transferred from the packet pointer (recv_data) thus recv_data >> guid; After [8601] this disappeared, and was replaced by if(!recv_data.readPackGUID(guid)) return; Interestly in most functions 'guid' is not used, but in HandleMoveTeleportAck(WorldPacket& recv_data) it is. Further more, no mention of a change to this function is recorded in the commit. I placed flags in this function to monitor values of 'guid' and identify what was happening. Inside the function there is a conditional statement, if(guid != plMover->GetGUID()) return; If the 'guid' does not match the guid of the bot being teleported, then it will exit the function. In the changed function 'guid' value is always zero so the condition is always met. The result is that the teleport is never completed. I reversed the change and hey presto!, all of my bots arrived at the master location. I have been using this patch since [8601] and have yet to see a reversal to the code in either the ManGOS core, or the playerbot branch. I have posted here because this isssue may only effect playerbot systems. If this is useful, maybe someone will intergrate the patch as a commit to the playerbot code. Change to HandleMoveTeleportAck in MovementHandler.cpp; diff -crB a/src/game/MovementHandler.cpp b/src/game/MovementHandler.cpp *** a/src/game/MovementHandler.cpp 2009-10-12 21:40:50.000000000 +0100 --- b/src/game/MovementHandler.cpp 2009-10-12 21:50:13.000000000 +0100 *************** *** 173,183 **** { sLog.outDebug("MSG_MOVE_TELEPORT_ACK"); uint64 guid; - - if(!recv_data.readPackGUID(guid)) - return; - uint32 flags, time; recv_data >> flags >> time; DEBUG_LOG("Guid " UI64FMTD, guid); DEBUG_LOG("Flags %u, time %u", flags, time/IN_MILISECONDS); --- 173,181 ---- { sLog.outDebug("MSG_MOVE_TELEPORT_ACK"); uint64 guid; uint32 flags, time; + + recv_data >> guid; recv_data >> flags >> time; DEBUG_LOG("Guid " UI64FMTD, guid); DEBUG_LOG("Flags %u, time %u", flags, time/IN_MILISECONDS); Execute patch in source root directory as follows, patch -p1 < my.patch