blueboy

Hi Guys, In response to a popular request, I have created the Repair patch, for you to test. The patch allows you to repair only group member bots, as the player repairs. To exclude bot(s) from repair, temporarily uninvite bot(s) from group. # Normal repair, paid for by individual bot # Guild repair, paid by the guild bank Limitations. As the repair 'anvil' has to be active on the client, to allow selection. If the player does not require repair or has no money, you can not repair bot(s). It is not practical to allow bot(s) to repair individual items, as the player can. But you can't have everything :rolleyes: The patch is designed to work with small groups, where the bot(s) are close enough to the player & NPC, to interact. Revised Repair patch diff --git a/src/game/PlayerbotMgr.cpp b/src/game/PlayerbotMgr.cpp index c66b483..3feae0d 100644 --- a/src/game/PlayerbotMgr.cpp +++ b/src/game/PlayerbotMgr.cpp @@ -9,6 +9,7 @@ #include "GossipDef.h" #include "Chat.h" #include "Language.h" +#include "Guild.h" class LoginQueryHolder; class CharacterHandler; @@ -323,8 +324,73 @@ void PlayerbotMgr::HandleMasterIncomingPacket(const WorldPacket& packet) } return; } + case CMSG_REPAIR_ITEM: + { + WorldPacket p(packet); // WorldPacket packet for CMSG_REPAIR_ITEM, (8+8+1) + sLog.outDebug("PlayerbotMgr: CMSG_REPAIR_ITEM"); + + uint64 npcGUID, itemGUID; + uint8 guildBank; + + p.rpos(0); //reset packet pointer + p >> npcGUID; + p >> itemGUID; // Not used for bot but necessary opcode data retrieval + p >> guildBank; // Flagged if guild repair selected + + for (PlayerBotMap::const_iterator it = GetPlayerBotsBegin(); it != GetPlayerBotsEnd(); ++it) + { + + Player* const bot = it->second; + if(!bot) + return; + + Group* group = bot->GetGroup(); // check if bot is a member of group + if(!group) + return; + + Creature *unit = bot->GetNPCIfCanInteractWith(npcGUID, UNIT_NPC_FLAG_REPAIR); + if (!unit) // Check if NPC can repair bot or not + { + sLog.outDebug("PlayerbotMgr: HandleRepairItemOpcode - Unit (GUID: %u) not found or you can't interact with him.", uint32(GUID_LOPART(npcGUID))); + return; + } + + // remove fake death + if(bot->hasUnitState(UNIT_STAT_DIED)) + bot->RemoveSpellsCausingAura(SPELL_AURA_FEIGN_DEATH); + + // reputation discount + float discountMod = bot->GetReputationPriceDiscount(unit); + + uint32 TotalCost = 0; + if (itemGUID) // Handle redundant feature (repair individual item) for bot + { + sLog.outDebug("ITEM: Repair single item is not applicable for %s",bot->GetName()); + continue; + } + else // Handle feature (repair all items) for bot + { + sLog.outDebug("ITEM: Repair all items, npcGUID = %u", GUID_LOPART(npcGUID)); + + TotalCost = bot->DurabilityRepairAll(true,discountMod,guildBank>0?true:false); + } + if (guildBank) // Handle guild repair + { + uint32 GuildId = bot->GetGuildId(); + if (!GuildId) + return; + Guild *pGuild = sObjectMgr.GetGuildById(GuildId); + if (!pGuild) + return; + pGuild->LogBankEvent(GUILD_BANK_LOG_REPAIR_MONEY, 0, bot->GetGUIDLow(), TotalCost); + pGuild->SendMoneyInfo(bot->GetSession(), bot->GetGUIDLow()); + } + + } + return; + } /* case CMSG_NAME_QUERY: case MSG_MOVE_START_FORWARD: EDIT: Sorry I left a reference to the Guild header file out of the patch. I have revised the above patch. Hope you like it, and once again please give constructive feedback

