blueboy

Milly's Harvest and the collection of wood piles in Eastvale should work perfectly. I will double check, just in case something has changed with the core that now prevents it. Most bot quests are completed as the player does (killing quests, etc) The collection quests was an exception and this was the reason we wrote specific code. I have been presently working on 'use item quests'. Most are completed as the player does (e.g 'Awakening lazy peons' in the orc start area), but some like filling quests aren't. I have revised the 'quest' command to display an [item Link] that can be used to complete bot quests (e.g 'Crown of the Earth' quest in the Nightelf start area. Here you can utilize the 'use' command with the bot(s) in close proximity to the specific moonwell. to get the bot to fill the phial at the moonwell. I can't think of an example of an explore quest, perhap you can and I will test it out. I know most area explorations are handled by the 'acheivement manager', let me know. Hope this helps

If you are referring to the playerbot GitHub, https://github.com/playerbot/mangos then yes it is updated to keep pace with changes in the core. Occasionally, we merge code from portal , once it checks out. The portal branch holds our beta test code, ready for public testing. If you wish to try the latest code changes for 'bot looting', you will need to merge the code from loot-fix-bt alpha branch. This code is not guaranteed and any feedback, is for the devs info only. It sounds to me that your experiencing an issue that we are aware of and at present looking into. Occasionally, bots fail to collect quest items and continue to try without success. A temporary fix (As the player; you can either collect the item for yourself or move away from the offending item). Chances are that they will collect the next item without issue. If you are still experiencing problems, let us know Hope this helps

Hi Guys, In response to mrelfire's suggestion I have created a new method for bots to repair their items. This is far more comprehensive than the existing method, and even allows bots to repair items with 'Field Repair Bots'. The new method is a plugin to the 'findNearbyCreatures mechanism' on vendor, so it might be a little buggy. Please test this code and provide feedback Overview: Once commanded to repair, the bot will scan for all nearby armourers (including repair bots). If found, it will travel to the armourer and repair specified or all items, and then return to the master. If the bot is a member of a guild, it will use guild money to repair items, else it will use it's own money. I might change this so the master can dictate whether the bot uses guild money or not. Syntax: or P.S. As a bonus, bots can even sell items to 'Field Repair Bots'. Tested with Field Repair Bot 74A. I will push a working patch to vendor shortly Hope this helps

They have recently renamed some enums in the core and this was what caused the conflict. I have now corrected this on portal with a merge MaNGOS[11357]. I will be updating the other repos shortly. Hope this helps

Thanks for the suggestion. This has been requested before and I am presently revising the code to hopefully accommodate it. Field repair bots possess the npcflags of a repairer (UNIT_NPC_FLAG_ARMORER) & vendor (UNIT_NPC_FLAG_VENDOR). The idea is that the repair bots will be treated just like any other npc, so the playerbots should be able to interact with them Hope this helps

Hi Guys, Before committing the 'auction.patch' revision to vendor, I thought it might be useful to provide a brief primer on it's use. To 'create' a bot auction We first need to get a list of all items in the bot inventory, in [item Link] form. Select 'Trade' from the bot avatar menu on the client and then close the trade dialog that opens. Click on the [botname] HLINK to open chat with botname. The items will be added to the bot m_itemIds list. While(m_itemIds not empty) { bot will scan for surrounding creatures (findNearbyCreature()) who can service m_itemIds if(found) Search is carried out for all itemids that can be processed by this creature. if(processed successfully) This instance of the data pair (npcflag,itemid) will be removed from m_itemIds } If the auction is created successfully, the master is notified. To 'list' all active bot auctions A dumby item is added to the bot m_itemIds list, purely to locate the nearest auctioneer. Once found, all active bot auctions are listed (Please noted that location of the nearest auctioneer will only be acheived, if the bot is within range of the auctioneer). Primarily an [Auction Link] is displayed. If(anyone has bidded on the bot auction) Their 'name' and 'bid' will also be displayed, together with the auction 'time' remaining. else Remaining auction 'time' will be displayed. To 'cancel' active bot auctions Using the [Auction Link] displayed by 'list' (shift click on the link) The auction ids are first extracted from the links and then added to the bot m_auctions list. A dumby item is also added to the bot m_itemIds list to locate the nearest auctioneer. Once found, all active auctions in m_auctions (with ActionFlags == REMOVE) will be removed. If the auction cancellation is successfully, the item(s) will be returned to the bot via email and the master will be notified. I will push the changes to vendor shortly Hope this helps

Hi Thanks very much for the patch. This is more or less what I did to fix recent changes with the core. After MaNGOS[11317], changes to include 'prepared sql statments' caused a few conflicts with playerbot code in WorldSession.cpp. @@ -467,8 +467,13 @@ void WorldSession::LogoutPlayer(bool Save) ///- Reset the online field in the account table // no point resetting online in character table here as Player::SaveToDB() will set it to 1 since player has not been removed from world at this stage // No SQL injection as AccountID is uint32 + static SqlStatementID id; + if (! _player->GetPlayerbotAI()) - LoginDatabase.PExecute("UPDATE account SET active_realm_id = 0 WHERE id = '%u'", GetAccountId()); + { + SqlStatement stmt = LoginDatabase.CreateStatement(id, "UPDATE account SET active_realm_id = ? WHERE id = ?"); + stmt.PExecute(uint32(0), GetAccountId()); + } ///- If the player is in a guild, update the guild roster and broadcast a logout message to other guild members if (Guild *guild = sObjectMgr.GetGuildById(_player->GetGuildId())) @@ -543,8 +548,11 @@ void WorldSession::LogoutPlayer(bool Save) WorldPacket data( SMSG_LOGOUT_COMPLETE, 0 ); SendPacket( &data ); + static SqlStatementID updChars; + // Playerbot mod: commented out above and do this one instead - CharacterDatabase.PExecute("UPDATE characters SET online = 0 WHERE guid = '%u'", guid); + SqlStatement stmt = CharacterDatabase.CreateStatement(updChars, "UPDATE characters SET online = 0 WHERE guid = ?"); + stmt.PExecute(guid); DEBUG_LOG( "SESSION: Sent SMSG_LOGOUT_COMPLETE Message" ); } I have committed these changes to portal in the last merge. I have been working with the adjusted code and it appears to work without issue. Sorry, I have been distracted by development work on the 'auction.patch'; this is now ready to commit to vendor. Once done, I will then check whether there are any further problems with playerbot and MaNGOS[11339]+. Hope this helps

Sorry, I misunderstood. Your referring to the repository ahbot @ blueboy Github. I have no plans to alter the code here. It works and provides adequate auctionhouse capabilities for playerbot development. As mentioned in my last post, it would be silly to create a new flavour of ahbot, when everyone anticipates cyberium's ahbot being included in the core, sooner or later. Hope this helps

All things are possible I am not totally familiar with cyberium's 'new_ahbot' that is under review (I know I should), and hopefully it won't be too before it's in the core. However, I understood the reason for removing the bot from the code, was to free up resources; without the need to create a dedicated ahbot character and associated account. I assume that the 'new_ahbot' code emulates the bot, in stocking and purchasing items to and from the auctionhouse. If this is so, my code will work with both, without any need for alteration. Playerbot auctions are added to the auctionhouse exactly the same as a real player would do, and processed the same way too. If the auction is won or expires, an email is sent to the bot. I am presently working on a revision to the initial code that will allow bots to not only add auctions, but also to list those bot owned auctions, and remove any unwanted bot auctions. Playerbot bidding is not practical at present. Hope this helps

Hi Guys, I've just pushed the 'auction' patch to the vendor branch. This is the initial version, so it's a bit rough around the edges. It works much the same as the sell command except the bot(s) look for auctioneers rather than vendors. All you can do a present is create an auction for the bot(s). Used in conjunction with the 'auctionhousebot' patch you can get the auctionhousebot to bid and even buyout the bot(s) items, if the price is right. I would be grateful for feedback on this point. The values for starting bid and buyout price are only approximated. If anyone want to provide a concise algorithm to calculate these values, I would appreciate it. Anyway enjoy.. Hope this helps

You can do, but it's more flexible to create standalone patches and create a server to your own design playerbot and ahbot from blueboy will merge without conflict. Here is the bash script to create the ahbot patch #!/bin/bash -x git clone git://github.com/mangos/mangos.git ahbot cd ahbot git fetch git://github.com/blueboy/ahbot.git ahbot:ahbot git checkout ahbot HASH=`git log --pretty=oneline | grep -m 1 '\\[1[0-9]\\{4\\}]' | cut -d " " -f 1` git diff $HASH > ahbot.patch hope this helps

I have the auction patch ready and I will be pushing it shortly. In the meantime, I have just pushed the sell patch to vendor Hope this helps

Simply, it where bots interact with NPC, without the need for the player to select the NPC for the bots Hope this helps

Hi, If you require help compiling playerbot with the core, you must give me more information. Your message tells me very little, I am using linux. I have just compiled the latest code from portal master (pushed 3 hours ago) with the latest core MaNGOS[11321]. It compiles and runs without issue. I am also running movemaps, ahbot from blueboy and the following alpha branch mods (loot-fix-bt and vendor). Please let me know what compile issues you get.

New Feature: Direct bot & NPC interaction I have created a new function findNearbyCreature() that facilitates bot & NPC interaction for a number of purposes. Each bot will maintain it's own itemlist (m_itemIds). The list is a series of item pairs, the first component of the pair (UNIT_NPC_FLAG) dictates what is to be done with the item (uint32 itemid) given as the second component. e.g m_itemIds list while ( m_itemIds is not empty ) { bots will scan for all relevant NPC's within range (findNearbyCreature()), that can service the list. if ( NPC found ) bot will move to the NPC location, who will service all list entries, relevant to that NPC. } Initially, this has been developed to handle the sale of bot items with vendors, but it will be extended to realise bot interaction with auctionhouses. I will shortly push a working patch, to the alpha branch vendor @sunnyqeen Thanks for the patch, it works a treat I will shortly push it to portal Hope this helps

