blueboy

Yes, I agree the duel is a bit one sided. The bot just stands there and takes all the damage, without really reacting. Leave it with me.. Cheers

All interesting suggestions Kreegoth. kyle1 (a.k.a chelobaka) has already added extensive controls for bot 'pet/minion spells' and combat reaction (passive, aggressive,etc). I agree that it would nice if you could specify which pet/minion is active at any time. I will also look into making bot 'totem control' more friendly. Cheers

I have merged portal master into vendor, so it should now be fully compatible Hope this helps

Ha , If the AI was a reflection of what I would do... you'd all be dead. I have been doing some research into gamers jargon/strategies and I realise I know nothing. Am I correct in believing that in the following 't' stands for tier or level, but does this relate to available spells in the spell book? and cite* http://wow-l2p.blogspot.com/2009/03/group-dynamics-tank-healer-dps.html 'aggro' is held by the tank. Is this the focus of the attacking creatures damage? It might be helpful if we could build a glossary of terms, so there is no misunderstanding (wow 101). Cheers guys

The link is not invalid, but you need to be logged into the forum to access it Hope this helps

Hi Kreegoth, Thanks for the info, I'll try it out. No worries... I just pleased that we can both collaborate on improving the AI. Oh, by the way is the 'druid' AI any better? Hmm, a bot following another bot, don't see why not. Leave it with me and I'll have a play. No I agree, it might seem a little off the wall to some, having a priest 'dps', but why not. I'm sure that higher level priests and certainly paladins can do alot of damage with holy spells. Speak with you soon

Hi Kreegoth, I understand your concerns and I wish there was a definite way to keep the priest at distance, yet still part of the action. Even hunters will resort to melee combat at close range. Hunters of course have 'auto shot' to bias their ranged attack and invariably have a ferocious pet to occupy the target at a distance. I have been testing the code with a low level priest that does not have a wand, and only basic spells. Even so, observing the 'combat log' shows that the priest rarely resorts to physical attack. I use a druid 'tank' to occupy the target, while the priest stands back (at ranged distance) throwing 'smite', shadow pain' etc. I am sure your targets are alot tougher than the ones I come up against, so combat is likely to be more difficult and prolonged. Can you detail your characters spells, weapons, levels, combat locations etc and I'll try to simulate a team on my server. Then we will be on the same page at least for furher testing. Hope this helps, and thanks for your time testing this out.

The problem is that priests will approach the target and stand at ranged distance (25.0f). If the spells they cast causes sufficient 'dps', it will draw the targets attention. The priest in close combat will have no choice but to use melee. It may be possible to include conditional code in the general combat 'AI' (i.e. in PlayerbotAI.cpp) to force ranged combat for certain classes. Cheers

