blueboy

Hi sunnyqeen, Thanks for the patch. I agree that it would nice for the bots to learn new flight nodes, even if the master is only enquiring about flight. It is important to use an opcode that will only be triggered when the player selects the flightmaster. I have checked the incoming opcodes stream, as the player activates the flightmaster and I get CMSG_GOSSIP_HELLO and CMSG_TAXINODE_STATUS_QUERY (the opcode CMSG_TAXIQUERYAVAILABLENODES is not sent). CMSG_TAXINODE_STATUS_QUERY is not suitable, as it is not triggered by flightmaster activation. It is triggered if the player gets near to a flight node (i.e every node during flight, so the bots would learn new nodes as they flew ). The only possibility would be to use the CMSG_GOSSIP_HELLO opcode. The problem here is that it's a general opcode used for any NPC activation. If we were to utilize this, it would be necessary to make the code adaptable for other types of NPC. I have modified the code in your patch to make it more granular, to allow for this. I also found that currently CMSG_GOSSIP_HELLO & CMSG_QUESTGIVER_HELLO are not being used correctly, to enable bots to turn in quests. CMSG_QUESTGIVER_HELLO does not appear to be sent at all, when the player turns in a quest. Further with CMSG_GOSSIP_HELLO, bots were checking all NPCs selected by the player. I have replaced these with CMSG_QUESTGIVER_COMPLETE_QUEST instead. I have included several dumby options for you to test the codes functionality. You can remove these if not required or just comment them out. I will update the flight branch shortly, but here is the revised patch for you to try; EDIT: Since posting the patch below, I have found problems with bots turning in quests, as the player does. The problem stems from the use of CMSG_QUESTGIVER_COMPLETE_QUEST. I realise now, that CMSG_QUESTGIVER_HELLO is the best way, and I will update the flight branch accordingly. diff --git a/src/game/playerbot/PlayerbotMgr.cpp b/src/game/playerbot/PlayerbotMgr.cpp index 07b9be8..25622b5 100644 --- a/src/game/playerbot/PlayerbotMgr.cpp +++ b/src/game/playerbot/PlayerbotMgr.cpp @@ -401,9 +401,7 @@ void PlayerbotMgr::HandleMasterIncomingPacket(const WorldPacket& packet) } break; - // if master talks to an NPC - case CMSG_GOSSIP_HELLO: - case CMSG_QUESTGIVER_HELLO: + case CMSG_QUESTGIVER_COMPLETE_QUEST: { WorldPacket p(packet); p.rpos(0); // reset reader @@ -501,6 +499,76 @@ void PlayerbotMgr::HandleMasterIncomingPacket(const WorldPacket& packet) } return; } + // Handle GOSSIP activate actions, prior to GOSSIP select menu actions + case CMSG_GOSSIP_HELLO: + { + DEBUG_LOG("PlayerbotMgr: Received CMSG_GOSSIP_HELLO"); + + WorldPacket p(packet); //WorldPacket packet for CMSG_GOSSIP_HELLO, (8) + ObjectGuid guid; + p.rpos(0); //reset packet pointer + p >> guid; + + for (PlayerBotMap::const_iterator it = GetPlayerBotsBegin(); it != GetPlayerBotsEnd(); ++it) + { + Player* const bot = it->second; + if (!bot) + return; + + Creature *pCreature = bot->GetNPCIfCanInteractWith(guid, UNIT_NPC_FLAG_NONE); + if (!pCreature) + { + DEBUG_LOG("PlayerbotMgr: HandleGossipHelloOpcode - %s not found or you can't interact with him.", guid.GetString().c_str()); + return; + } + + GossipMenuItemsMapBounds pMenuItemBounds = sObjectMgr.GetGossipMenuItemsMapBounds(pCreature->GetCreatureInfo()->GossipMenuId); + for(GossipMenuItemsMap::const_iterator itr = pMenuItemBounds.first; itr != pMenuItemBounds.second; ++itr) + { + uint32 npcflags = pCreature->GetUInt32Value(UNIT_NPC_FLAGS); + + if (!(itr->second.npc_option_npcflag & npcflags)) + continue; + + switch(itr->second.option_id) + { + case GOSSIP_OPTION_TAXIVENDOR: + { + bot->GetPlayerbotAI()->TellMaster("PlayerbotMgr:GOSSIP_OPTION_TAXIVENDOR"); + bot->GetSession()->SendLearnNewTaxiNode(pCreature); + break; + } + case GOSSIP_OPTION_VENDOR: + { + bot->GetPlayerbotAI()->TellMaster("PlayerbotMgr:GOSSIP_OPTION_VENDOR"); + break; + } + case GOSSIP_OPTION_STABLEPET: + { + bot->GetPlayerbotAI()->TellMaster("PlayerbotMgr:GOSSIP_OPTION_STABLEPET"); + break; + } + case GOSSIP_OPTION_AUCTIONEER: + { + bot->GetPlayerbotAI()->TellMaster("PlayerbotMgr:GOSSIP_OPTION_AUCTIONEER"); + break; + } + case GOSSIP_OPTION_BANKER: + { + bot->GetPlayerbotAI()->TellMaster("PlayerbotMgr:GOSSIP_OPTION_BANKER"); + break; + } + case GOSSIP_OPTION_INNKEEPER: + { + bot->GetPlayerbotAI()->TellMaster("PlayerbotMgr:GOSSIP_OPTION_INNKEEPER"); + break; + } + } + } + } + return; + } + case CMSG_REPAIR_ITEM: { @@ -840,7 +908,8 @@ void PlayerbotAI::GetTaxi(ObjectGuid guid, std::vector<uint32>& nodes) } if(m_bot->m_taxi.IsTaximaskNodeKnown(nodes[0]) ? 0 : 1) - m_bot->GetSession()->SendLearnNewTaxiNode(unit); + return; + // m_bot->GetSession()->SendLearnNewTaxiNode(unit); if(m_bot->m_taxi.IsTaximaskNodeKnown(nodes[nodes.size()-1]) ? 0 : 1) return; The later part of this patch (@@ -840,7 +908,8 @@ void PlayerbotAI::GetTaxi) is only necessary if you are using the code from the flight branch. Thanks for your interest in playerbot and for drawing these issues to my attention. Hope this helps

