blueboy

Hi, Have you taken a look at our Wiki site. playerbot wiki If you are merging only playerbot into MaNGOS you shouldn't get any merge conflicts. I will check this out just in case something has changed in the core. If you are using others mods in addition to playerbot then you will need to fix these conflicts before building. The normal directory tree is as follows, <Source Root>src/game/playerbot We have two main repositories with several alpha branches holding the latest code under development. (you are welcome to use these, but feedback is for developers information only (minimal support)). playerbot playerbot release code This is tried and tested code (full support) portal playerbot beta code This holds most of the latest playerbot features under test (full support) If I were you, I'd start with a clean download of MaNGOS using the 'clone' command rather than 'pull' then choose which playerbot code you wish to use. You can merge the playerbot code in two ways, either directly or via a patch. I like to use standalone patch as this give you an opportunity to correct any merge conflict before actually applying the code. Once you have fixed the patch you can reuse it should you need to build the server again. If it merges without conflict, then remove '--check' and re-apply. Merge Conflicts. git uses code patterns (normally 3 lines) above and below the patch mod (patch sandwich), in order to find the appropriate location for insertion into the main code. The conflicts occur when these patterns do not match those in the main code (generally occurs if you apply more than one mod). git helps by marking the conflict in the main code with (use an editor and search for HEAD) <<<<<<< HEAD conflict >>>>>>>> <hash> Remember to remove the conflict markers before saving the code, otherwise it won't compile Look at both the patch code and the main code and compare. (You are merging into to main code so this is your standard). If one or both patterns differ, then copy and paste these from the main code to the patch ans save. Also remember to insert a space at the beginning of each of the 3 lines copied, otherwise the patch will be broken i.e. This link may also help you resolve any conflicts http://book.git-scm.com/3_basic_branching_and_merging.html Occasionally the conflict occurs in the patch itself, say for instance they suddenly decided to rename a function in the core. A keen eye is required and alot of patience. Hope this helps

Hi Joubarbe, We're glad you enjoy playerbot, and I agree with you that a year or so ago there were still major fixes being posted to resolve server instablity in the MaNGOS. However, those instability issues have all but gone. I can't remember the last time my server crashed (low population) due to the core code. Instability occurs when you start adding a multipicity of modifications to the core, that often conflict with one another. For this reason, I would avoid using repacks if you can. It's better to keep the number of mods to a bare minimum, and repacks don't always give you that choice. The project Playerbots began on TrinityCore and the original developers then brought the playerbot project to MaNGOS, where it has since evolved through contribution from many developers. Unfortunately the TrinityCore project stagnated through lack of interest, all but the occasional burst of enthusiasm to get it going again. We have added playerbot support for MaNGOS Zero (WoW Classic), but time restrictions prevent us from providing support for all cores. I have been asked many times whether we will provide support for Cataclysm, but and as you probably know most code is based on a flavour of TrinityCore. One day, MaNGOS and we will be there. The guys at mangosR2 are also doing excellent work and I was taken back by the number of mods they have incorporated in the code. This may well account for why the playerbot code seems to be causing them issues at present. My advice to you is keep the makeup of your server simple and if you have the know how, build it yourself. There is plenty of support here and on the other threads, if you get stuck. Hope this helps

Sorry, I think you may have misunderstood what I meant by 'reproduce'. If I was to create a server from mangosR2 code, under what circumstances would this crash occur?

Thanks for the fix and I hope this stops your crash on mangosR2. I don't think this really effects playerbot on MaNGOS. I looked at mosst's crash dump and I don't think the problem is with a NULL pointer being passed in 'm_bot'. This fix may treat the symptoms, but not the cause of the crash. I believe there is something else causing this bus error. This code has worked without issue for ages on MaNGOS. Like I said on GitHub, I cannot comment further without more information concerning the crash. I do realise your bots are in combat, but can you shed any light on what happens at the time of the crash? How reproducible is this crash? What is the nature of your bot group? (i.e small group, raid group and or mixture of bots and real players) and not dual faction. What is the nature of combat? (i.e. are you just attacking a solitary target or storming a stronghold with many targets) When I have time I'll try to test out mangosR2 and see if it crashes for me too. Let me know