Hi, No crash, is good news. Let's hope it stays that way. As far as the priest is concerned, mana is not expended for nothing. The priest is just doing its job. 'Power Word: Fortitude' AURA is cast on all members of the group every 16 minutes, as it runs out. If the group is very large, then I am not surprised the mana runs out too. As I said in my last post, there are no distance restrictions on non aggressive spells. For small groups, distance is not an issue. However, I appreciate with your raid group scenario it would. I shall see if I can add a distance check, which will exclude remote group members. Cheers

Hi Guys, RE: In response to a question about priest bots causing a server crash, whilst casting HEAL on group members, out of sight Thanks to mrelfire, I have taken a closer look at the code. I have found several logic errors in PlayerbotPriestAI.cpp, related to the following spells (Auras) prayer of fortitude power word: fortitude prayer of spirit divine spirit In the function uint32 PlayerbotAI::getSpellId(const char* args, bool master) const You will note that the value returned is of type uint32 and not bool. However, it is used frequently in boolean expressions thus; If SpellId is not found, then the returned value = zero (or false) If found, it will return a positive non-zero Spellid (or true) I found the following Incorrectly the following test is used, return value == 1 (never true) and this should be, return value > 0 I must admit, it is rare that I run with a group larger than about 5. Who knows how raid groups will behave with the Playerbot AI and what effect they would have on the servers performance (recent freeze issue). I have briefly looked at the code and distance restrictions on casting spells seem only to be placed on aggressive spells. I can't imagine that the absence of a group member would have such a catastrophic effect on the server. RE: In response to an ongoing issue, linked to HasAura, that causes mrelfire 's server to repeatedly crash I have also added a condition to HasAura to handle the possible situation where a spellId might be zero or less. bool PlayerbotAI::HasAura(uint32 spellId, const Unit& player) const { if(spellId <= 0) return false; for (Unit::AuraMap::const_iterator iter = player.GetAuras().begin(); iter != player.GetAuras().end(); ++iter) { if (iter->second->GetId() == spellId) return true; } return false; } this may help, we'll have to try it. I will update the code on blueboy shortly. Hope this helps

Hi eqhugo, Thanks very much for your contribution. I'll give it a try shortly. Cheers

Hi Guys, There seems to be activity in core development to restructure the character database. 9630_01_characters_characters.sql you will be aware of the demise of the data field. You will note that the data has been shifted to a new table called data_backup. Some of the data has already been redirected to three new fields highlighted below. What this means is a massive headache to developers of third party addons (mods like auctionhousebot, playerbot and account management systems such as MiniManager). This migration of data is ongoing so be prepared for alot of upset. I advise you to backup your existing databases and be reluctant to upgrade MaNGOS until they have finished messing about. As fast as we find fixes, they will cause more issues by changing things again :mad: Hope this helps

Hi, Point is, why did they stop using MinimalLoadFromDB in the core? Perhaps there is a better solution There was just a chance you might have missed the maxitem setting;). Have you logged on with the 'auction guy' [/b,]they do suggest you do this at least once. I've been trying to upgrade ACE libs for windows (Upgrade works fine with linux), to help towards the freeze issue, but ServiceWin32.cpp does not like the change. The ServiceMain function may haveto be rewritten. With this present problem I will put that on hold. I have also tried updating the MySQL header files (These are quite old, and almost certainly will have been revised). More info to throw into the pile. Cheers

Hi, Have you changed the maxitem field in auctionhousebot table (character database). The default is zero, so nothing will be added to the auctionhouse. I set the value for all auctionhouses (Horde,Alliance,Neutral) to 500. They remove the data field from the character database in the latest sql update 9630_01_characters_characters.sql. I counted myself one of the lucky few, as I wasn't effected by the recent freeze issue, being on linux. However, auctionhousebot now causes both my servers (windows (32bit) and linux) to crash. Interestingly, MinimalLoadFromDB( QueryResult *result, uint32 guid ) was removed from the core code ages ago, and is only maintained now by auctionhousebot. Maybe if we looked at the alternative used in the core, we could apply this to auctionohousebot. Just a thought. Cheers

