blueboy

Hi hurrensohn, Thanks for the heads up on the portalone repo. There wasn't much activity with core changes, so I didn't bother updating the repo. I have now done so and all merge errors are fixed. Hope this helps

merge remote branch 'origin/master' into sharedbots, done... Hope this helps

As far as I know the compare feature on github will compare the code on each sub-branch with that on the master. If for instance you compare the sharedbots branch with the portal master, you will get a snapshot of the sharedbots patch. I hope that makes sense Cheers

Have you tried summoning bots from the commandline and via 'botguy' ? I seem to remember it worked the one way, but not the other. I would be interested to know if it works for you? Cheers

I'm a little puzzled In your first post you wanted to include 'talent spec' code in your existing playerbot. You didn't mention that you were using sharedbots. The current sharedbots branch includes the 'talent spec' code. Have you tried just merging the current sharedbots branch into your code. If you get any conflicts, I will do my best to resolve them for you. @Edit Yes this is the part of the sharedbots patch that enables the code, based upon the playerbot.conf setting. Remember to follow The reason it isn't included in all the branches yet is because it's still buggy. Although you can load bots from other accounts, it then refuses to load bots from your own account I did find a fix for this, but it was thought to cause a security issue so wasn't implemented. Hope this helps

Yeah the autobot code is a 'work in progress' and I'm not sure whether it is operational yet. The best person to speak to would be kennumen, as it's his code. Hope this helps

The talent spec code is available in all playerbot repos. Here is the read_me for our release code, that holds our oldest active code. Depending on how old the version of playerbot is and it's source, you shouldn't get any merge conflicts. As a demonstration I have merged the alpha branch 'new-ai' into our release code without conflict. Here is the script, N.B. If you are trying to merge our code into the code used on R2, there are guarantees that you won't get some merge conflicts. @Edit If for instance you are using a very old version of playerbot, I would recommend that you build fresh. If it's recent code, after the merge; linux; Re-run cmake, before running make Windows; Rebuild the project using the *.sln file Hope this helps

Thanks for the info. I believe this is a real problem. Briefly looking at the AI for Mages,Warlocks,Priests, etc it is clear that the spell sequence (rotation) for duels is still quite primative. e.g PlayerbotMageAI.cpp So mage attack will be a steady stream of fireballs, with no disernible break between each cast. For non-duel attack, the spell rotation is more elaborate, so there will appear to be a reasonable delay between each fireball. It's agreed that there needs to be more work done on developing AI for duel combat. As a temporary solution you might try including a small delay in the AI to slow things down a bit (In green). One issue I have noticed while messing about with arenas was that warlock pets are unattackable with 'Phase Shift'. This is also true for duels, so it would be appropriate to disable this aura, while in these scenarios. If it works, you can apply it to the other AI. Either way, I would like you to let me know how you get on Hope this helps

A full patch to include all developemt code is not possible. You'll either have to be patient until such time when we merge the develpment code, or do the merge directly as Gitch suggests. I have created a small bash script to facilitate a multiple merge. You will still need to resolve some minor conflicts, but these are very simply fixed. bash script #!/bin/bash -x git clone git://github.com/mangos/mangos.git portal cd portal git fetch git://github.com/blueboy/portal.git master:portal git fetch git://github.com/blueboy/portal.git skillbot:skillbot git fetch git://github.com/blueboy/portal.git new-ai:new-ai git fetch git://github.com/blueboy/portal.git autobot:autobot git checkout master We will first switch to the portal branch. then.. 1. new-ai merge 2. skillbot merge To fix this conflict, open PlayerbotAI.cpp with your text editor and search for the pattern HEAD i. PlayerbotAI.cpp ii. PlayerbotAI.cpp Remove the text in red and save. To apply the merge after fixing the conflicts Your default text editor will open giving you the opportunity to change the commit header. For simplicity, just save the file and your done. 3. autobot merge You will see that there are three files causing conflicts. Repeat the process described for merge 2. i. config.h ii. config.h.in iii. playerbot.conf.dist.in Remove the text in red and save. To apply the merge after fixing the conflicts Your default text editor will open giving you the opportunity to change the commit header. For simplicity, just save the file and your done. I haven't merged all branches, but it will get you started. Hope this helps

Not at all, I still actively use MiniManager myself. I only update if there is a problem, normally if they try to restructure the databases. If there is, let me know and I'll try to sort it out. Cheers

Yes sorry it will work with plate armour too, but if I had mentioned plate in my example, someone would have pointed out that this is only available at level 40 Before, the paladins having all armour classes would grab everything. If you were equipping a paladin manually, your more likely to choose mail over leather and cloth. Once available, plate would be the preferred choice Hope that's clear

