blueboy

Hi klunk, Any quest that requires the bots to interact or use an item, can not at present be completed. The bots can acquire the quest but need help to finish them. e.g collecting logs, in Eastvale Logging camp, or picking fruit for Milly in Northshire. At present you will have to log in as the player for each bot, in order to complete the quest. This is a feature that definitely needs addressing. The GOSSIP_enum effect with trainers is messy at present. They have only recently changed how this works in MaNGOS. The mechanics are present and working in the core, however it is not a priority to the guys who develop the databases. You could do as erazare suggests and populate the relevant table yourself, or wait until they get around to fixing them. The same is true for vehicles, a feature fully supported in WOW, but can only at present be introduced as a mod. Under the hood, there is still alot of work to be done. If you would like to tackle any discrepancy, that would be great. The 'floor'issue you mentioned, for instance. Cheers

Hi, The bots will not loot ordinary items from corpses, but they will take required quest items. They will also take part in 'group loot rolls'. Or at least they should. Let me know if they don't. @Everyone - I will reiterate what rrtn said shortly after I joined the forum. All contributions are welcome, particularly those to improve the AI of playerbot. If you have an improvement you have created and wish to see it in the main code, please submit a patch in this thread for people to test. I will then commit it to blueboy, giving you credit for your work. Cheers

Hi Guys, The new code is now live on blueboy. The latest release is compatible with MaNGOS[9204], and compiles without issue. I have tested it with; MaNGOS[9204] SD2[1546] auctionhousebot autobroadcast I didn't test Tasssadar vehicle code with the server. However, a patch created from the latest release (merged with MaNGOS[9202]) applied with only one issue. That was the conflict with Player.h, explained in previous posts. After the patch was adjusted it integrated without issue. I decided it was only necessary to comment out the ' recv_data.read_skip<uint32>();' line in the ' void WorldSession::HandleGroupAcceptOpcode( WorldPacket & recv_data )' function, within GroupHandler.cpp. The group invite now works perfectly Cheers

Hi klunk, Yes, for some reason I'm getting a 'CHAT' message flagged on the server when the invitation occurs. The value of 'lang' passed to the chat handler seem very dubious ( lang = 4294967295). This only happens with one of my characeter groups, so it might an isolated incident. Yes, the floor issue is something that needs attention, but will take awhile to resolve. At present it's on 'the backburner'. Cheers

Hi klunk Thanks for checking it out. If you enter '/p' (party) at the command line with 'invite', I am not suprised you get a 'What?' whisper. There isn't an 'invite' command supported with Playerbot. What I have found is that the ChatHandler is being called when you do a menu invite. I have looked at the text, and it is garbage, and the same text each time. I am trying to silence this. Cheers

Hi erazare, No I haven't updated the blueboy repo yet. I was hoping to get feedback from you guys before pushing the changes. Cheers

Hi Guys, One other issue that I get on my server that may occur on yours. When the 'group invitation' works, the bots whisper that they do not understand the command, at the client? Are you getting this too? Let me know.

Hi Guys, Yes I have found a solution. I changed a pointer to the players name. I thought that if the members name was obtained from the CMSG_GROUP_INVITE, then it made sense that this should also be passed to the SMSG_GROUP_INVITE. You will see where I have commented out GetPlayer()->GetName(); and replaced it with membername; In 'void WorldSession::HandleGroupInviteOpcode( WorldPacket & recv_data ), GroupHandler.cpp'; // ok, we do it WorldPacket data(SMSG_GROUP_INVITE, 10); // guess size data << uint8(1); // ok data << membername; // GetPlayer()->GetName(); player->GetSession()->SendPacket(&data); I will make a temporary patch shortly for you to test out, or just change the value and see if it works. @klunk It would useful if you can check that my change does not mess up real player groups. Edit: One further change. Comment out recv_data.read_skip<uint32>(); In GroupHandler.cpp void WorldSession::HandleGroupAcceptOpcode( WorldPacket & recv_data ) { // recv_data.read_skip<uint32>(); // value received in WorldSession::HandleGroupInviteOpcode and also skipeed currently? Group *group = GetPlayer()->GetGroupInvite(); if (!group) return; This was probably what caused the issue. It may have been added in MaNGOS[9172]. Hope this helps

Hi klunk O.K cheers for that, so it must be how playerbot handles requests from the client, to group. I haven't changed anything in playerbot that might cause this issue, so we still have to look at what has changed elsewhere. Edit: If anyone is interested in a similar issue I had with 'Teleports', look at posts #365 & #370 in this thread cheers