Hi Guys, I have examined both 'Priest' and 'Druid' 'AI' and can confirm what Kreegoth says. The question is whether it is wrong or not ? My reluctance to change the 'AI' I am no gamer and the original 'AI's were developed and revised by guys who are. I am worried that with my inexperience I will make matters worse 'What I like 'AI' wise , might be hated by the next guy'. I have appealed for all to get involved in the development, to help produce a better 'AI'. One that can be used by all levels, satisfying the 'hardcore gamer' needs, yet be easy to use, even by a novice. I have had some guys show initial interest in 'AI' development, but then something scares them off. I wonder whether it might be deodorant I use PlayerbotPriestAI The existing priest AI contains a function call to override the bot(s) movement orders and set them to 'MOVEMENT_FOLLOW' the master. If you as the master go in fighing, so too will the priest, every time. If you stand back from the fight and order the bots to attack, then the priest will stay with you. I have commented out this and added some conditional code to set the combat 'SpellSequence' based upon combat orders (i.e ORDERS_HEAL will cycle through known 'HOLY SPELLS' only). If combat orders aren't set, ('ORDERS_NONE') then it will default to alternating through all Schools and spells e.g. spell sequence 1. SPELL_HOLY > SMITE 2. SPELL_SHADOWMAGIC > SHADOW_WORD_PAIN 3. SPELL_DISCIPLINE > FEAR_WARD 4. SPELL_HOLY > MANA_BURN etc... with the understanding that the bot has sufficient mana. As such, some spells will never be used. It would be nice if we could develop code that adapted to changing circumstances, casting a more appropriate sequence of spells. I would rather avoid changing movement orders during combat. If the movement order are 'MOVEMENT_STAY' the bot will remain static and be removed from the dynamics of battle. if the priest bot is too far from the battle, it's ranged spells will be ineffectual. PlayerbotDruidAI This 'AI' seems quite restrictive. It looks like druids will use 'DruidCombat' most of the time. The druid form will only change, if the druid has 'cat form', else it will return the bot to normal form. Also in 'DruidCombat', most spells are orientated towards mellee attack. e.g. Restriction imposed for 'DruidTank' to allow more general shapeshifting. if (Victim and bot health >= 40% and master health >= 60%) { if (Victim is m_bot) // (i.e master or (pet or minion) doesn't count as a victim) SpellSequence = DruidTank; } I am not surprised that druid bots rarely changes it's form during combat. Similiarly with 'DruidSpell', ranged casting only occurs if the targets health is above 20% and the victim is not a bot (i.e only if the target creature is attacking the master or (pet or minion)). I have created a patch, but it is too large to post to the forum. What I propose is that we develop class 'AI' in a new alpha branch 'new-ai'. It's my hope that this branch will be a melting pot for all your ideas. EDIT: The patch has been pushed. You can use the following bash script to create a standalone patch #!/bin/bash -x git clone git://github.com/mangos/mangos.git new-ai cd new-ai git fetch git://github.com/blueboy/portal.git new-ai:new-ai git checkout new-ai HASH=`git log --pretty=oneline | grep -m 1 'Cleaning code' | cut -d " " -f 1` git diff $HASH > new-ai.patch Your feedback will be appreciated. Hope this helps

Hi Kreegoth, Thanks for showing interest in playerbot. This is a model request Your suggestions and explanations are great and in particular the 'pseudo code' for your ideas. In answer to question, yes it should be possible. Leave it with me and I'll put a patch together for you to try out in a few days. Hope this helps

Hi, Nice idea, not having to manually 'train' the nearby collection option. I'm sure it will be very popular. If it works via SQL call, will it automatically restore quest items for collection (without user intervention), after a server restart? Once again, many thanks for your excellent work mate

Hi kaxias, Thanks for the patch @Dark_Oppressor There is a good reason why this does not flag an compile error for most users. They have recently introduced 'GuildMgr' to the core from MaNGOS [11430]. I have now changed the way bots repair their items. The old way captured the opcode 'CMSG_REPAIR_ITEM' (PlayerbotMgr.cpp) only sent when the player selects the 'anvil' at an armour. The patch would be relevant for this code and I will apply it to portal shortly. The new code from the vendor branch is far more versatile and utilizes the new 'findNearbyCreature mechanism'. Simply, if ordered to repair all or only selected items, the bot(s) will wait until they are in close proximity to an armour. Then they will independently approach the armour and complete the task of repair. The code in PlayerbotMgr.cpp is now redundant and thus does not require the patch. This is the playerbot project which is a core modification. You will use MaNGOS as a base for your server code. You are then free to apply various core modifications (playerbot, auctionhousebot, etc) to this. You can do this either by directly merging the mod code into MaNGOS or by applying a pre-prepared (standalone) patch. I prefer the later and use the following bash scripts to create the patches. You can adapt these scripts to create patch from other mods if you wish First get your code base Creates patch from portal master #!/bin/bash -x git clone git://github.com/mangos/mangos.git portal_patch cd portal_patch git fetch git://github.com/blueboy/portal.git master:portal git checkout portal HASH=`git log --pretty=oneline | grep -m 1 '\\[1[0-9]\\{4\\}]' | cut -d " " -f 1` git diff $HASH > playerbot.patch Create patch from alpha branch (e.g vendor) #!/bin/bash -x git clone git://github.com/mangos/mangos.git vendor cd vendor git fetch git://github.com/blueboy/portal.git vendor:vendor git checkout vendor HASH=`git log --pretty=oneline | grep -m 1 'Merge branch' | cut -d " " -f 1` git diff $HASH > vendor.patch To apply the patches, inside the code source directory --check option does a dumby run with the patch, without actually applying it. If no conflicts occur, remove it and run again. --whitespace=fix option as you might guess, checks for unwanted whitespaces in the patch. Remember, the more mods that you attempt to merge into your base, the higher the risk of 'merge conflicts'. These need to be resolved before the merge will take. I recommend that you start by merging only one or to mods at first, until you 'git' more confident (sorry for the pun ). If all goes well, you can then build your code. If you want a playerbot friendly version of 'auctionhousebot' you can obtain it from https://github.com/blueboy/ahbot. It's not as nice as cyberium's code, but it works. Hope this helps

Hi kaxias, Thanks for spotting those omissions, I'm amazed it only caused a warning. I haven't got a 64bit box, so I can't test out the code for VC100 myself. I have now pushed the changes to portal Cheers

Arrh!, that throws water on my idea. Oh well, It looks like your issue is not connected to the issue I'm experiencing. Let me know where your issue occurs (i.e which instance) and I'll see if I can reproduce it on my server. Then I can work on a solution. Yes, 'mmaps' is superb and drastically improves how NPC and bots navigate around fixed objects in the world. A simple example would be, without 'mmap', if the player jumped from the battlements of a tower, so too would the bots. with 'mmaps', if the player jumped, the bots would find a more appropriate path ('pathfinding') by running down the stairs. Far nicer visually. Note that 'vmaps' are still required for height calculations and are not replaced by 'mmaps'. You use both. The 'stuck' issue. Theory 'bot' movement is analogous to 'pet' movement. So if bots get 'stuck', so should pets. Testing There is a tree by the entrance to Saldean's farmhouse in Westfall. If you run around the tree, eventually the bots get 'stuck'. It doesn't occur with mmaps disabled. I have just tested this with a pet and the same thing occurs. I will need to find other locations where this occurs, before I approach the guys at 'MoveMaps'. So anyone who does use 'MoveMaps' and have experienced this issue, feedback would be appreciated ( location coordinate required). Hope this helps

I have a group with 3 bots and me so no need for raid. Sometimes one of the bots enters the instance while the other 2 are not. Sometimes all 3 are left out. Hope you understand what i mean. About the loot issue: i am using the loot-fix-bt code and have the config like this: PlayerbotAI.Collect.Combat = 1 PlayerbotAI.Collect.Quest = 1 PlayerbotAI.Collect.Profession = 1 PlayerbotAI.Collect.Loot = 0 PlayerbotAI.Collect.Skin = 1 PlayerbotAI.Collect.Objects = 1 but i will test a few more times and let you know in detail Hi, By any chance are you using 'movemaps' ? ( I know that is a silliy question, as everyone does). I have noticed recently that the bots frequently get 'stuck'. Ordering the bot to 'follow' or involve them in combat does snap them out of this unresponsive state, but I understand that if would be useless in the case of entering an instance. If you are using 'movemaps' try temporarily disabling this feature in 'mangosd.conf' to see if it still occurs. I am at present looking for a solution on my server and would be interested in any feedback you can give. With your looting issue, I see an obvious difference that might be preventing looting (PlayerbotAI.Collect.Loot = 0). Set this value to 1. Hope this helps, speak with you soon.

Hi thanks for spotting the unecessary whitespaces. I'll apply those changes relevant to playerbot shortly. In Player.cpp @@ -1501,7 +1501,7 @@ void Player::Update( uint32 update_diff, uint32 p_time ) if (IsHasDelayedTeleport()) TeleportTo(m_teleport_dest, m_teleport_options); - // Playerbot mod + // Playerbot mod if (m_playerbotAI) m_playerbotAI->UpdateAI(p_time); else if (m_playerbotMgr) and in WorldSession.cpp, @@ -523,7 +523,7 @@ void WorldSession::LogoutPlayer(bool Save) sSocialMgr.SendFriendStatus(_player, FRIEND_OFFLINE, _player->GetObjectGuid(), true); sSocialMgr.RemovePlayerSocial (_player->GetGUIDLow ()); - // Playerbot - remember player GUID for update SQL below + // Playerbot - remember player GUID for update SQL below uint32 guid = _player->GetGUIDLow(); ///- Remove the player from the world You should notify the guys at MaNGOS with the rest. Cheers

Hi, I see that the first of your observations has been answered. Remember that any materials produced by the disenchantment, can be traded with a bot that does have the skill. With your second, when you say "if I have more bots"; Is this in addition to your group party bots? If this is so, then it's not a bug, but the core preventing non-party members entering the same instance (This is an anti-cheat mechanism). If you wish to enter an instance with a larger group, try converting your standard group to a raid group. That should work, and all member bots should be able to teleport through the portal. With your last observation, have you enabled all default collection settings in file 'playerbot.conf' ? The only setting that requires manual adjustment after a server restart is the collection of nearby objects. This feature has to be 'trained'. By default, the collection of nearby objects is empty and requires input e.g. First do a survey then get and finally to check the settings, collect If you have done all the above and it still errs, are you using the latest code on loot-fix-bt. I'm using this and have not experienced the issues you mention. Hope this helps

Yes, I was thinking the same about the 'quest confirmation text'. When I push it to portal, the text will be there. Thanks for testing the code. Cheers

Hi steveb, vladex has correctly answered the first part of your question, about the disposal of 'gray items'. This is an automatic feature, so there is no specific command. To use, approach a vendor with your party, and just select the vendor. In response to your request for bot(s) to be able to start quests from acquired items, I now have a working solution that I would like you to try, before I push it to portal master. For this code to work, it is necessary to modify the 'SMSG_TRADE_STATUS' code on portal as I have done on vendor. This will enable users to display (i.e. [iTEM LINK]) quest items in the bot inventory (from client 'TRADE' on the bot avatar). I have added conditional code to UseItem() in PlayerbotAI.cpp. This checks whether the item being used actually starts a quest or not. If it does, then a 'CMSG_QUESTGIVER_ACCEPT_QUEST' packet is created and sent, automatically accepting the bot item quest. diff --git a/src/game/playerbot/PlayerbotAI.cpp b/src/game/playerbot/PlayerbotAI.cpp index 4b3f723..bffe9d4 100644 --- a/src/game/playerbot/PlayerbotAI.cpp +++ b/src/game/playerbot/PlayerbotAI.cpp @@ -813,7 +813,7 @@ void PlayerbotAI::HandleBotOutgoingPacket(const WorldPacket& packet) for (uint8 slot = INVENTORY_SLOT_ITEM_START; slot < INVENTORY_SLOT_ITEM_END; slot++) { const Item* const pItem = m_bot->GetItemByPos(INVENTORY_SLOT_BAG_0, slot); - if (pItem && pItem->CanBeTraded()) + if (pItem) { const ItemPrototype* const pItemProto = pItem->GetProto(); @@ -845,7 +845,7 @@ void PlayerbotAI::HandleBotOutgoingPacket(const WorldPacket& packet) for (uint8 slot = 0; slot < pBag->GetBagSize(); ++slot) { const Item* const pItem = m_bot->GetItemByPos(bag, slot); - if (pItem && pItem->CanBeTraded()) + if (pItem) { const ItemPrototype* const pItemProto = pItem->GetProto(); @@ -3621,6 +3621,17 @@ void PlayerbotAI::UseItem(Item *item, uint32 targetFlag, ObjectGuid targetGUID) uint32 glyphIndex = 0; uint8 unk_flags = 0; + if(uint32 questid = item->GetProto()->StartQuest) + { + m_bot->GetMotionMaster()->Clear(true); + WorldPacket* const packet = new WorldPacket(CMSG_QUESTGIVER_ACCEPT_QUEST, 8+4+4); + *packet << item_guid; + *packet << questid; + *packet << uint32(0); + m_bot->GetSession()->QueuePacket(packet); // queue the packet to get around race condition + return; + } + uint32 spellId = 0; for (uint8 i = 0; i < MAX_ITEM_PROTO_SPELLS; ++i) { I have tested the code in 'Eversong Woods' with item [Tainted Arcane Sliver]. Using this item, starts a quest of the same name. if you could test the above patch with other such items (e.g. Westfall Deed) I would appreciate it. Hope this helps

Hi Guys, I've just finsihed the 'bank' plugin for the 'findNearbyCreature() mechanism'. The new 'bank' command will allow bots to access their personal bank account. If the bot is in close proximity to a banker; (Note that the new bank code allows the transaction of 'soulbound' items too) To test the code, [stinging Viper] is soulbound, so to test whether the item can be auctioned, traded or sold, If you try to trade [stinging Viper] with the player, it fails as it should. I will need to revise the SMSG_TRADE_STATUS code in PlayerbotAI.cpp to allow bots to display 'soulbound' items in their inventory. This will allow bots to use 'soulbound' [iTEM LINK]'s for the 'bank' and 'sell' commands The patch and code revisions will be done shortly Hope this helps

Hi Guys, I have revised and improved the 'talent' command code. The new command allows you to also reset all bot talents, if you wish and if you have the gold. The new sub-command 'reset', directs the bot(s) to wait until close enough to an appropriate class trainer and able to reset the bot(s) talents. The command alone In addition to displaying the [TALENT LINK] & [GLYPH LINK] with unspent talent points, will now also display the cost to reset all talents. Code Improvements A problem with the original code was that if the 'talent tab' on the client 'inspect window' was open during the command execution, it was not updated until closed and then re-opened. This was annoying and the new code now updates the 'inspect window' correctly. Because of the dependancy of the new 'talent' command on the 'findNearbyCreature()' mechanism, I have moved the code to the vendor branch and will shortly remove the old talents branch. Hope this helps

Blueboy, as I see you don't update bot_readme.txt. Some new function was added but were not documented. =) Hi, Yes thanks, I do try to update bot_readme.txt, when I can . I do need to add the syntax for the new 'talent' command. The config options you refer to relates to BThallid's loot-fix-bt work (These are default settings for automatic loot collection). I will draw his attention to this next time I speak with him. Hope this helps

If you wish to try the latest playerbot features, I would suggest you use the portal master code as your base and then add features you desire from the alpha branches below. Hope this helps

Hi vladex, Thanks for the heads-up on 'Warden by Neo2003'. I wasn't aware of this code, so thanks. I would suggest that you have answered your own question; I can see why Blizzard use such security systems, but for MaNGOS it's bordering on paranoia. If you are running a large populated server and wish to prevent cheating then, I can see it's relevance. However, the chances are that users of such systems would not be interested in playerbot anyway. If you use a low population server, where playerbot would be an asset, then there are obvoius ways to discipline rogue users. I just hope that the core does not integrate 'Warden', as it will cause lots of developers, lots of problems. As far as the looting issue is concerned, as I have said in a previous post. Occasionally bot(s) do fail to loot, and because of the nature the automated loot collection system, will continue to try looting the same item without success. It is unclear what is causing this issue and we will continue to find a solution. In the meantime, move the bot(s) to new items in new locations and it should work again. If it doesn't and it can be reproduced, your information will be useful in fixing it. Hope this helps

Hi Guys, Thanks for your feedback. I haven't been ignoring you , but working on the request by steveb, for bot(s) to complete explore type quests. The added code will allow party bot(s) to be included in the 'CMSG_AREATRIGGER' rewards. This opcode is only triggered by the player (based on accountid, so only one trigger per accountid) reaching a specified zone. The HandleAreaTriggerOpcode() will ensure that the bot(s) meet the reward criteria. This should work for explore quests such as 'Scouting Fargodeep Mine' etc and 'pursuit' or 'escort' type quests (like the one in Westfall, where you escort a 'salty dude' to the Deadmines. Please let me know how it works. I have checked the looting issue with 'Milly's Harvest' and it works fine for me. I will need you to fully describe your system, so I can rule out a difference in the code used. Hope this helps