Hi Gitch, I not sure whether you have tried copying/pasting your patch, but with the code box formatting 'Diff' you endup including line numbers and no (cr/lf)s. I had problems with this myself. It's very pretty to read, but for practicality it's better to post code boxes in raw format. Cheers

Hi Gitch, Sorry, I should take more time reading posts (Too many late nights). I saw '"follow" and on the "fly" and thought you wanted to reduce the distance between player and bots during flight. Obviously you can set the general follow distance in the config file, but I agree it would be nice for users to be able to change this as they play. Hopefully I'll have a chance this weekend to do some more gaming Believe me whitespaces in code are like cancer, if you don't keep a check on them they take over. I remember creating a standalone patch for movemaps before it's inclusion in the core, it took well over an hour to clean the code. Cheers

Hi Gitch, Sound like a good idea. Be careful though, when I was testing the flight code, if the bot delay in following is too short the bots can catch up with the player and the display becomes very ugly as everything merges. Have a play and see what you come up with Cheers

We did have a sister forum for playerbot that provided all that, but they had big problems with 'spanners' (Not a typo, but a description) and it has been taken offline. here's the link should it ever be active again http://mangos.osh.nu/forums/index.php?app=uportal Cheers

Hi Guys, Something must have been going right yesterday. I must have had a crystal ball. Anyway, I have now updated all the repos and also the 'new-ai' branch with the latest core and with MoveMaps Yaaah.. Hope this helps

Hi Gitch, I found some more information on the trade HLINK. I'm sure whether it will help any UI escape sequences To examine the HLINKs using the playerbot code First, At line ~ 6850 in PlayerbotAI.cpp uncomment the following line // DEBUG_LOG("chat(%s)",text.c_str()); Then rebuild code and send a dumby command to the bot chat handler ([Cooking] link from player spellbook) These recipe are initially learnt with the cooking skill Herb Baked Egg Roasted Boar Meat Charred Wolf Meat After learning Spiced Bread the recipe list looks like this According to the link above, the recipe list is a Base64 encoded string, presumably using a custom inhouse algorithm. I tried a direct conversion from Base64 to ASCII and got only garbage. Cheers

Hi Gitch, and everyone else I have responded to today. Sorry, it's been one of those days, which I should have taken off I understand that it would be a nice idea to open dialog boxes on the client to service bots for various tasks, but it's not going to happen. The main problem is the system expects each player to have it's own world session and a screen to display it on. In theory you could get the system to open a window for the bot on the client, but you wouldn't see it. If you were to redirected the output to the player's session, you probably couldn't interact with it and it would almost certainly cause a crash. This is the reason why most command output is through the chathandler. Cheers guys

Hi Guys, @Gitch Perhaps I didn't document these very well, but the ablity to view bot tradeskills and associated spell/recipes already exists. To learn a tradeskill (2 primary skills per bot) (from bot_readme.txt) Remember that [HLINK]s are selected by holding down the <Shift Key> and left clicking with the mouse 1. Select a suitable trainer with the bot closeby. The trainer will reply something like I can teach you: // I know this is not word perfect, but you get the idea [Apprentice BlackSmith] To learn; If the bot has the cost to learn the skill, there will be a 'black powder' flash and the skill will be learnt. Note that all associated spells are learnt in the same way. To check which tradeskills a bot has [botname] Whispers: My Primary Professions: [blackSmithing] 2. To use these skills and view known abilities, you need to use the 'craft' command. (from bot_readme.txt) Knowing that the bot has blacksmithing as a tradeskill Will list all known blacksmithing spells/recipes learnt by the bot. I make the item; If the bot has the relevant tool (BlackSmith's Hammer, has the raw materials i.e. Copper Bars, and close to an Anvil) the bot will create the item [Copper Vest]. If the bot needs raw materials too; To smelt, the bot will also need to know Mining or trade the raw materials with a bot or player that does. @macks To view the item damage for a bot, use the 'stats' command. It doesn't list all damaged items, but does tell you the total cost to repair them. Yes, Gitch has an good idea auto-replacing damaged items if the durability drops. Hope this helps