blueboy needs your help..please I should have left things the way they were, but I have messed things up bigtime now. I thought I would get some advice from you guys before it gets any worse. What I did wrong I first cloned portal master to a local repository called vendor. I then did a merge with the core, but did not push. I then applied my changes to the local master (1st mistake). I then created the remote branch vendor from this. I thought my internet had glitched, because my commit did not show up in vendor. I continued (2nd mistake), to sync the remote/local branches (git fetch origin) and setup tracking (git checkout --track -b vendor origin/vendor) for vendor, so that all future pushes would go straight to the remote branch. The local branch still did not show my commit, so I applied it again to the vendor branch (3rd mistake) and pushed. (4th mistake) I should left it alone, but it was suggested that I could correct this. I tried but it didn't work.I did some further research and found several articles suggesting; or (5th mistake) I eventually used the following, that is supposed to reverse the last push made. Because I didn't push the original core merge before I made my changes, the merge was counted as part of my push. As you can see from portal it didn't remove my commit, but updated all commits since my previous push (core commits included) with me as the committer :mad: Any ideas. I need to remove all commits from portal since my previous merge (i.e the one before last). EDIT: All fixed now If anyone is interested, here is what I did to repair portal I first removed the vendor branch Then, inside my local portal master (that I know to be clean), I forced an update. I then recreated the vendor branch and pushed my changes correctly Cheers

Hi Guys, Vendor Interaction for bots I have been working on a new project, so bots can interact with vendors to sell and buy items. I created a new alpha branch called vendor. The initial patch I pushed provides the bots with the ability to sell gray or poor quality items, whenever the player activates a vendor. This code has been adapted from an old 'Playerbots for TC2' patch. I have scoured the internet and there is no history as to the original authors of this particular code, only recently revised standalone patches. Unfortunately, I have blundered I have mistakenly pushed a copy of this initial patch to portal master as well. All subsequent versions will be pushed to the vendor branch. I have included an option in 'playerbot.conf' to activate/deactivate this feature. Hopefully the code will work without issue, and as usual we would be grateful for your comments. Hope this helps

They're both mine.The code on blueboy is tested and most stable, but won't necessarily reflect the latest changes with playerbot or the core. The code on portal is better if you want to try new features from playerbot or the core. Cheers

Hi, I'm a bit confused. I've just compiled the code on portal with the latest core (ManGOS[11216]) and it compiles without issue. Can you provide more details on the compile issues you get. Cheers

