blueboy

Hi, I have a small guild group, including a warlock and a priest. The warlock's imp invariably instigates attack, although I have him set on defence. Are you sure the imp, succubus, etc.. is configured correctly? Are the demon spells activated or not. When you say 'heal friends', are these members of the same bot group? As far as I know, if the priest's combat orders are set to heal, it will heal only members of the same bot group and the player master. Let me know on this thread, my private message box is nearly full. Cheers

Hi Guys, Revision of get patch (rev.2) I have now revised the get command to allow mining of minerals and milling of herbs. All bot(s) can do this, as long as they have the relevant skills and in the case of mining, a trusty pick Revision of survey patch (rev.3) I have also updated the survey command, to behave as I would like. It now filters out used items from the link string list. To use the revised commands First use the survey command to detect & display all available gameobjects, local to the bot(s) This lists all available gameobjects local to the bot(s), in [link string] format. Then hold down the shift key and select the desired [link string] (e.g [Copper Vein]) with your mouse. Summary of how it works (pseudo code) IF ( bot(s) have the necessary skills (i.e mining or herbalism) ) IF ( [For mining only] bot(s) possess a tool capable of mining (i.e pick or hammer/pick) ) IF ( bot(s) inventory can hold mined or milled items ) IF ( bots(s) have the relevant skill level ) { get items; update skill level; } Due to the size of these patches, I propose to add them to the code on blueboy, and carry out further development in-situ. I will updated the code shortly, after merging with the latest MaNGOS. EDIT: The updated code is now live on blueboy for you guys to use. Feedback would be appreciated. Hope this helps

Hi, Well spotted, a typo on my part

Hi, These are the default attack modes for the bot classes. The bot(s) will try to use these preferred modes. However, you will appreciate that in close combat, ranged weapons cannot be used and they will switch to melee. Sometimes bot(s) do go haywire, shooting at nothing or running back and forth (stuck in combat mode). Use the reset command to gain contol again. The bot|(s) also have an annoying habit of leaving you in the thick of it. Look around whilst in combat with a 'boss hostile' and they seem to be standing on the sidelines, having a smoke. After you manage to killl the hostile, on your own, they join you again. If you do need them to help, use my favourite :rolleyes: reset command to snap them out of it. Hope this helps

Hi, I know what you mean, the bots do occasionally seem to disobey orders, but I find that adds a certain realism to the AI :rolleyes: The larger the bot group, the more conspicuous you become. The problem is that the bot(s) are within attack distance of a hostile, they may well be detected and thus be targeted. The bot(s) are just defending themselves. It might seem that you have lost control , but they just following orders. Even bot(s) set to heal will use aggressive spells to defend from attack. I suggest that you remain far enough away from the hostiles, such that they do do detect your group. If you then target a hostile with your mouse and use the point command ( I suggest you set this up as a macro, assigned to menu button), the party will then proceed to attack. I like to use a player rogue, with stealth to lead the attack. The hostile will not necessarily detect the rogue, but the bot(s) that follow. You can then decide to use a surprise stealth manoeuvre to finsih off the hostile. Occasionally the bot(s) in the process of combat will become visible to further hostiles and combat then continues. If you wish to break off such attack, use the follow or reset commands Obviously, if you only want one of your bot to attack, you can use whisper (/w) rather than party (/p) chat prerequisite. EDIT Your right, the point command is not documented in the 'bot_readme.txt' file. It was added prior to my arrival, but I will remedy this on the next update. Cheers Hope this helps

Hi, I'm not sure exactly what you are unhappy with. You would like a hold command. How does that differ from the stay command? If you remain a safe distance from a hostile, the bot(s) will not attack. If you then use the point command, they will then attack the selected target. Are you suggesting that the bot(s) turn their own quests in? Sorry but there is a limit to the complexity of the AI. The bot(s) are provided to assist the player and not become autonomous. But if you have any ideas how this can be done, I would be very interested. As far as I know, the healing with bot(s) works fine. Priests, Druids, Paladins & Shaman are all capable of harming and healing. Are you suggesting that they should not defend themselves. Attack can be the best form of defence. If you want to customise your own system, then just remove the harmfull spells and they will then use all available mana on healing spells Cheers

Hi Guys, You might be wondering why I have merged the code on blueboy with the MaNGOS branch, twice. I first merged with [9792] and then the latest commit [9793] caused a merge conflict. Hope this helps

The survey patch and get patch are still in the beta test phase at present, and won't be included in the branch until they have been revised & fully tested. The repair patch is already in the branch :confused: Cheers

Hi, a huge step indeed , we shall have to put your suggestion on the wish list. I do intend to revise the 'get' command eventually to cover most of what you ask. I know klunk was working on a patch to facilitate bot(s) trading with vendors, but he hasn't posted anything recently. Cheers

Hi, Bad news. You will probably find "answers from bot(s) to player", in all files. Diablox was quite correct in suggesting PlayerbotAI.cpp as this contains the command handler. However, the class AI files handle bot spells and these often include verbal responses. Hope this helps