Hi Guys, Sorry for the delay in responding to the thread, I've been absorbed in dev work. @ZPS Thanks for the links to the playerbot improvements and I'll monitor the work you are doing, cheers I think I have a breakthrough in profession management. Are you tired of having your bot bags filled with reagents that they cannot directly use. Well, I'm pleased to say that I have found a solution in the new craft command. Sometime back I was examining the feasibility of mangaing enchantments, but I hit a brick wall when it was suggested that the bots should be able to enchant soulbound items via the non-tradable slots. This worked if one of the traders was the player character, but not if both were bots. I got frustrated with the server continuely crashing so I shelved the idea. I have now utilized the code I created to manage other professions that rely on the consumption of reagents. The initial craft command will allow your bots to create items, if they have the profession, the right tools and or appropriate spell focus (i.e near to forge, anvil, loom or cooking fire) First aid list all learnt spells to create medical supplies, indicating the number of items that can be created from all reagents in a bot's bags. craft [Heavy Linen Banadage] Create a single bandage craft [Heavy Linen Bandage] all Create all [Heavy Linen Bandage] from available reagents Cooking list all learnt recipes, indicating the amount of dishes that can be created from available reagents. craft [basic Campfire] required to cook by. craft [scorpid Surprise] Create a single dish craft [scorpid Surprise] all Create all [scorpid Surprise] and so forth for all other professions. I haven't tested all yet, but I hope you will help and provide feedback craft <blacksmithing | b> craft <leatherworking | l> craft <tailoring | t> craft <smelting | s> craft <jewelcrafting | j> craft <inscription | i> craft <alchemy | a> craft <engineering | e> I have a working patch and will be pushing the code to new-ai shortly. Hope this helps

Hi Guys, [bug] Paladins,Druids would exhaust all their mana trying to buff a warlock's imp. This is not really a bug, but more an omission in the playerbot code. I tracked the problem down to the imp spell 'Phase Shift' So while phase shift is active, the imp can only be buffed by the warlock pet owner. If the imp attacks it will lose phase shift ability and this will give the other bots the opportunity to buff the imp before entering combat. [solution] The bots will not buff the pet if it HasAuraType(SPELL_AURA_MOD_UNATTACKABLE) I have created a patch and I will push it to the portal master shortly. @kennumen I am at present testing the latest code on new-ai, with the following party Sorry I haven't got a priest bot in the team. Works a treat so far, but they're not tough enough to party so I haven't ventured into Shadowfang Keep yet One tiny thing that I noticed with the talent tab, of the inspect window on the client. If open, it was not being updated as new talents were being added, using talent spec #. I created a help function InspectUpdate() that refreshes the inspect window, without having to re-open it. I have taken the liberty of amending the code so this is now done. Hope this helps

Hi Guys, Thanks for the ideas. I have fixed the above issue. If one bot casts a profession spell (e.g. Mining - 2576) on an item first, it it possible for other bots to try indefinitely to get this item, although it has gone. I suspected that this maybe the problem, but I needed to find an appropriate place in the code to cancel the spell for the other bots. When the item is removed, an error message is sent through SMSG_CAST_FAIL, reporting SPELL_FAILED_BAD_TARGETS. Here I cancelled the spell, and the other bots now stop what they are doing shortly after the first. This should work for all collection type professions. I have revised the 'NEED OR GREED' code in PlayerbotMgr.cpp. The roll will now correctly assign the 'roll choice' depending on the usefulness of the item to the bot. If the bot has the required skill (e.g SKILL_MAIL or SKILL_WANDS) then they will choose NEED. I have updated the function IsItemUseful() in PlayerbotAI.cpp to include ARMOUR and WEAPON skills. I also added a check on 'ITEM_CLASS_GEM' items (e.g Tigerseye) These items will be needed only by bots with (blacksmithing, engineering or jewelcrafting as suggested by WOWHEAD). I take kennumen's point that order of choice will need to be revised (i.e to take account of enchantment skill level), but at least it functions correctly. We may need to tweak the IsItemUseful() function more as well. I have updated the GOSSIP_OPTION list in findNearbyCreature(). I found there were some questgivers from whom the bots were unable to interact with. also the bots seemed to be reluctant to approach the NPC with MovePoint(). I have disabled the default option to 'generatePath'.I will shortly push the above changes to the portal master branch, for testing. New Feature I have revised the use command so bots can now apply certain items (e.g Sharpening Stone or Armour Kits) to those equipped. I will push this code to the 'new-ai' branch for testing. Hope this helps

