Playerbot (archive)

[erazare]

one thing i like about core modifications as opposed to mangos proper, is that when you write these it doesnt matter how you do it so long as it works and is easy enough to build off of (like comments and shit) not a bunch of predefined BS... make it work and we're all happy =)

[blueboy]

Im almost there ..

i solved som of it via this

   // ok, we do it
   WorldPacket data(SMSG_GROUP_INVITE, 10);
   data << uint8(1);                                       // ok
if (!GetPlayer()->GetPlayerbotMgr())//   GetPlayerbotAI())
{

 data << GetPlayer()->GetName();
 player->GetSession()->SendPacket(&data);

}
else
{
 data << membername;
 HandleGroupAcceptOpcode(data);

}
SendPartyResult(PARTY_OP_INVITE, membername, PARTY_RESULT_OK);

the only problem i have now is that it uses the same name back to me in GetPlayer() and _player

So there are som stuff to work out .. but i can nearly create a group now ..

// XEQT

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.

[klunk]

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.

I can tell you that I have a couple of people, close friends and my children, using my server and we have managed to create normal groups without a problem. I did have an issue on one client (which has worked before with other accounts) not getting chat messages but that is something different and not ralated to playerbot.

[blueboy]

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

[blueboy]

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

[erazare]

sure blueboy not a problem will get on that asap

edit someone beat me to it...

ok yeah just waking up kids... a little bit lost on what has transpired..

[blueboy]

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.

[klunk]

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

I can see this working with the bot, will test normal groups later.

[klunk]

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.

I didnt get a whisper.

[klunk]

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

OK, so I managed to group with both bots and real people, interestingly if I type in /p with real people and bots I get a whisper from the bot every time. If its my bot it doesnt understand or someone elses it says speak to my master. Maybe have to have different chanels for real chat.

[erazare]

blueboy do you have this in your repo or is it still dev-ving?

nevermind just checked your repo... no updates *lol*

lets see if i can apply this

[erazare]

i havent tried updating to 9202 yet (nor shall i just yet) but they may have even further fuxored movement... check http://github.com/mangos/mangos/commit/824451aea4b8e87ddac4aa6501b30afb1d8ab098

just letting you know before it comes up blue

[blueboy]

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

[blueboy]

Hi klunk

OK, so I managed to group with both bots and real people, interestingly if I type in /p with real people and bots I get a whisper from the bot every time. If its my bot it doesnt understand or someone elses it says speak to my master. Maybe have to have different chanels for real chat.

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

[klunk]

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

Yes, I am not sure that there is anything you can do with it, other than put up with it. If you want to party with real people and bots you will get noise because bots listen to party chat as well. The only way around it is a special bot channel just for bot commands but then how do you stop all bots on the system getting the messages.

As for the floor issue I menioned, it seems to happen in the start areas, Human and Drainei but is fine in the city, stormwind.

[XEQT]

GroupHandler.cpp

   // ok, we do it
   WorldPacket data(SMSG_GROUP_INVITE, 10);
data << uint8(1);                                       // ok
if (!GetPlayer()->GetPlayerbotAI())//   GetPlayerbotAI())
{

 data << GetPlayer()->GetName();
 player->GetSession()->SendPacket(&data);

}
else
{

 sLog.outString("Its a bot");
 data << membername;
 HandleGroupAcceptOpcode(data);

}
SendPartyResult(PARTY_OP_INVITE, membername, PARTY_RESULT_OK);
}
void WorldSession::HandleGroupAcceptOpcode( WorldPacket & recv_data )
{
   std::string membername;
recv_data >> membername;
Group *group = GetPlayer()->GetGroupInvite();
if (!group) return;
if(group->GetLeaderGUID() == GetPlayer()->GetGUID() && _player->GetGUID() != GetPlayer()->GetGUID() && _player->GetPlayerbotMgr())
   {
 sLog.outError("HandleGroupAcceptOpcode: player %s(%d) tried to accept an invite to his own group", GetPlayer()->GetName(), GetPlayer()->GetGUIDLow());
       return;
   }

if (!GetPlayer()->GetPlayerbotAI())// GetPlayerbotAI())

and

sLog.outString("Its a bot");

data << membername;

HandleGroupAcceptOpcode(data);

and

std::string membername;

recv_data >> membername;

Whit this it is solved

// XEQT

[blueboy]

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

[erazare]

well i am running our private server using your new code changes and it works beautiful

I am ready to see people dev deeper in this.. like... they never loot corpses (my bots havent... they go stand next to them but they dont take anything) would also like to see them pick up quest items when they need them and oh... what would be super is if they would farm mines and other trade items so that when i login I can make metals and shit... even better if they could be doing that too... maybe if there is a long pause or no near threat or something

[blueboy]

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

[blueboy]

well i am running our private server using your new code changes and it works beautiful

I am ready to see people dev deeper in this.. like... they never loot corpses (my bots havent... they go stand next to them but they dont take anything) would also like to see them pick up quest items when they need them and oh... what would be super is if they would farm mines and other trade items so that when i login I can make metals and shit... even better if they could be doing that too... maybe if there is a long pause or no near threat or something

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

[klunk]

Lots of questions, and I promise at some point I will start providing some answers.

When I was playing with the bot last night it seems that the bot player does not get XP for discovering areas and does not get the completed on the explore quests. the second of this can be found with a quest in Goldshire to explore a kobold mine to the south. I had to log on the bot character and run into the mine to get the quest completion. Is this a known issue? Is there a jira/trac/issue site for playerbot?

I also noticed that sometimes, when I speak to a trainer that also has a quest, I get a GOSSIP_ enum instead of a text label, this seems to be a mangos issue rather than playerbot but does anyone else see this?

[erazare]

Lots of questions, and I promise at some point I will start providing some answers.

When I was playing with the bot last night it seems that the bot player does not get XP for discovering areas and does not get the completed on the explore quests. the second of this can be found with a quest in Goldshire to explore a kobold mine to the south. I had to log on the bot character and run into the mine to get the quest completion. Is this a known issue? Is there a jira/trac/issue site for playerbot?

I also noticed that sometimes, when I speak to a trainer that also has a quest, I get a GOSSIP_ enum instead of a text label, this seems to be a mangos issue rather than playerbot but does anyone else see this?

the gossip enum can be easily solved... I can pack some gossip up for you if you like but you need to populate gossip_menu table in your db

[klunk]

the gossip enum can be easily solved... I can pack some gossip up for you if you like but you need to populate gossip_menu table in your db

Ah, should that be in a SQL script already? Something in mangos core? Maybe it should be submitted to the core developers.

[erazare]

no no... UDB may or may not include it, YTDB does.. but during a base install of mangos if you ONLY use thier DB (which is highly un-suggested) those tables are empty

mangos staff itself will tell you that they only make the basic SQL structure for mangos they do not populate the DB you need to get a repo like UDB or YTDB or PSMDB to flesh it out

[blueboy]

Lots of questions, and I promise at some point I will start providing some answers.

When I was playing with the bot last night it seems that the bot player does not get XP for discovering areas and does not get the completed on the explore quests. the second of this can be found with a quest in Goldshire to explore a kobold mine to the south. I had to log on the bot character and run into the mine to get the quest completion. Is this a known issue? Is there a jira/trac/issue site for playerbot?

I also noticed that sometimes, when I speak to a trainer that also has a quest, I get a GOSSIP_ enum instead of a text label, this seems to be a mangos issue rather than playerbot but does anyone else see this?

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