Playerbot lets you login your other characters from your account as bots that can be controlled to automate combat, facilitate trade, accept quests, complete quests, handle movement, manage inventory, and much much more... More Information can be obtained from the Playerbot Wiki This is a community project and all contributions are welcome. I would like to acknowledge the hard work of all those who have previously contributed and made playerbot what it is today Cheers

Hi Guys, In response to recent events, I propose the following changes to playerbot. Please feel free to comment. New Github code Layout: Thanks to collinsp, I have been added to the owner's team for the original playerbot Github. I wish now to update this and maintain it for playerbot release code. The blueboy Github will be used solely for playerbot development. I hope you agree with me that this makes sense. New Playerbot thread: I will first ask the management to rename the existing thread to Playerbot (Archive) and it will be closed. As the originator of Playerbot, I will then ask collinsp to start a new thread, providing the first post. Hope this helps

The only thing I would change would be with 'Active Repositories' blueboy was forked from the original playerbot Github, and contains the most stable code. https://github.com/blueboy/mangos portal contains our beta code, includes the latest features, but is still under test. https://github.com/blueboy/portal EDIT: Have you got any thoughts on what is to become of the original playerbot Github. When rrtn left the scene, nobody was left on the collaborators list who could update it. Maybe we could use it as the site for our stable code and use blueboy Github for development only. Cheers