Hi Thanks kennumen for the todo list. I'm already looking at a number of the issues you raised and hopefully we can find solutions to all. I've got a small patch to try and improve on the Need or Greed choice. I've only just started testing it so it might not work. If anyone is interested here's the patch. diff --git a/src/game/playerbot/PlayerbotMgr.cpp b/src/game/playerbot/PlayerbotMgr.cpp index ac39b96..ed123e4 100644 --- a/src/game/playerbot/PlayerbotMgr.cpp +++ b/src/game/playerbot/PlayerbotMgr.cpp @@ -573,7 +573,21 @@ void PlayerbotMgr::HandleMasterIncomingPacket(const WorldPacket& packet) if (!group) return; - (bot->GetPlayerbotAI()->CanStore()) ? choice = urand(0, 3) : choice = 0; // pass = 0, need = 1, greed = 2, disenchant = 3 + Item* rItem = bot->GetItemByGuid(Guid); + if (!rItem) + return; + + if (bot->GetPlayerbotAI()->CanStore()) + { + if (bot->CanUseItem(rItem) == EQUIP_ERR_OK) + choice = 1; // Need + else if (bot->HasSkill(SKILL_ENCHANTING)) + choice = 3; // Disenchant + else + choice = 2; // Greed + } + else + choice = 0; // Pass group->CountRollVote(bot, Guid, NumberOfPlayers, RollVote(choice)); @UnkleNuke. As always, thanks for your kind words of encouragement I remembered that 'mail' was on your wish list, so I hope you like it. I've just pushed the mail patch to the new-ai branch. One more bug to the list. [bug] If two or more bots have the same profession (e.g mining), only one bot will succeed in collecting the gameobject. The others will continue mining a non-existent ore sample. Any suggestions to this, or the ones that kennumen list will be gratefully received. Back to testing..

Hi Guys, Some time ago, we had a request to provide bots with the ability to interact with mailboxes. I am now pleased to announce that I have a working patch ready and I'll push it shortly to the new-ai branch. The code will allow bots to collect money, items and info (including auctionhouse mail) from a selected mailbox. I wanted to keep the command syntax simple, yet functional. You can set up a macro for convenience However, to prevent cheating it is necessary for the player & bots to be within interaction distance of a mailbox. mail inbox [Mailbox] List all bot mail from selected [Mailbox] 1. Command bots to do a survey for surrounding gameobjects. 2. Command bots to look in their mail inbox. mail getcash [MAILID] Gets money from all selected [MAILID] mail getitem [MAILID] Gets items from all selected [MAILID] All mail will automatically be removed from the mail box after a set number of days (default: 29days). However, if you wish to tidy up the bots inbox sooner, then mail delete [MAILID] Delete all selected [MAILID] I do not think it practical to allow bots to send mail, but I hope you will find the existing suite of subcommands useful. Please test and provide feedback so that we can improve the code.

Hi, Nice wish list and it certainly gives us plenty to work on. As I already mentioned on PM, there does exist a way to remove unwanted items manually from the bot's inventory. Interestingly, the 'sell' command allows you to donate (for no value) the items to your nearest vendor. This works for both quest and conjured items that would otherwise clog up the bot's inventory. I agree that it would be much better if the bots only received items they require while looting. At present, the looting system uses autostore that pockets everything regardless of need. To everyone, please contribute. Playerbot is a community project and it need your help Cheers

Hi, Now that I have slept on this, I was wondering An intresiting group of characters, if your adventuring in Mulgore. Which paladin trainer are you visiting? The nearest one to my knowledge is in Orgrimmar (Master Pyreanor, Grommash Hold). Surely you are not commuting each time you wish to skill up. Cheers