Hi Guys, They have been renaming things again :rolleyes: and have missed one! MaNGOS[9630] & [9631] There is a typo in LootMgr.cpp that prevents compilation in Windows. Suprisingly the error is not flagged on linux The enum declaration has been changed in World.h You will notice the 'L' highlighted above, this has to be changd to lowercase. EDIT They have fixed it in MaNGOS[9632] Hope this helps

Hi, Thanks for your contribution, but I'm a littlie puzzled as to what it does. I found the location where your patch should be inserted (HandlePlayerbotCommand in PlayerbotMgr.cpp, where bot(s) are summoned or added to the player's world session) Following your code this prevents mixed teams (HORDE & ALLIANCE) 1. Setup a pointer to the players world session. 2. Test whether the player's team faction is different from the team faction of the bot, you are trying to summon. 3. If different, send warning to the client, and return true ? (Shouldn't this be false) Thanks again

Hi Guys, I've just updated the code on blueboy as promised. I have tested the code with MaNGOS[9614] & ScriptDev2[1653] and it compiles and runs without issue :rolleyes: The code now includes the gmconfig.patch and I have fixed several compiler warnings. Finally, I have fixed an issue in DoLoot function that was causing to appear on Windows servers, as bot(s) loot. Hope this helps

Hi, Thanks for the information, yes I'm seeing these as I'm compiling on my XP (32bit) box. You will appreciate that warnings happen , and are generally ignored. However they are flagged for a good reason, to discourage sloppy coding. I will take a look at these, and hopefully eliminate them. As a side issue, I have cleared up an ugly warning that was popping up on the server (Windows only) as the bots loot. I tracked the cause of this down to a condition statement in the DoLoot function in PlayerbotAI.cpp. This assigned a phantom loot guid value used to release the loot. I have now corrected this by passing a real value. Keep on Trucking EDIT: I have now removed all compile warnings caused by playerbot code:rolleyes: I will update blueboy shortly, with the changes I have made

Hi, I wish I could get it to freeze! :confused: what! No what I mean to say is that I wish I could have the problem on my server, so I could be more pro-active in solving it. I believe that DaemonCantor is on to a lead with MySQL. I'm waiting to hear if he has some news. Cheers

Hi, I'm glad you got it to work. Out of interest, what was the solution? Sorry if I might have seemed abrupt in my reply, it was not intended Cheers

Hi, Interesting, most of the data is loaded into memory at server startup for MaNGOS, but I can see that auctionhousebot would have need to access the DB server on a regular basis. If it is any help, blueboy code , with fix for addition of Mail.h in Player.cpp MaNGOS[9612] ScriptDev2[1652] PSMDB[299] Silvermoon database auctionhousebot[Naicisum] latest, with fix for addition of Mail.h in AuctionHouseHandler.cpp autobroadcast[Xeross] old Run on a Dell with XP Windows (32 bit) MySQL 5.1.36 run on my linux box, and accessed remotely! I get no lag or freeze and everything appears fine. Edit: I have just checked which ENGINES are used for the MaNGOS database and auctionhousebot, on my system All use MyISAM, except the character & auctionhousebot tables that use InnoDB Hear from you soon

Hi, Thanks, but I have held off updating the repo to the latest MaNGOS until we get this issue sorted out. I know the code on blueboy works fine on all commits upto 9612, as I have tested them myself. blueboy MaNGOS[9591] tested with Windows & linux MaNGOS[9591] to [9612] tested with linux The detect.patch and get.patch add optional features that should not have a bearing on the normal operation of the server. If you do not use them, they are not needed. Although I do not provide direct support for auctionhousebot(Naicisum repo), it is an important addition, that I believe we must all fix. For my part going to test each commit of MaNGOS, unitl I find what is causing this issue, that appears to only effect Windows. Unlike other repos, I like to keep blueboy clean & simple (i.e Playerbot & MaNGOS only). I am curious to know what this 'Item Duration' patch is? Thanks for your help in resolving this issue