Hi mrelfire Thanks for the ideas. Several classes utilise the following code to quench a bot's thirst. The code is triggered by the bot's mana dropping below a certain level. if (ai->GetManaPercent() < 25) // if thirsty { Item* pItem = ai->FindDrink(); // pItem points at the drink if (pItem) // if found { ai->TellMaster("I could use a drink."); // tell the client ai->UseItem(pItem); // drink return; } } There is then a check in the bots bags for potential refreshments (Magi can conjure drinks, if they have the spell). At present, I do not believe potions are considered drink. I'm sure it would be possible to improve the code to also use specific potions if available. Stretching playerbot beyond it supported scope. I realise that people use or try to use playerbot in raid scenarios, but this is not currently supported. No account is currently made for level 74 magicians with cold or fire specialization. I'm not suprised that it ignores these advanced abilities and uses it's wand. Kyle1 has done some excellent work improving bot AI, with respect to spell casting, but the AI is still by no means perfect, even for low level magicians. For the AI to evolve beyond it's current state, will require more contribution from users who actively play the game (that excludes me, I haven't got the time ). The building blocks to create a more effective AI are already present in the playerbot code (e.g functions like FindDrink() or UseItem()), it just requires a little effort to put these ideas into patch form ("I could use a drink" code is a good example). If for instance you wanted help creating a new function (i.e FindPotion(name)), I can help you with this. Hope this helps

Hi, O.K, I have now tested it out on both linux and windows and it works as expected. Flying from Ogrimmar to Thunder Buff, logged out as player then logged back in as bot. It continues the flight from where it logged out. I was wondering how you built your server on windows. I assume your using the existing (VC90,VC100) *.sln files. I know they have just added support for cmake builds and it is possible to create new *.sln files using cmake, but I haven't tested this out yet with MaNGOS. Cheers

Don't apologise, I want to help resolve this matter if I can. I can't help feel that this issue maybe caused by some setting or other, that you have not mentioned. I try to run my server with the "*.conf" defaults whenever possible. I run two servers; Main: linux O.S based (openSUSE 11.3 diistro) 32 bit Backup test: windows xp 32bit. I have been testing this issue on my linux box up to now, but if your using windows I will try it on my XP box and see if there is a difference. Speak with you soon

Hi, Thinking about it, you maybe quite right. I assume your running with the latest UDB update. Have you tried a different database, either psmdb http://svn.assembla.com/svn/psmdb_wotlk/ or ytdbase http://svn2.assembla.com/svn/ytdbase/ I currently use ytdbase as it includes some really nice features. Hope this helps

Hi, It sounds like a vmap issue to me. When did you create new vmaps last, and also make sure you have the vmap settings correct in mangosd.conf. I use; Hope this helps

Hi, No, it's working as expected. The NPC's do not want you to summon/dismiss a bot, they are just giving you the option to do so. The NPC's menu should still provide the option to train, buy or sell, or fly. By the way, the bot menu is not added to every NPC, just those who meet certain criteria (For instance you will not find the menu with Inn Keepers and most flightmasters or merchants. Mainly trainers). If you do not wish to use botguy menu, do not apply mangos_botguy.sql to your world database. If you have alreadly done so, remove the record that the sql file adds to the world database. This does not effect summoning/dismissing bots from the command line Hope this helps

Hi vladex, O.K I've built a server having all the mods you listed, including the vehicles from the patch you posted. I have tried everything to make it go wrong and it won't. I had a small group; a player knowing all nodes, one bot knowing Orgimmar , Camp Taurago and Thunder Bluff, and another who just knows Thunder Bluff. If I fly from Orgrimmar to Camp Taurago, only the player and first bot flies. The last bot teleports to Camp Taurago, but has learnt the node for Orgrimmar. I tried logging out during the flight and then logging back in as the bot, and it worked as expected. The bot flew around the mountain, en route to Camp Taurago and not through it as your video show. I finally flew from Orgrimmar to Thunder Bluff and all flew. I'm completely stumped why this happens on your server. I will continue to test the code and would welcome anyone elses comments, who may or may not be experiencing the same issues as vladex Cheers