Hi Sorry about being sneaky and editing my last post, it's me doing my bit to save the planet, by saving paper :lol: I have now tested this on my windows server XP (32bit) and it works perfectly with no crashes. I manually leveled my group of Taurens on both servers from 1 the 6, manually learning all spells/skills and doing all quests (where did Saturday go ) Have you tried removing your client cache. I have had a number of issues in the past with corrupted data in the cache causing crashes. I created a batch file to automatically remove the old cache each time I run the client worth a try. I think the next step will be for you and I to meet up in BloodHoof Village. I'm free tomorrow morning at about 11.00am GMT.. Yeah I've got no problems with you merging the 'talentspec' code with portal master. There was a 'drop' command, but this was related to dropping unwanted quests. If you want to remove quest items, I suggest you occasionaly log the bots in as the player and destroy these items. I'm not sure a dedicated command would be worthwhile. Speak with you soon

Thanks for the information. I am looking into the matter at present and I'll get back to you once I have an answer. Does it only crash when learning [Thorns] ? EDIT This is most peculiar, I have taken a group of level 6 taurens to Bloodhoof Village and visited Gennia Runetotem N.B [Thorns] is the spell link, selected by holding down the shift key and clicking on the link. I'm sure none of you are just typing '[Thorns]' and I do not question the fact it's happening to you. What we need to do is find out what is different between my system and yours. My system Compiled on linux, in debug mode [MaNGOS] 11836 [sD2] 2319 [Database] ytdbase 0.14.3 R606 [Addon] EveryQuest2 // not necessary for playerbot. I am presently testing another patch. @darkfr3ak Can you elaborate more. I have checked warriors and they learn skill like any other class. Speak with you soon

Nice one, I'll give it a try EDIT: :cool: Works a treat !

As a complete novice in actually playing wow, it has always been a mystery which talents to choose in order to end up with a useful character. To an experienced gamer this choice maybe simple, but for guys like me we need help... lol. I do remember playing a game not unknown to many (NeverWinterNights), religously following a guide to create an elite character. The new talent spec feature promises to be that guide for playerbot users. The author kennumen has only just started developing this code, but I would recommend that you watch this space as believe this will prove extremely useful. If I understand correctly, your looking for code that will allow a group of bots to adjust their individual abilities, depending on the class makeup of the group. So if you had a group of say three paladins, one would specialize as a healer, another as the tank and the other as dps. If this is so, I can tell you that the code does not exist ( 'yet' ) and if it did, I would expect it to in PlayerbotAI.cpp rather than PlayerbotMgr.cpp Hope this helps

Hi kennumen, First of all thanks for your contribution. I have taken a brief look at the commit and I can appreciate the time you must have put in entering the talent data alone As you point out this is just a preview, so not biggie that it's still a little buggy. I will certainly help out if I can, maybe track down these bugs causing the instablity in the code. I'll get back to you once I've taken a closer look Cheers

Hi, I've just tested it and it works. This is what I did 1. Ensure that your warrior has the charge spell in it's spellbook :rolleyes: 2. Get a list of bot spells 3. select target 4. cast charge spell if warrior has 'battle stance' aura, it will charge. Note that charge is automatically selected as a combat maneuver in DoFirstCombatManeuver() for warriors. If you just command the warrior to attack the target and it's within range ( between 8.0 & 25.0 feet) it will charge. EDIT: I am presently working on an issue that I believe is caused by a change they have made in the core. The bots seem reluctant to attack targets. Movement speed is drastically slowed (Although you get the swish sound for the charge) and frequently the bots turn to return to the master, before continuing to the selected target. I have seen the same reponse from pet attacks, so it's not restricted to playerbot code. Hope this helps

Hi Guys, I have updated to the 'skill' commmand. This revised command now displays the bot(s) existing weapon skills. This will save you the trouble of having to remember the bot(s) individual weapon abilities. Useful when you need to allocate an appropiate weapon to each of the bots (i.e quest rewards) or in weapons training. I have created patches for both MaNGOS and Mangos Zero and will push the code shortly. EDIT: Code has now been pushed Hope this helps