Hi, This might sound like a stupid question, but does your player account, have a character called Mystic? The bot character must come from the same account as the player (i.e The account must have at less two characters, one used as the player and the remaining unused characters (max 9) can be summoned as bots). I have tested the syntax of the bot command as used by you, and it works fine. Let me know

Hi, I'm presently running the code from blueboy with MaNGOS[9591] ScriptDev2[1641] PSMDB[299] auctionhousebot[Niacisum] latest autobroadcast[Xeross]old detect.patch get.patch On a Dell with Windows XP (32bit) Compiled with VC++ 2008 and it compiles & runs perfectly. I understand that this issue occurs on builds using MaNGOS[9606+]. I will soak test this for a day and then try a later version of MaNGOS, until I get an issue. Could you guys build a server as I have done above and confirm that it works, then we can press on. I have already explained in a previous post #857, that Looking For Dungeon is because of a new feature on the client, that is not yet supported by MaNGOS servers. The client is asking for information, the server does not respond, thus the error. It is safe to ignoreHope this helps

Hi, To pinpoint what is causing your issue, I suggest you step back to an earlier version of MaNGOS known to work, and test with each of your mods. If it works, test again with each MaNGOS commit until we track down what is causing the freeze. Naicisum's repo has not been updated for over a month, and I gather it has issues. I am not experiencing any issues on my linux box, but I will try the same on my windows box. Cheers

Hi, If your server doesn't freeze at all, I can't explain why all your clients are freezing at the same time. It certainly sounds like a network bottle neck. Nothing that I have changed with Playerbot would have such an effect. Have you tried disabling auctionhousebot like DaemonCantor suggests? I last updated the code on blueboy last Tuesday (16th March), and that was just a cosmetic change. Cheers

O.K, Thanks for clarifying. The original post did not make this clear. If all your clients are freezing at the same time, that does suggest that the server is not responding (unduly busy). If the server has not frozen, do the clients work again if left, or do they remain frozen? Have you tried DaemonCantor's, suggestion of disabling auctionhousebot mod in 'mangosd.conf'? Cheers