Hi vladex, I've looked at the video and it appears the character actually flies through the mountain in the Barrens en route to Camp Taurajo. Is this the player flying or the bot after you log back in. The server output tells me nothing (no debug info). Make sure you have set to 3 in mangosd.conf. The code I use for bot flight has no influence on the flight path taken. The bots will only follow the flight path known to the player. This effect shown in your video is caused by something else. As I said in my last post the only mod that you use and I don't is vehicles. Try building your server without vehicles and see if it goes away. I have just looked at Tasssadar's github and see from a recent commit EDIT: I've just looked at the date of this commit. Not so recent. Where are you getting your code from, mabe I can try it on my server see what happens. https://github.com/Tasssadar/Valhalla-Project/commit/2f49a742b4c3f3401da78173659afacdeafb05fd Your video does suggest that the windrider is flying very low, almost at groundlevel. Thus it appears to fly through the mountain rather than over it. Hope this helps

Hi, The only thing you run that I do not run is vehicles. So lets get this straight, the player and a couple of bots (both invited to the player group) approach a new flightmaster. The player and one of the bots learn the new node and fly. The other bot does not. Hmm, this does make sense. The only conditions that would prevent a bot from learning a new start node would be if it isn't in the player group or can't interact with the flightmaster (not close enough, wrong faction). I assume that all the bots know the destination node. If you could show me what is outputted at your server console when this issue occur, it would help enormously. Cheers

Hi vladex, I assume you have applied the patch I posted and the problems still continue.. You've got me confused now. You say the bug has returned, and it is the same one as before. Is this the problem with logging in and out, where the bots were not continuing the flight from the point of interruption, but from the beginning. I see you also finish by saying that "this time everything worked normally" What exactly is happening? It would be useful if you could provide a snippet of your server output (debug log), when things go pear shaped. Did you manage to create a video of this issue, that might help. To troubleshoot this flight issue, it might be necessary for you to rebuild your server, with just the portal and flight code. How are you applying the code from the flight branch. I'm assuming that you create a standalone patch and apply this to your source code before building. Hear from you soon

Hi, I've found the cause of the flight issue. The flight path or spline is stored in a list (nodes). The first element of this list signifies the start node and is indexed as zero (nodes[0]). I mistakenly took the destination element as having an index of one (nodes[1]). This is true for single node flight, but incorrect for multi-node flight. I now index the destination node by taking the size of the node list and subtracting one (nodes[nodes.size()-1]). This now correctly points at the last or destination node for both single and multi-node flight. I will update the flight branch shortly, but in the meantime here is a patch diff --git a/src/game/playerbot/PlayerbotMgr.cpp b/src/game/playerbot/PlayerbotMgr.cpp index e609ee5..1f3eb2c 100644 --- a/src/game/playerbot/PlayerbotMgr.cpp +++ b/src/game/playerbot/PlayerbotMgr.cpp @@ -789,7 +789,7 @@ void PlayerbotAI::GetTaxi(ObjectGuid guid, std::vector<uint32>& nodes) if(m_bot->m_taxi.IsTaximaskNodeKnown(nodes[0]) ? 0 : 1) m_bot->GetSession()->SendLearnNewTaxiNode(unit); - if(m_bot->m_taxi.IsTaximaskNodeKnown(nodes[1]) ? 0 : 1) + if(m_bot->m_taxi.IsTaximaskNodeKnown(nodes[nodes.size()-1]) ? 0 : 1) return; if(m_bot->GetPlayerbotAI()->GetMovementOrder() != MOVEMENT_STAY) Hope this helps

That's right. If the bot doesn't know either of the nodes it won't fly and if it o doesn't know destination node. It will be left behind. o doesn't know the start node, but can interact with the flightmaster, it will learn the node and fly (as long as it knows the destination node). O.K I've just found a bug myself - bot knows two nodes Stormwind and Ironforge. - player knows Westfall, Stormwind, Ironforge, Thorium Point and Menethil Harbor. If the player flies between Stormwind & Ironforge the bot follow and with any other destination it will be left behind. However, if the player first flies to Menethil Harbor and I then summon the bot (/p follow) it goes bananas :rolleyes: If the player flies to Westfall, the bot follows the player to Westfall and even flies via Thorium Point, also unknown to the bot. If I then log out and get the bot to teleport to Stormwind, the flightmaster shows that the bot still only knows, Stormwind, Ironforge and Menethil Harbor, which it has newly learnt. I will have to find a way to close this loophole, so this doesn't happen Cheers