Hi, Yes I had a great time, it was my nephew's wedding:D I have just updated the code on blueboy to include the core revision [9770] that fixes a build error on linux, from [9767] EDIT: The fix in commit [9770] didn't work. I notified getmangos.eu this morning, with a working solution. I will wait for the fix to be applied to the core, but in the meantime; Edit CLIRunnable.cpp @ line 320 change this to and it will work Hope this helps

Hi, It will pull now , I have just updated the code on blueboy Hope this helps

Hi Guys, I have revised the 'free' command. I'm not sure whether you use it at present, but I thought I could improve upon the information it provides. I have also renamed it to something more appropriate. The new name is 'stats'. First Feature: Have you ever needed to know how much money the bot(s) has. At present, the only way to do this is by trading. The bot(s) will list available money and all inventory items (can be many). The trade dialog also pops up over this info. You then have to close the dialog and scroll back to find the amount. You will appreciate that this can be a real pain. The revised 'stats' command displays all info in a single line, so you can easily view statistics on all group members, without fuss. Second Feature: Free bag slots are displayed, as they were with the 'free' command. Third Feature: It is easy to view personal item damage and the cost of item repair, at the NPC anvil. But, you can't at present determine the damage for the bot(s) or easilty evaluate whether the bot(s) can afford repair. The new stats command allows you to do this from anywhere. I will update the code on blueboy shortly to include this revision. I have also been testing the repair patch without fault and I have not receive any bad reports, so I propose to include this in the update too. Thanks to UnkleNuke & deviljohn for the info on recent changes with 'flight speed' auras. I will include these changes in the update. NOTE: Do not pull the merge, pull the commit that follows Hope you like the changes

Hi Guys, Looks like it's just me testing this fix. I have found a loophole in my fix. The fix works fine if the player continues to return to the instance, after death. However, if the player chooses to be resurrected by the spirit healer, we again have the situation where the player and bot(s) are separated between instances. As soon as the bot(s) then try to teleport to the player, the server will crash. Solution I have found that the instability has something to do with group membership. If the group is disbanded, no crash occurs. I thought that it would be fitting to reward the player's treachery in using the spirit healer, by triggering a breakup of the group. I have written code that will capture the CMSG_SPIRIT_HEALER_ACTIVATE opcode and direct member bots to leave the group. The bot(s) will still travel to the players location, but the server no longer crashes. Once all bots are assembled, you can again invite them (if they forgive you :rolleyes:) to form a new group. I will update the code on blueboy shortly, so you can test it. Hope this helps

Hi Guys, Since posting the fix for this issue I have experienced further crashes without warning, when the player and bot(s) are separated between instances. After several crashes, it was clear that the crash only occurs if the player is dead and in transit between the graveyard and it's corpse. If the bot(s) then try to teleport from the instance to the player, BANG!:mad: Logically there is no advantage in the bot(s) teleporting to the player's ghost. So in the FollowCheckTeleport function @ line 2546 in PlayerbotAI.cpp I have included a condition to prevent the bot(s) teleporting, while the player is dead. They will now remain by the player's corpse or at least in the same instance as the player's corpse. I have tested this update with instance (The Deadmines, Westfall) and so far so good. I would welcome feedback, good or bad. EDIT: I will update the code on blueboy shortly Hope this helps

Hi Guys, Sorry for my absence, but it has given me a chance to examine this issue more closely, and also play the game Issue - Premature reset on the current map - m_currMap Whilst in an instance (Dungeon) with a group of bots. If the player dies and is removed from the instance to the nearest graveyard. The bots will try to follow, attempting teleportation. As they do, the following assertion error occurs, Solution Essentially the function GetMap is being called. The current map (m_currMap), has a NULL value. This then causes the assertion. I first scattered flags in the code to follow the program flow. I traced the issue to bool Player::TeleportTo(uint32 mapid, float x, float y, float z, float orientation, uint32 options) located @ line 1648 in Player.cpp. Initially I thought the following might be the cause, @ line 1754 The flags at this point showed that m_currMap has a valid map location. However at line 1848 in Player.cpp, the function, void Map::Remove(Player *player, bool remove) is called from Map.cpp @ line 719. This ultimately resets the current map to NULL @ line 764 with a call to the function ResetMap() Later GetMap() is called again, but this time m_currMap is NULL and the assertion occurs. All I have done is to comment out the call to ResetMap() in Map.cpp; I have tested the solution by completing the 'Wailing Caverns' dungeon, without any server crash. I would appreciate it if you Guys could do the same in a dungeon of your choice and give me some feedback. I will shortly update the code on blueboy, with this solution included for you to test. P.S. Since commenting on the difficulties on the auctionhousebot thread, Xeross has updated his Github and I can confirm that it works fine with the latest MaNGOS. As UnkleNuke correctly points out, both playerbot and auctionhousebot will work, with a little adjustment for core changes. Hope this helps