Hi mrelfire, I haven't forgotten your aura issue. I have now managed to build a server on Windows. I haven't had any problems yet, but then again I do not have much time to play :-( Your server probably has a higher population, to stress it out! The box I built the server on is quite modest (i.e 32bit), I know your using a 64bit box. This might have a bearing. Everyone If any of you apart from mrelfire & Bramm are having issues with HasAura, please let me know. Cheers

Hi, When you say it freezes, is this as the server loads or when you try to logon? I have had some issues myself with this recently, at logon; after creating a new build. First issue Second Issue Hard to pinpoint what is causing these issues, particularly if your using many mods in combination. Hope this helps

Hi Guys, As promised here is the initial release of the get.patch. This patch works in conjunction with the previous survey.patch, that must be applied to the playerbot code first. It is quite simple to use, allowing bot(s) to loot gameobjects for quest items (e.g Milly's Harvest). /w <botname> get <link string> item is retrieved for single bot. /p get <link string> item is retrieved for one bot at a time, in party. I have now overcome the remote looting issue, that prevented bot(s) from looting the object, far from the player. The player can now remain a safe distance from the object (Like all good Generals), or go in close with the bot(s). diff --git a/src/game/PlayerbotAI.cpp b/src/game/PlayerbotAI.cpp index 091a14f..e915cce 100644 --- a/src/game/PlayerbotAI.cpp +++ b/src/game/PlayerbotAI.cpp @@ -2762,6 +2762,99 @@ void PlayerbotAI::HandleCommand(const std::string& text, Player& fromPlayer) SendWhisper("I have no info on that object", fromPlayer); } + // Get project: 15:40 22/03/10 rev.1 allows bots to loot gameobjects for quest items + else if (text.size() > 2 && text.substr(0, 2) == "g " || text.size() > 4 && text.substr(0, 4) == "get ") + { + uint32 guid; + float x,y,z; + uint32 entry; + int mapid; + if(extractGOinfo(text, guid, entry, mapid, x, y, z)) + { + + //sLog.outDebug("find: guid : %u entry : %u x : (%f) y : (%f) z : (%f) mapid : %d",guid, entry, x, y, z, mapid); + m_lootCurrent = MAKE_NEW_GUID(guid, entry, HIGHGUID_GAMEOBJECT); + GameObject *go = m_bot->GetMap()->GetGameObject(m_lootCurrent); + if(!go) + { + m_lootCurrent = 0; + return; + } + SetState(BOTSTATE_LOOTING); + m_bot->UpdateGroundPositionZ(x,y,z); + m_bot->GetMotionMaster()->MovePoint( mapid, x, y, z ); + m_bot->SetPosition(x, y, z, m_bot->GetOrientation()); + m_ignoreAIUpdatesUntilTime = time(0) + 5; + m_bot->SendLoot( m_lootCurrent, LOOT_CORPSE ); + Loot *loot = &go->loot; + uint32 lootNum = loot->GetMaxSlotInLootFor( m_bot ); + //sLog.outDebug( "[PlayerbotAI]: GetGOType %u - %s looting: '%s' got %d items", go->GetGoType(), m_bot->GetName(), go->GetGOInfo()->name, loot->GetMaxSlotInLootFor( m_bot )); + for( uint32 l=0; l<lootNum; l++ ) + { + QuestItem *qitem=0, *ffaitem=0, *conditem=0; + LootItem *item = loot->LootItemInSlot( l, m_bot, &qitem, &ffaitem, &conditem ); + if( !item ) + continue; + + if( !qitem && item->is_blocked ) + { + m_bot->SendLootRelease( m_lootCurrent ); + continue; + } + + if( m_needItemList[item->itemid]>0 ) + { + ItemPosCountVec dest; + if( m_bot->CanStoreNewItem( NULL_BAG, NULL_SLOT, dest, item->itemid, item->count ) == EQUIP_ERR_OK ) + { + Item * newitem = m_bot->StoreNewItem( dest, item->itemid, true, item->randomPropertyId); + + if( qitem ) + { + qitem->is_looted = true; + if( item->freeforall || loot->GetPlayerQuestItems().size() == 1 ) + m_bot->SendNotifyLootItemRemoved( l ); + else + loot->NotifyQuestItemRemoved( qitem->index ); + } + else + { + if( ffaitem ) + { + ffaitem->is_looted=true; + m_bot->SendNotifyLootItemRemoved( l ); + } + else + { + if( conditem ) + conditem->is_looted=true; + loot->NotifyItemRemoved( l ); + } + } + if (!item->freeforall) + item->is_looted = true; + --loot->unlootedCount; + sLog.outDebug( "[PlayerbotAI]: %s looting: needed item UpdateAchievementCriteria", m_bot->GetName()); + m_bot->SendNewItem( newitem, uint32(item->count), false, false, true ); + m_bot->GetAchievementMgr().UpdateAchievementCriteria( ACHIEVEMENT_CRITERIA_TYPE_LOOT_ITEM, item->itemid, item->count ); + } + } + } + // release loot + m_bot->GetSession()->DoLootRelease( m_lootCurrent ); + + // clear movement target, take next target on next update + m_bot->GetMotionMaster()->Clear(); + m_bot->GetMotionMaster()->MoveIdle(); + sLog.outDebug( "[PlayerbotAI]: %s looted target 0x%08X", m_bot->GetName(), m_lootCurrent ); + SetState(BOTSTATE_NORMAL); + SetQuestNeedItems(); + m_lootCurrent = 0; + } + else + SendWhisper("I have no info on that object", fromPlayer); + } + else if (text == "quests") { bool hasIncompleteQuests = false; Hope you like it, and please provide feedback

Hi, Thanks for the suggestion. It makes sense to include guild repair, if available. Cheers

Hi, Thanks for the suggestions, keep them coming I will tackle them if and when I can. I will shortly post the get.patch which will update the survey.patch, to allow you to complete collection type quests. Eventually, I want the get command to also direct bots to mill, mine and loot game objects. I have not forgotten the suggestion to repair bots, I will now take a look at this Thanks again