I tried what you did. A player and two bots. We flew from Menethil Harbor to Westfall. As soon as the player arrived, I logged out. I then logged back in as each of the bots. Interestingly, they were still in flight but dismounted and landed safely, just short of the destination in Westfall. Something very weird is happening on your server. I know you are taking a different flight path, but that shouldn't matter. If anyone else is reading this and would like to try this out on their server, it would be a great help us.. EDIT: @vladex You haven't altered the delay times set for the player and bots (i.e 12 seconds between player and lead bot, then 3 seconds for every subsequent bot). I did extensive tests initially with these and got some strange effects if I reduced them from the current settings (i.e bots teleporting while in flight to the flight destination). Cheers

Hi vladex, So you interrupted the flight by first logging out and then you log back in. I have just tried this on my server. The player continues the flight from the point where I logged off. In the case of the bot, I needed to summon the bot again and as such was not flying. When you log back in as the player, does the bot still show up as been a member of the player group, but with the avatar grayed out and unavailable (prior to summoning)? Or, did you log off as the player and log back in as the bot "bane"? When I tried this, the bot was still in flight, but again continued from the point at which I logged out. I guess the video will answer these questions, I look forward to seeing it. Thanks for the feedback and your time Cheers

Isn't that always the way Glad you got it working. I hope you enjoy the new features added from the alpha branches. I really like BThallid's work with looting. Please let us know what you think. Cheers

O.K, so your bots are now flying, as they should. To resolve the looting issue, we need some details so we can try to reproduce what your getting. Can you copy & paste the server output (debug log = 3) when survey and or get fails. This will help use pinpoint what is going wrong. I will assume you have a group of bots and you have all loot collect objects enabled in playerbot.conf Do you get a list of game objects?, looking something like [Copper Vein][battered Chest][silverleaf] <Shift> click on required game object Do all the bots travel to the game object location? Only those bots with the required skills will be able to collect the game object. (client output looking something like this) [botname] receives loot [Copper Ore] [botname] receives loot [Rough Stone]x6 If a bot successfully collects the object, check whether the game object is added to the collect list for that bot [botname]Whispers: I'm collecting all loot, profession, quest items after combat and nearby objects (Copper Vein) Occasionally, bots will fail to collect objects. This is also true for players, particularly after gaining new abilities such the ability to mine Tin. Retry and eventually the bot should succeed. If not let us know. Cheers

Hi Guys @mrelfire Thanks for the info. There was an addition to the core in MaNGOS [11193] (World.cpp), that caused a merge conflict. This has now been corrected and I have pushed the changes to portal. @vladex The criteria for bots to follow the player are, bot must be in the player group. bot must be able to interact with the flighmaster (i.e close enough, same faction) bot must know the destination node (if the bot does not know the start node and can interact with the flightmaster, it will be learnt). bot must have enough money to cover the cost of the flight. bot must have the m_movementOrder set to follow If the bots still do not fly, let me know @toni1883 sharedbots allow you to share a character from another account. This can be useful if you need characters from separate accounts to exchange items. It is not designed to promote cheating or allow users to build very large raid groups. If you wish to try out the code on the https://github.com/blueboy/portal/tree/sharedbots alpha branch, read bot_readme.txt on that branch Hope this helps and please provide feedback on all code tested

Yes, if you wish to merge the code on portal (master branch) with an existing local git repository. If you try to download to anything but a git repository, you will get If all goes well, the code will download and merge. If your existing server source code conflicts in any way with the code on portal, you will have to resolve these before the merge takes effect. If you prefer, you can create a standalone patch as explained in post #1689, and apply this to your server source code (using git apply with --check option to check for possible merge conflicts). EDIT: Sorry I don't read my own posts I have corrected the git apply option Hope this helps

Hmm, That interesting, on my system if you do no specify the branch It assume your pulling from the master. If you wish to pull from one of the alpha branches, use <remote branch name>:<local branch name> e.g EDIT: But please remember we have not yet changed these alpha branches, so if you try to merge these with portal code you will get conflicts. If you wish to use code on the alpha branches at present, create a standalone patch and then apply this to the portal code. Hope this helps

There's a good reason for this. You have updated you MaNGOS to [11167]+ and your using the code on blueboy. I will be converting the code on this repo shortly to fit in with core changes, but I just want to make sure they will not change their minds and revert to using the old 'autoconf' build. In the meantime, please pull your code from portal which has the cmake changes. Hope this helps