Hi deviljohn, Brilliant that you have got it working, I'm going to be away for the next few days and I was worried that I was going to leave playerbot broken. Hopefully, it will remain problem free, at least until I get back. I built a windows test server and found GitBash useful in running the relevant scripts. Do you create and apply patches under windows. This might avoid this issue occuring again. I like to always start with a clean download of MaNGOS, and then apply the necessary mods. If you are interested I can post the adapted scripts I created under linux, to aid in building on windows. Interesting, I didn't realise that ScriptDev2 was available on Github. I'm still pulling it from Subversion. I use the following script to pull a specific version of ScriptDev2, rather than always the branch HEAD (e.g ./scriptdev2.sh 1670). #!/bin/bash unset VERSION unset DEST VERSION=$1 DEST="E:\\mangos\\src\\src\\bindings\\ScriptDev2" if [ -z "${VERSION}" ]; then echo "No ScriptDev2 VERSION specified, assume latest VERSION"; else VERSION="-r "${VERSION}; fi if [ -d "${DEST}" ]; then rm -R ${DEST}; fi mkdir ${DEST}; svn co [url]https://scriptdev2.svn.sourceforge.net/svnroot/scriptdev2/[/url] ${DEST} ${VERSION} As far as auctionhousebot is concerned I am presently not using it, and I certainly wouldn't pull from the Naicisum's Github, that has now well and truly stagnated. Hopefully it will not be long before Xeross has his Github running with the latest MaNGOS. Hope this helps

Hi, I must admit I am very puzzled by your errors, I'm getting no problems with group invitation. Looking at the MaNGOS changelog, changes have been made http://github.com/mangos/mangos/commit/5ca7c18fe3117e6d2b6c80d1a9c0ecb7d3497833 to group invites. I had to comment out the line @ 169 below from GroupHandler.cpp to allow invites. Check that this is still commented out. The error also suggests that your running the client on the same machine as the server, Is this true? Take a look at the commit I have referenced above and compare the changes with the code on your machine. EDIT: How are you preparing the code for build? Are you downloading the code from blueboy, then merging with the MaNGOS head? If so, then that would account for the problems with group invites. The MaNGOS code will effectively reverse the changes I have made in GroupHandler.cpp. Let me know how you get on.

Hi Guys, The conflicts with GroupHandler.cpp were changes made to code comments, but are now sorted. I have just updated the code on blueboy to be compatible with MaNGOS[9701] and the new 3.3.3. client update ( remember to change your dbc, maps & vmaps). I have tested the code with; MaNGOS[9702] ScriptDev2[1671] The code compiles and runs without issue. Hope this helps

Hi, Did you use the script I provided. I have just tried it and it works perfectly. I can't make the instructions any simpler. Your script is wrong. Alternatively, do as mrelfire suggests and just clone the code on blueboy to your harddrive and build that. If you are using windows, and a Bash emulator shell (Git Bash), perhaps that is not working correctly. However, I have used it myself without problems. Cheers

Hi, Not very easy to read, but I would say that you have created a bad patch. Your script is wrong. mangos should be playerbot. The playerbot patch would have no reason to update the MaNGOS sql files, as the errors suggest. I see from your last post that you copied the example I gave you, Why not start by using the version of MaNGOS that the code on blueboy is currently integrated with. i.e MaNGOS[9644]. I will now give you step-by-step instructions. First, create the patch using this script, courtesy of skinlayers #!/bin/bash -x git clone git://github.com/mangos/mangos.git playerbot cd playerbot git fetch git://github.com/blueboy/mangos.git master:Playerbot git checkout playerbot HASH=`git log --pretty=oneline | grep -m 1 '\\[9[0-9]\\{3\\}]' | cut -d " " -f 1` git diff $HASH > playerbot.patch then > git clone git://github.com/mangos/mangos.git > cd mangos git log to get the HASH code 91d5f2300cb0780830ac5634ac29b1c7ea16a96a for MaNGOS[9644] > git checkout -b 9644 91d5f2300cb0780830ac5634ac29b1c7ea16a96a Switched to a new branch '9644' Finally apply the patch. It is a good idea to use the '--check' option, should there be any errors :rolleyes: > git apply --check --whitespace=fix playerbot.patch or if you have the Gnu patch utility. This uses --dry-run equivalent to --check for git. > patch --dry-run -p1 < playerbot.patch Note: Remove --check or --dry-run , to actually apply patch Hope this helps

Hi, Yes I try to read this thread, unlike most. Are you offering to help, there is a limit to what one person can do. Cheers

Hi, If you give us some details on the errors we might be able to help. 'loads of errors' tells us nothing and these errors are not happening to most users of playerbot. Cheers

Hi, Looking at your first code box, I noticed that the commandline and are broken with what looks like a carriage return. try removing it, to look like this I can confirm that it works on my linux box #!/bin/bash -x git clone git://github.com/mangos/mangos.git auction cd auction git fetch git://github.com/xeross/mangos.git ahbot:auction git checkout auction HASH=`git log --pretty=oneline | grep -m 1 '\\[9[0-9]\\{3\\}]' | cut -d " " -f 1` git diff $HASH > ahbot.patch I also note from your command prompt, that your using windows. Maybe the bash shell that your running the script in does not support this '-m' option for grep. Hope this helps

Hi, The easiest solution would be for you to send me a private message, and I will do my best to help you Cheers