Hi XEQT, Great work, but can I throw a 'spanner in the works'. The error message I get now, and the one that erazare first brought to our attention, pointed at a different opcode. If you look in Opcodes.h you will see that the opcode 110 is to CMSG_GROUP_INVITE (hex 0x06E, Dec: 110)and not SMSG_GROUP_INVITE (hex: 0x06F, Dec: 111). We need to check where the data is read coming from the client, and not the data coming from the server. Here is the starting point when it arrives at the server, Opcodes.cpp: /*0x06E*/ { "CMSG_GROUP_INVITE", STATUS_LOGGEDIN, &WorldSession::HandleGroupInviteOpcode }, Pointing at WorldSession::HandleGroupInviteOpcode in GroupHandler.cpp The Byte Buffer exception is flagged as it tries the read the data at the top of this function, void WorldSession::HandleGroupInviteOpcode( WorldPacket & recv_data ) { std::string membername; recv_data >> membername; recv_data.read_skip<uint32>(); // 0 for all known invite ways // attempt add selected player // cheating if(!normalizePlayerName(membername)) Interestingly,' recv_data.read_skip<uint32>();' was recently added to solve a packet reading issue in MaNGOS[9172] http://www.manground.org/mangosChangelog.html?logpage=30 Maybe this is where we should begin I still think that Blizzard might have changed the packet format in update 3.3.0. But it doesn't make any sense, because it was working when I used the playerbot code with MaNGOS[9162] & the old 'dbc' files, with the new client @erazare It sounds like you have a number of real players on your system. Could you get them to try forming a 'real player group', and see whether the issue still occurs? We might have to do what you suggested and test each commit until we track down where the offending change occurs. Sorry.

Hi Guys, At last I'm on the same block as you. I've built the code from klunk repo. MaNGOS[9183] SD2[1544] Compilation was fine. Interestly, I was not able to run the server, until I had recreated the 'dbc' files in accordance with MaNGOS[9170]. It then loaded, and I now get exactly what you get. Hmm.. this will take a while, but I got to crash now its quarter to four in the morning. Cheers

Hi klunk, Thats, fine nothing to do but clone your repo to my harddrive, that will do nicely. ahbot won't be causing the issue! I'll get back to you, probably tommorow now Cheers

Hi XEQT, Sorry, I think you mis-understand me. I was hoping someone had a Github repo with the problem code on. I know erazare has 'Tiamat' but it has multiple mods included in it. Cheers

Cheers XEQT, Do you guys get the problem if you run with an earlier version of MaNGOS, say [9162]? Cheers

Hi Guys Cheers for the info. Right we can now eliminate a platform specific issue. I'm using OpenSuSe 11.1. Can I get access to an example repo that is giving you problems. If I can reproduce the issue on my machine, I might be able to help. I will also require step by step account of your merge procedure. Cheers

Hi erazare, I've looking at this issue all day, and traced an issue in GroupHandler.cpp where the packet for CMSG_GROUP_INVITE was not read correctly. This was fixed in MaNGOS[9172]. Look at the changelog. Any chance you could give me the address of your repo that is giving you problems. I will try to reproduce the error on my server. I do not seem to have an issue with group invites. Its curious why I not having the same issues as you, I wonder whether it might be platform specific. If users could give us some feedback on what they are running (windows or linux), and whether they get this issue. klunk linux erazare windows blueboy linux XEQT ? Cheers

Hi klunk, Yes I'm afraid it is. You said you've been using Tirintycore up to now, yes. This is an aspect of Playerbot I want to address, Trintycore might have an answer. I have been looking at this but have not made much progress, because of other issues. If you can offer help that would be great. Have you got LOS settings active in 'mangosd.conf'. That does help, particularly when baddies seem to run through walls to kill you. The Line of Sight option stops this. Making the investigation of dungeons like the 'deadmines' possible Cheers

Hi Guys, I just tried my working server, and get no errors when I try to group the bots. I do not remember getting any errors when I compiled. The server is as follows; MaNGOS[9162] SD2[5143] playerbot from blueboy // latest version auctionhousebot // latest Naicisum version autobroadcast // old version vehicle // Tasssadar @erazare I will try to reproduce your error on my machine. Can you giving me the address of your repo, and I'll give it a go. I checked bizkut's patch and repo and they were both fine. Cheers

O.K, I'm going to run some tests that might take awhile. Please do not think I am ignoring you. I'm presently building a basic server MaNGOS[9183] playerbot from blueboy @ MaNGOS[9162] // latest version I will see if I get a problem when I try to group my bots. The error message suggests that the worldpacket data is malformed. One possiblity is that Blizzard has changed the format of the packet sent from the client, for this event, in the latest 3.3.0 update. I had a similar problem with teleporting in the last client update. If I had experience with a 'packet sniffer' it might be straight forward to compare the data sent. However, I haven't so it might be a case of trial and error, until the size of data sent in the packet matches that received. I would have thought that this issue would also effect MaNGOS on its own ? If you have a number of users on your servers, maybe you could see whether this issue occurs with a group of real players? Essentially data is sent and received thus, Client bananas >> packet // 2 size oranges >> packet // 3 size apples >> packet // 2 size send packet Server expects receive packet bananas << packet // 2 size oranges << packet // 3 size apples << packet // 2 size But if they have changed it, the server might get something unexpected receive packet bananas << packet // 3 size oranges << packet // 3 size apples << packet // 3 size 2010-01-15 13:21:42 ERROR:ERROR: Attempted to get in ByteBuffer (pos: 0 size: 0) value with size: 4 2010-01-15 13:21:42 ERROR:WorldSession::Update ByteBufferException occured while parsing a packet (opcode: 110) from client 192.168.xxx.xxx, accountid=135. Skipped packet. The error suggests that the server has recieved unexpected data from the client, and is ignoring the packet. Hope this helps, interested in everyones thoughts.

I explained how you integrate the two together in #510. I presume this is what causes your conflict. Playerbot into MaNGOS works fine. When I create individual patches, each is compared to a clean MaNGOS branch. The patch only expects to find MaNGOS code. I explained that vehicle and playerbot both update the same section of code in Player.h. I suggest you apply playerbot first and edit the vehicle.patch to account for the change in the patch 'pattern' three lines following the mod, protected: uint32 m_contestedPvPTimer; with // Playerbot mod: // A Player can either have a playerbotMgr (to manage its bots), or have playerbotAI (if it is a bot), or Cheers

Hi erazare, Are you using Tassadar's vehicle code with this. I got a conflict in Player.h when I tried to integrate 'playerbot' and 'vehicle' code together. (Details post #510) I just integrated bizkut code into MaNGOS[9183] without a problem. Have you got anything else in the code that might be conflicting. Cheers

Hi, I've checked the code on pastebin, with a patch I created from your repo. I tested both against MaNGOS [9183] and they both work perfectly. I haven't checked whether the code compiles, but I am fairly sure that you won't get any problems. Cheers

Its nice to see someone else using Linux for a change, I was begining to think I was the only one. Welcome to the forum and if you are able to contirbute that would be great, particularly if you have some experience with trintycore. There are a number of threads that would be interested in your opinions. The answer to your merge question is yes. Treat your hardrive as your workbench. For a merge, First clone your repo to your computer. Then set up a 'remote' branch that you wish to merge with. Your repo will automatically be labelled 'master'. git clone [email][email protected]:klunk/mangos.git[/email] git remote add mangos git://gthub.com/mangos/mangos.git git pull mangos master fix any conflicts git commit git push Careful when you commit. I do not use or like the commandline editor 'vi'. This is automatically opened after you commit a merge. It took me ages to work out that the editor had been opened. It does this so you can edit the message used for the merge. I thought that the commit had corrupted. Making normal changes is similar, except you need to add modified files before commiting, and you specify a message 'what you have changed', git add <modified files> git commit -a -m "What you did" git push Hope this helps

Hi klunk, No you should not have problems with gossip?. You had created an old patch only compatible with MaNGOS[8898]. The revised patch that you create should work fine, try it Edit: Oh, yeah I think you forked off the correct branch, now I have had chance to think about it. Your repo will be thus separate from Playerbot & Blueboy. Cheers

Hi, Scriptdev2 is separate to the MaNGOS and playerbot code. You can download it before or after!. Remember to patch the code for scriptdev before compiling otherwise the scriptdev code with not compile with MaNGOS. I wrote a small script to make this easier, #!/bin/bash unset BRANCH unset PATCHES BRANCH=$1 PATCHES="/home/mangos/compile/mangos1/src/bindings/ScriptDev2/patches/" [ ! -z "${BRANCH}" ] || { echo "available patches:>"; ls ${PATCHES}; exit 1 ; } patch -p1 < ${PATCHES}'MaNGOS-'${BRANCH}'-ScriptDev2.patch' N.B Obviously, the directory tree for 'PATCHES' above will be different on your computer. You can run the patch manually from the directory listed. Then finally before compiling autoreconf --install --force Hope this helps