Hi Guys As promised I have now pushed the portal 'new-ai' conversion to the new 'zeronew-ai' branch, that supports playerbot for MaNGOS zero. I have tested the code on windows and *nix systems and it compiles and runs without issue. You will be aware that many of the game opcodes are presently quarantined by the core guys, so you will frequently find that somethings simply do not work, for bots or players. A good example of this is with the orc quest "Lazy Peons". In this quest you are supposed to wake sleeping peons, by wacking them over the head with a supplied club. Unfortunately this does not work By bot first select the peon By player first select the peon. click on Foreman's Blackjack item in player's inventory neither way credits the quest objective. If you are actually playing the game, you will appreciate that this will break the quest chain and prevent you from taking on subsequent quests. As a temporary fix, I suggest you use the 'gmguy patch' to auto-complete troubled quests. Please note that you will need to login the bots individually as players and enter the command below Example: Lazy Peon quest - 5441 Remenber that only quests flagged in the database table 'gmguy', by server admin can auto-completed. If no entry exists, then the quest cannot be completed. More information can be found in the file README.GMGuy Please let me know if you experience any problems Hope this helps

Test out the 'new-ai' code for MaNGOS zero. Like I said already, I have fixed the 'use' command so it operates correctly under MaNGOS zero. I was endeavouring to test this issue out, patiently levelling my bots up. I didn't realise that in the original wow you had to reach level 40, before you could ride . So I modified the settings in mangosd.conf to and created two new players. One thing I do need to tackle is to enable bots to buy items from vendors i.e. [blue Skeletal Horse]. I first got the bot to learn [Apprentice Riding] and this worked O.K. I bought a horse for the player and one for the bot. I then attempted to summon the bot horse notice that there is no space between the 'use' command and the item. In the later revisions of the client, a space was automatically inserted between the command and the item link. With the current client revison this does not occur, so I needed to revise the playerbot chathandler code to compensate. and the bot mounted and then unmounted immediately as expected (no crash). The reason for this behaviour is that if the player is unmounted, bots cannot remain mounted. So I repeated the above procedure with the player mounted and this time the bot remained mounted. I can confirm that the server did not crash. I will be pushing this code shortly, once I have ironed out a few more issues. Hope this helps

Thanks for the info, I'll check that out. I have also completed a full conversion of the portal new-ai branch to work with MaNGOS zero. Once I'm happy, I'll create a simliar branch off portalzero to hold this code. This code will include a fix for the 'use' command. Under MaNGOS zero, CMSG_USE_ITEM opcode fails in the existing playerbot zero code, if the bots move during casting. I hope that the revised code will allow bots to use the mount item correctly. I will be pushing the code shortly Hope this helps

Thanks for your kind words , but your thanking the wrong person for code that controls the gathering of objects. True, I did the initial work enabling bots to see gameobjects in the world with the get command to manually gathering. The looting code you enjoy today also encompasses the automated collection of useful objects, is the hard work of BThallid who is a valued member of the playerbot team and contributes regularly. He has also added the excellent 'sharedbots' feature to playerbot. It nice to see discussion again on the thread Cheers

Hi Glad you got it working. Use the script I posted above and make the changes I specified. SD2 is for MaNGOS supported by the guys from Scriptdev2.com. I use it because I need to provide Playerbot support for both MaNGOS & MaNGOS Zero. I believe that many of the guys who now support MaNGOS Zero came from ScriptDev2.com Essentially ScriptDev provide custom scripts that are necessary to detail game instances and battles with Boss foes. SD0 is compatible with MaNGOS Zero and is obtained from https://github.com/mangos-zero/scriptdev0 SD2 is compatible with MaNGOS and is obtained from https://github.com/scriptdev2/scriptdev2 Hope this helps

Hi, You need to provide more information. How did you create the patch? How are you using the git apply option? Where are are you applying the patch? It looks to me that your not applying the patch in the source root. This is inside the MaNGOS source folder where the 'createprojects.bat' file is located. Git can't find the files otherwise. EDIT: Run this script before you create your project with cmake. It's a general script, so you need to specify the SOURCE path & the SD2URL address. Hope this helps

O.K run this script copy playerbot_zero_update.patch to your source root folder and apply the patch. Then re-build your server (i.e. make) Note the --check option does a dumby run. If no merge errors, re-apply without this option Hope this helps