For now I've added the necessary code to cover this from within _dosellitems() itself. Think it would be easier to call IsItemUseful() for the majority of the checks if possible. Getting close to a push I think, will up date when I do. Hi Gitch, I've just been testing the latest autoequip code with a new party of bots. For some reason the priest was not replacing a low level neophyte's robe( armor 3, cloth class ) with the unkempt robe( armor 8, cloth class ). The problem is the IsItemUseful() function. It contains a filter for low quality items. I don't wish to alter this, as it is used elsewhere. However, you can still utilize the armour comparison code from the function in your AutoEquipComparison() function. You will need the declaration of the relational array 'item_armor_skills' and of course the test to see whether the bot can equip the item's armour class and not greater (i.e Paladin can wear mail; if the item is leather or cloth it will return false as it's not the best armour for the bot). I have included a patch below for you to try diff --git a/src/game/playerbot/PlayerbotAI.cpp b/src/game/playerbot/PlayerbotAI.cpp index b29c909..ff30c42 100644 --- a/src/game/playerbot/PlayerbotAI.cpp +++ b/src/game/playerbot/PlayerbotAI.cpp @@ -543,6 +543,11 @@ void PlayerbotAI::AutoUpgradeEquipment(Player& /*player*/) // test for autoequip void PlayerbotAI::AutoEquipComparison(Item *pItem, Item *pItem2) { + const static uint32 item_armor_skills[MAX_ITEM_SUBCLASS_ARMOR] = + { + 0, SKILL_CLOTH, SKILL_LEATHER, SKILL_MAIL, SKILL_PLATE_MAIL, 0, SKILL_SHIELD, 0, 0, 0, 0 + }; + // get itemlevel for current item equipped in slot ItemPrototype const *pProto = pItem2->GetProto(); // equipped item if any @@ -567,11 +572,13 @@ void PlayerbotAI::AutoEquipComparison(Item *pItem, Item *pItem2) } case ITEM_CLASS_ARMOR: { - if (pProto->ItemLevel < pProto2->ItemLevel && pProto->Armor <= pProto2->Armor && IsItemUseful(pProto2->ItemId)) // itemlevel + if (pProto->ItemLevel < pProto2->ItemLevel && pProto->Armor <= pProto2->Armor && + m_bot->HasSkill(item_armor_skills[pProto2->SubClass]) && !m_bot->HasSkill(item_armor_skills[pProto2->SubClass + 1])) // itemlevel + armour + armour class EquipItem(pItem); // now in case they are same itemlevel, but one is better than the other.. - if (pProto->ItemLevel == pProto2->ItemLevel && pProto->Quality < pProto2->Quality && pProto->Armor <= pProto2->Armor && IsItemUseful(pProto2->ItemId)) + if (pProto->ItemLevel == pProto2->ItemLevel && pProto->Quality < pProto2->Quality && pProto->Armor <= pProto2->Armor && + m_bot->HasSkill(item_armor_skills[pProto2->SubClass]) && !m_bot->HasSkill(item_armor_skills[pProto2->SubClass + 1])) // itemlevel + armour + armour class EquipItem(pItem); break; } Hope this helps

Hi Guys, I've tidied the code on the 'master' and 'new-a' branches if your interested. @nightterror I have now merged the 'master' code into the 'new-ai' as I suggested on PM. Cheers

Hi Gitch, Sounds peculiar. Are you sure the bot is a member of the curent group. The system might have got confused as to who is a party member or not. If for instance you change who the master is (As a player if you logout and back in as one of other bots), it might require that you recreate the party. If you right click on the player avatar and select 'leave party'. Then invite the bots again with the new master. If the offending bot is not in the party and a command is directed to the party (/p) it will be ignored. Just an idea Hope this helps

Hi Guys, Thanks for all your contributions, we're going to be busy this weekend testing Cheers

Hi Gitch, One additional thing you could use that I'm trying at present with your code is the function IsItemUseful() that was created to control which bot gets what while looting. A problem with paladins is that they can equip all classes of armour. You have already mentioned that some of your bots appear to be cross-dressers (no accounting for taste) :lol: Ideally you only want paladins to equip mail (plate when available). I recently updated the code for IsItemUseful() to enforce this behaviour. So all you need to do is add this to your conditions. This should stop hunters, rogues, warriors and paladins from donning cloth robes. Hope this helps

Hi Gitch, Like I said in my previous posts, I have been looking at choice of weapons with autoequip. I'm not sure whether this will help, but it seems to work well on my server. Regardless of the type and quantity of weapons in the bot's inventory, it will equip the bot with the weapon having the highest DPS. I found that only the first highest DPS item was being equipped from the item list. By assigning 'pProto2' item prototype pointer to 'pProto' solved this. The use of the 'item class' switch statement stopped the weapon and armour comparison code from conflicting. I also included an InspectUpdate() at the end of AutoUpgradeEquipment() to refresh the inspect window if it just happens to be open during the equip process. I promise that I won't interfere again, sorry :8 I just love your 'autoequip' idea and wanted to help. @nightterror Great idea of yours to toggle MELEE and RANGED modes in the AI. I'm testing this at present too. Cheers