Hi Guys, I've just added a new alpha branch called talents. As the name suggests, the code enables the player to manage the bot talents. The initial patch allows you to display all active talents for bots (no big deal, 'inspect' does this too), but it also shows active glyphs for the bots. Handle talents & glyphs: talent -- Lists bot(s) active talents & glyphs <click> on an [HLINK] will display the tooltip for the talent or glyph. talent learn [HLINK][HLINK] .. -- Learn selected talent from bot 'inspect' (shift click icon). You can select a new talent to learn from bot 'inspect' window, <shift click> on the appropriate icon. If you require a known talent to be updated to a higher rank, you can either use bot 'inspect', as above or <shift click> on the appropriate [HLINK] displayed by the bot 'talent' command. will do nothing as xena has no 'Unspent talent points'. If she did, the [shield Specialization] would increase in rank by one. Known issue: If the bot 'inspect' client window is open when you learn a talent, it will not be updated until you close and then reopened it. Please note that the spell is learnt correctly, it's just that the open window will not refreshed. After learning a new talent, all talents are displayed again in the chat history, with the updated 'Unspent talent points'. Hope this helps

Hi, Great to see your still around. I understand about time constraints, there are never enough hours in the day. My only real worry about starting a new thread is that someone might delete the old thread to free up space. This topic is still open for discussion and we would be grateful for any assistance you give, once a decision has been made. We are just looking after the shop, until you get back

