blueboy

Hi Guys, The bots can now accept and complete quests from gameobjects. Example. A quest chain that begin with guard Thomas, located at the eastern Elwynn bridge. You are first instructed to [Find the lost Guards]. Travel north upstream towards Stone Cairn lake. Here you will find the corpse of the first guard Malaki. There are two ways the bots can complete these quests, either with the player or without. If the player examines the corpse, the bots close to the player with automaticly turn in the quest [Find the lost Guards] and then accept the new quest [Discover Rolf's fate]. For the bots to do this on their own, Malaki's corpse is treated as a gameobject. So first, execute a 'survey' command to display [A half-eaten body]. Then using the 'get' command, The bots will now travel to the corpse, kneel to open, turn in [Find the lost Guards] and auto-accept [Discover Rolf's fate]. You will then travel to the murloc village to find Rolf's corpse and repeat the process before returning to guard Thomas. I have updated the group loot code for bots. If the bots do not have any space in their inventory, they will pass on the roll. I have updated PlayerbotPaladinAI.cpp to include code to utilize 'Seal of Righteousness', so 'Judgement of Light' and 'Judgement of Wisdom' can be used in combat. I have been examining PlayerbotPriestAI.cpp too. The healing spell LESSER_HEAL was not used to heal target members. The example given by Akuba and kennumen would certainly work, but I feel there maybe a better way. The chain of heal spells replace one another. Once GREATER_HEAL is learnt at level ~38, LESSER_HEAL becomes all but redundant. So too, code expressly referencing LESSER_HEAL. If we were to have a more general condition, say and change the value stored in HEAL, then the code would remain useful A snippet from the initialization of spells, from the priest AI The ReloadAI() function that I have recently added will now update active spells, each time a new spell is learnt. So before the HEAL spell becomes available, HEAL can be equated first to LESSER_HEAL and then to FLASH_HEAL. This I believe will make the code more concise and the AI more flexible. I realise that each spell has it's uses. In combat it would be better to utilize faster yet weaker spells. In non-combat situations, speed of casting is not so important and more powerful spells would be favoured. I suggest that the complexity of AI for each class will evolve in time with your help of course. @kennumen Thanks for the wealth of information you provide. This will be very useful for me and I'm sure many others as we begin to develop the AI. Please bear with me, it will take awhile for me to digest everything before I can comment properly. @Akuba You say that the murloc pets are disappearing below ground. I guess you are not using 'mmaps' then. This provides solidity to visible maps/buildings and 'pathfinding' ensures that land based creatures always follow the most appropriate routes (i.e. above ground level ) travelling from point A to point B. So no more hostile creatures levitating across canyons or else passing through walls to attack you). Once you try it, you won't go back. Hopefully it won't be too long before the code is included in the core. I will be updating the new-ai branch shortly. Hope this helps

Hi I use YTDB myself so I'll pop over to Westfall and see if I get the same. I've taken a quick look at the paladin ai and I agree there is no code to handle "Seal of Righteousness'. Leave it with me and I'll come up with something. The loot roll should be easy to fix. I'll include a condition to force the bots to pass on the loot if their inventories are full. Hope this helps

Hi Guys First of all, I have just pushed the 'revamped bot quest management' code to new-ai branch, as promised. Sorry for the delay, but I had to iron out a few last minute issues with the code. The bot commands should now work much better and I would interested in your comments. Lets keep the momentum going! Talking of comments, it's good to read your discussion on future development of playerbot, with regard to Arenas and Battlegrounds support. I would like to help if I can, but it will require your patience and lots of feedback. This is new ground for me and I have not got a clue about gaming in such areas. I will need lots of help, ideally from guys who can program or at least relate their ideas in pseudo code. I have been approached by many who claim that they can rewrite the playerbot ai, but all seem to vanish into the woodwork. I like the idea of building modular code that could be utilized in a macro or scripting environment and so expertise in these areas would also be welcomed. @Akuba Thanks for your contribution. I plan to include your suggested revision in the new-ai code shortly. I also look forward to hear about this issue, causing your server to crash. I have just pushed revised code to new-ai that may resolve these issues, but if not we'll sort you out Hope this helps

Hi Guys, I have revamped code related to bot quest management and have a few improvements, that I will shortly push to the 'new-ai' branch. The 'report' command will now monitor quest required creatures and gameobjects in addition to the existing required items. The 'drop' command has been removed and now included as a sub-command in a far more comprehensive 'quest' command. The bots can now undertake class related quests. The new 'quest' command utilizes the findNearbyCreature() mechanism and bot(s) will approach the nearest questgiver before interacting. I have reduced the creature search radius (i.e. INTERACTION_DISTANCE), to minimize confusion that may occur if two or more questgivers are close together. The user should ideally execute all commands when the bot(s) are within close proximity to the desired questgiver. quest will show the status of active bot quests, as [Quest link]s (bot(s) do not need to be close to questgiver). quest < list | l > will show all quests available to bot from the nearest questgiver, as [Quest link]s. quest < drop | d > [Quest Link] will drop an active bot quest. (bot(s) do not need to be close to questgiver). quest < add | a > [Quest Link]... will add or start specified ([Quest link]s) quests, obtained from the 'list' sub-command. quest < end | e > will 'turn in' valid completed quests to the questgiver. The user will also be asked to select rewards, if there is a choice.I have also improved the 'skill' command by adding an audible response. If bot(s) do not have enough gold the bot will make an announcment, alerting the user. Audible responses only have limited use with playerbot however, as generally alerts occur to more than one bot at a time (e.g. Inventory being full) and bots will tend to talk at once. As I said in my last reply, I do appreciate help from gamers who understand the game better than I, and your information is very useful. So I again thank you for your input and I will endeavour address your suggestions now that I have a clearer understanding. Hope you all enjoy the changes.

Hi kennumen, The playerbot code will not have an effect of how real players react with mobs. If as you say the bots and pets aggro correctly, it must be something else causing this passive behaviour. What other mods are you running? Interesting suggestion. As I understand, you wish to be able to 'recall' the bots during combat. I have recently been exploring ways to make bot ai more realistic and adaptive to changes in circumstances (e.g. Druids by default have melee attack, although they possess some quite useful ranged spells. If the bots had the ability to switch their attack mode they could be more effective in a fight. This may also be influenced by the status of other party members). I don't get much chance to play the game myself (having zero raid experience) and I always appreciate input from those who have. I'm not sure how tolerant hostiles would be if provoked by a phased attack. In my experience hostiles will react immediately and do not give up unless you were to turn and outrun them. At which point the 'threat level' will drop sharply, and they would not be further provoked until their status resets. It maybe possible to distract the hostile during attack, by drawing it's fire. Forcing the hostile to repeatedly change it's target (bot presenting a higher threat), but it would be complex to orchestrate. It certainly will be something to consider as we develop the ai further. Thanks

Hi Guys. I have improved the bot AI, with several changes Increased bot combat efficiency, by improving the success rate of spell casting. Fixed a long term problem where bots would frequently get stuck in spell casting limbo, after combat, (e.g. Hunters would aim their ranged weapons & Mages would be poised with fireballs, towards imaginary targets). Bots having ranged combat will now tend to keep their distance from the target, while those having melee combat will go in and tank. I have improved the appearance of bot combat, by removing code causing movement lag/hysteria, (e.g. bots appearing to run on the spot or sliding towards the target). The bots now correctly turn and face their targets during combat. Bots can now cast newly learnt spells immediately. There is no longer any need to resummon bots before they can utilize buffs. If you would like to try this code, I'll be pushing it to the 'alpha' branch new-ai shortly. Hope this helps.

Hi Guys, I have just merged the code from the loot-fix-bt and vendor branches, with that in the portal master. It goes without saying that it is not necessary to re-apply code from these alpha branches, when building your servers. I have done some tests and it compiles and appears to run without issue. Please let us know if you experience any problems. Hope this helps

The commands syntax is displayed whenever you mis-type a command to a specific bot e.g. It does not display if you mis-type commands to the party This was always displayed when a command was misunderstood by playerbot original 'msg' string I have updated the code to clearly 8o show the syntax for all commands. I know that the code formatting is complex, but the displayed result is better, but I agree annoying. I realise that in the heat of battle, command mis-typing will happen more frequently. What I will do is revert to the original 'msg' format and only show the syntax menu if you type say I will be working on re-introducing command shortcuts (e.g cast [Fireball] or c [Fireball]) to reduce the amount of typing required. I was forced to remove them because the command vocabulary has grown and confusion was caused when the shortcuts were parsed and this led to a crash. Leave it with me. If you wish to disable this altogether, just comment out the 'msg' contents at the foot of PlayerbotAI.cpp and then re-compile Hope this helps

Hi Guys, Playerbot support for MaNGOS zero is now live @ portalzero The initial playerbot patch includes additional code from the loot-fix-bt and vendor branches, adjusted to function with MaNGOS zero code. I have tested the following commands and they all appear to function without issue (Bot flight, SellGarbage and Bot Guy also work). Please keep us posted if you experience any issues. Here is an example script for you to create a standalone patch. Hope this helps

Hi, I will be updating the main playerbot repo and blueboy repo soon. I left them alone until such time that they have got over the teething period (with the addition of AuctionHouseBot) in the core. I have just tried the code from portal with the latest core and it applies without issue. Good News @All: I am busy at present creating a compatible playerbot patch to work with MaNGOS zero. I have got the patch working and I am just ironing out a few things before I release the code. I will obvoiusly be creating a new repo called portal_zero to hold the revised code. Hope this helps

Hi Bramm, If you could develop an algorithm to prevent (or reduce) bot collision in crowds, that would be brilliant. Your code snippet looks sound and in theory it should work. I in no way wish to discourage you from having a go, but I must tell you that many have tried before, without success ( there's the challenge ) Possible pitfalls you might find UpdateAI() can be useful to provide feedback in bot control loops, but should be used with caution. You'll probably find that adjusting the relative position on each cycle of the loop may cause continual undesirable movement in the bots. Another problem visually is caused because the bots are not solid objects. If two player characters were to collide, they would just bounce off one another. If two bots were to collide, they will merge into one. If you could post your patches on the forum we'll certainly test them out with pleasure and thanks in advance for your time and interest in playerbot. Cheers

Hi, O.K I have managed to compile the playerbot code with the latest MaNGOS zero, with alot of chopping. I have no idea what still works, until I have chance to test it out. So please bear with me and I'll post here once I have more news Hope this helps

The simple answer is no, but that's purely because I have never tried MaNGOS zero. I know this version of the core does not yet include AuctionHouseBot, so a patch created from our portal branch would not work, without extensive modification. However, we have not yet updated the blueboy or main playerbot repos. As a test, I have just modified (using blueboy code) a patch that did apply to MaNGOS zero without issue. However, it failed to compile and from what I could see it wasn't solely the fault of playerbot. I'm a little puzzled by the version you give. The current version of MaNGOS zero is [z1765], is Mangoszero 0380 a repack? If it is, then the answer is definitely no, as it would suicide to try and support every flavour and variation out there. If you are using the offical MaNGOS zero core, then I will give you what help I can, but I can't promise it will work Hope this helps

Hi Guys, For sometime now I have noticed an issue with the collection of quest items by bots, using the findNearbyGO() mechanism. Frequently the bots will repeatedly fail to retrieve the quest items, whispering Collection was unpredicatable and it was a real concern as an objective of a quest. This comment originates from the DoLoot() function, but I could not find any obvious reason why it should happen. On further investigation it was clear the bots were repeatedly failing to ; The debug logs show that each time the spell succeeds, the following chain of opcodes are triggered and if it fails I then examined the playerbot handlers for these opcodes in HandleBotOutgoingPacket(), PlayerbotAI.cpp. Comparing how the core builds the SMSG_SPELL_GO packet data in Spell.cpp, with the way playerbot reads that data... (using the FIFO (First In First Out) concept, with distinct data size boundaries), I found a discrepancy. Spell.cpp PlayerbotAI.cpp You will see that there are clear differences that will cause erroneous results. This will lead to bogus values for spellId (only data value actually used here). I have now corrected the data sizes and order in which relevant data is read. Also, in the same block of code for the condition below, I found another problem. m_CurrentlyCastingSpellId was found to always be zero. So the conditional code would never be executed, even if the spell was cast successfully. I found that m_CurrentlyCastingSpellId is only set in function CastSpell(), PlayerbotAI.cpp. Looking at the code as a whole, it is easy to see that m_CurrentlyCastingSpellId is never set, due to it's location. So, I relocated it to a position just prior to spell actually being cast. I have also changed how update delay (m_ignoreAIUpdatesUntilTime) is calculated where CastingTime is based on whether the spell is channeled or not. Patch: diff --git a/src/game/playerbot/PlayerbotAI.cpp b/src/game/playerbot/PlayerbotAI.cpp index 774937e..428198f 100644 --- a/src/game/playerbot/PlayerbotAI.cpp +++ b/src/game/playerbot/PlayerbotAI.cpp @@ -1114,14 +1114,14 @@ void PlayerbotAI::HandleBotOutgoingPacket(const WorldPacket& packet) if (casterGuid != m_bot->GetObjectGuid()) return; + uint8 castCount; + p >> castCount; uint32 spellId; p >> spellId; - uint16 castFlags; + uint32 castFlags; p >> castFlags; uint32 msTime; p >> msTime; - uint8 numHit; - p >> numHit; if (m_CurrentlyCastingSpellId == spellId) { @@ -1129,8 +1129,9 @@ void PlayerbotAI::HandleBotOutgoingPacket(const WorldPacket& packet) if (!pSpell) return; + uint32 CastingTime = !IsChanneledSpell(pSpell->m_spellInfo) ? GetSpellCastTime(pSpell->m_spellInfo) : GetSpellDuration(pSpell->m_spellInfo); if (pSpell->IsChannelActive() || pSpell->IsAutoRepeat()) - m_ignoreAIUpdatesUntilTime = time(0) + (GetSpellDuration(pSpell->m_spellInfo) / 1000) + 1; + m_ignoreAIUpdatesUntilTime = time(0) + (CastingTime / 1000) + 1; else if (pSpell->IsAutoRepeat()) m_ignoreAIUpdatesUntilTime = time(0) + 6; else @@ -3052,6 +3053,11 @@ bool PlayerbotAI::CastSpell(uint32 spellId) if (pSpellInfo->Effect[0] == SPELL_EFFECT_OPEN_LOCK) target_type = TARGET_FLAG_OBJECT; + uint32 CastingTime = !IsChanneledSpell(pSpellInfo) ? GetSpellCastTime(pSpellInfo) : GetSpellDuration(pSpellInfo); + + m_CurrentlyCastingSpellId = spellId; + m_ignoreAIUpdatesUntilTime = time(0) + ( CastingTime / 1000) + 1; + if (pSpellInfo->Effect[0] == SPELL_EFFECT_OPEN_LOCK || pSpellInfo->Effect[0] == SPELL_EFFECT_SKINNING) { @@ -3078,13 +3084,6 @@ bool PlayerbotAI::CastSpell(uint32 spellId) else m_bot->CastSpell(pTarget, pSpellInfo, false); // actually cast spell - Spell* const pSpell = m_bot->FindCurrentSpellBySpellId(spellId); - if (!pSpell) - return false; - - m_CurrentlyCastingSpellId = spellId; - m_ignoreAIUpdatesUntilTime = time(0) + (int32) ((float) pSpell->GetCastTime() / 1000.0f) + 1; - // if this caused the caster to move (blink) update the position // I think this is normally done on the client // this should be done on spell success I have already carried out some testing and it appears to solve the collection issue, but we would be interested in getting your feedback. Hope this helps

Hi Guys, This is an announcement of changes to the blueboy GitHub repositories. Now that AuctionHouseBot is included in the core there does not seem any point in maintaining the 'ahbot' respository any longer. I propose to remove this shortly and replace it with code for a new project suggested by tyrael. I have created a working patch for the project 'gmguy', and the code will be available shortly. This project is independent of playerbot and I hope that tyrael will take the opportunity to start a new topic in the core modification forum. All further discussion related to gmguy will then take place there. Overview of 'gmguy' gmguy is a new chat command enabling players to resolve routine maintenance tasks which would otherwise done by the server admin. (Please note that the use of this command is fully controlled by the server admin and does not pose a security risk). The command can be enabled/disabled only by the server admin in the mangosd.conf file. The first sub-command included with the patch is 'quest' To select the [Quest Link] <Shift Click> on the quest from the client objectives menu. This will enable players to autocomplete selective quests, known to give problems in normal completion. The server admin will control which quests can be autocompleted by listing them again in mangosd.conf The example list above will allow players with a human faction character to autocomplete all trial quests in 'Northshire'. The quest sub-command utilizes the core command 'HandleQuestCompleteCommand' to provide the character with what it requires to normally complete the quest. The character will still need to visit the appropriate 'questgiver' and collect the reward to continue the quest chain. EDIT: As promised I have now created a new repo 'gmguy' Hope this helps

Hi tyrael, I will keep this short, but contact me on 'PM', I may have something to get you started. You can find plenty of info/tutorials online to learn c++. Hope this helps

I fully agree, but tyrael admits his programming experience is limited and I just want to help him get started. Once he is more comfortable with the code, he can start an independent core modification. Cheers

Hi tyrael, You have a good idea and the enthusiasm to have a go The programming side can be learnt and I will help you all I can. Two questions for you, so I know what you need... You say that you have zero C++ experience. Have you had any experience with other computer languages? How much experience have you got with git? EDIT: I been thinking about your idea and have a suggestion. I don't think it is necessary to have a 'gmguy' on GM Island to service the users issues. Why not do everything using the ChatHandler system! Create a chat command e.g .gmguy accessible by all players. This command could be enabled/disabled by the server admin at will in the playerbot.conf file. This would avoid the need to teleport the player from their current location and the added complication of processing tickets. The command could then have a series of sub-commands e.g quest. So if a player finds that they have a quest that seems to be broken, they can enter something like .gmguy quest [Milly's Harvest] The [Milly's Harvest] link will hold all relevant info pertaining to the quest. If there is a known issue with this quest it can then be autocompleted by sending a database update using the quest id. The server admin can control those quests that can be autocompleted, again through playerbot.conf, Further sub-commands could be then added as the project develops. Speak with you soon

Hi tyrael, A very interesting idea and worth pursuing. A GM bot to automate what are very mundane tasks, and I'm sure it would be particularly popular with admins of middle to high population servers. I would suggest that it is developed as a separate (optional) patch, compatible with playerbot. You maybe aware that we develop our code in the 'alpha branches' off the portal master repo. I remember the debate over the original 'botguy' (a.k.a Pappy Looter) code that was a hassle to use and caused frequent crashes. Eventually we found a way to incorporate the features into playerbot. Maybe you could adapt the botguy code for your suggested 'gmguy', as an optional patch for those who wish to use it. Let me know what you think and how involved you wish to be in it's development. Thanks for your suggestion

Hi Guys, I've just got a moment to spend online. I've merged the code on portal master with the latest MaNGOS [11565] and it compiles and runs without issue. I have also merged portal master with blueboy master and playerbot master. This should stop the errors you're getting, caused by several variables being renamed in the core. Hope this helps

Hi Kreegoth, Sorry, I've got a family crisis on at present, so I can't spend too much time on the computer. It does sound like there maybe some conditional code preventing the healing process, if the healing target is beyond a certain distance. It may even be a condition of the healing spells. Take a look at wowhead to see if the player is beyond the ranged distance for the spell. EDIT: I've just read the last part of your post , and the spell range is not the cause. Take a look in PlayerbotAI.cpp, and particularly at the code for spell casting. Hope this helps

Hi, I might know what is stopping your priest from healing. I created your patch as a modification to the PlayerbotPriestAI that I modified on new-ai. Did you apply the AI from new-ai before you applied your patch. 1. use base code from portal master 2. apply patch from new-ai 3. apply patch from your revised code. I looked at my modified PlayerbotPriestAI.cpp and it doesn't have the conditional code for setting 'SpellSequence'. i.e if (ai->GetCombatOrder() == PlayerbotAI::ORDERS_HEAL ) // && ai->GetMovementOrder() == PlayerbotAI::MOVEMENT_STAY) SpellSequence = SPELL_HOLY; else if( ai->GetCombatOrder() == PlayerbotAI::ORDERS_ASSIST ) // && ai->GetMovementOrder() == PlayerbotAI::MOVEMENT_STAY) SpellSequence = SPELL_SHADOWMAGIC; else SpellSequence = SPELL_HOLY; It's late here and my brian is on shutdown. I will try to make sense of this tomorrow Hope this helps

Not yet but I'll do my best to check it out in the next couple of days. Create a working patch for your work ( I run a unix box, but you can emulate the command instructions on windows) From your chosen root directory, create two parallel directory trees a & b. and Note the -p option forces the creation of subdirectories The 'a' tree will hold your reference files and the 'b' tree will hold your modified files Right now you need to copy the relevant files to these empty trees. I will use the files from 'new-ai' as an example throughout. navigate to the directory where the target files exist. Then copy the files to the appropriate directories in the 'a' and 'b' trees example check The files in both trees are identical so the following command (from a & b root) will in theory produce a blank patch If it doesn't, check that you have copied all the relevant files. Now you can modify the files in the 'b' tree. Once done, run above command again and produce a raw patch. The raw patch will need some manual editing. Each file mod in the patch, will have a header. example header In the raw patch, you will observe an additional directory level (highlighted 'a/' and 'b/'), that will break the patch if not removed. This gives, Do this to all file mods in the raw patch to produce a working patch. Now practice creating your own patches and then I'll show you how to apply these and push your changes to 'new-ai'. I have now added you to the collaborators list for portal and sub-branches Hope this helps

No problems, neither did I when I started with playerbot Patches are easy to create and I'll shortly post example instructions, to get you started. Cheers

Hi Kreegoth, Thanks very much for your contribution, I will try it out and get back to you as soon as I can. I would like to add you to the collaborators list for the GitHub repos, if you are interested. That way you will be able to push your work directly for others to use. If you are interested, I will give you any help you need to push your code. Thanks again