I use the bash script on WINXP, using the git shell. The only issue you might get is with the 'grep.exe' included with the shell. If it is an old version it might not know the '-m' option. I replaced this with a version from GNU that does. Failing that, speak with me on PM. Cheers

alpha (portal branches) High risk code still in early development (minimal support, feedback for dev info only). beta (portal master) Public test stage, code in the later stage of development (full support) release (blueboy master) Fully tested code (full support) alpha branches are merged into portal master, and once tested portal master is merged into blueboy master

Hi UnkleNuke, I agree that the playerbot thread is now a vast tome. I am not personally interested in the thread belonging to me, but I can see some problems in starting a new thread. As I didn't start the original thread, I cannot close it. If I was to created a new thread, what would I call it, other than "Playerbot". With two threads open, support would become confused, as users would invariably post either thread, asking questions that may have already been answered. Also, if the existing thread was to be closed, someone @ getmangos.eu might even feel it would be a good idea to delete it, to free up space I prefer to create and apply standalone patches as you know, from the various branches, but I know that this is not always possible. BThallid has done extensive work on the loot-fix-bt branch. During the course of his work, he has the merged code several times with portal. As such it is not possible to create a (full) snapshot patch, that contains only loot-fix-bt code. If you were to use one branch as a base, I would suggest you use this one. Then merge all others with this e.g portal or MaNGOS. It is possible to create snapshot patches from all other alpha branches and this is what I suggest you do (some branches e.g sharedbots and flight exist with core code before the recent 'cmake build' changes. A merge would result in conflicts. Easily fixed, but why make life complex). Standalone snapshot patches are more or less independant of the core version. I include below a general bash script that will help create a snapshot patch, without core code (note: The patch will includes all code changes, after the last merge). Just replace flight in the script with the name of the required branch and apply the created patch to your base code. #!/bin/bash -x git clone git://github.com/mangos/mangos.git flight cd flight git fetch git://github.com/blueboy/portal.git flight:flight git checkout flight HASH=`git log --pretty=oneline | grep -m 1 'Merge branch' | cut -d " " -f 1` git diff $HASH > flight.patch Hope this helps

Hi Guys, I would first like begin by encouraging you to use the superb code on the loot-fix-bt branch, developed by BThallid. This takes bot looting & gathering to the next level and is a vast improvement over what was. Interestingly, a recent addition to this code (SMSG_INVENTORY_CHANGE_FAILURE handler) has enabled me to highlight a bug in the existing looting code, presently on portal. Issue: bots were not looting corpses properly. Items, including quest items were being left behind, although the bots had the capacity and need for these items. The SMSG_INVENTORY_CHANGE_FAILURE handler sends a warning to the client, each time an item is left behind. Cause: The SMSG_LOOT_RESPONSE packet was not unpacked correctly in the switch option, included in the function HandleBotOutgoingPacket(). This led to data corruption and erroneous item information. Solution: WorldPacket p(packet); // (8+1+4+1+1+4+4+4+4+4+1) representation of how the packet is composed, with data sizes ObjectGuid or uint64 data size 8 uint32 data size 4 uint8 data size 1 Before fix: The remaining data is unique to each lootable item, and was not being used. So as each bot loots, the data becomes more and more confused. if (loot_type == LOOT_SKINNING || HasCollectFlag(COLLECT_FLAG_LOOT)) for (uint8 i = 0; i < items; ++i) { // just auto loot everything for getting object WorldPacket* const packet = new WorldPacket(CMSG_AUTOSTORE_LOOT_ITEM, 1); *packet << i; m_bot->GetSession()->QueuePacket(packet); } After fix: The following Loops for each item on the corpse The data is now processed correctly and all items are lootable. I will be updating the code on portal shortly. Hope this helps

I have been asked about bg/arena before and I am aware of yad's work mentioned by vladex. I believe the best course of action would be to first allow yad the develop stable code for this and then we will try to get both projects to work together. If anyone would like to tackle this as a project with playerbot, please raise your hands now