Jump to content

Playerbot (archive)


Recommended Posts

well stormwind is a gameobject actually

Yes, but right in front of me there was a peacebloom and command "survey" didn't return its link.

Today I test bots' gathering at another place, this time I get the game objects, but when I order bots to "get", sometimes they just get in position and stand still, and if this occurs, command "get" won't be effective untill next time you login.

quest item like "a bundle of woods" can't be picked up. The "survey" and "get" code may be modified when merging two branches, but I don't know if this matters.

Link to comment
Share on other sites

  • Replies 1.8k
  • Created
  • Last Reply

Top Posters In This Topic

blueboy, Thanks for the guide. I just merged two branches by violence last night, I mean I've been manually modifying each line of changes according to https://github.com/blueboy/portal/compare/training...loot-fix-bt.

And after fixing several compiling errors(exactly the same with conflicts you mentioned), the solution was successfully built.

But there's still something wrong with the "looting" part, bots can't skin hide from corpse, and another big problem is that when I'm using "survey" command, bots return only the namelist of nearby areas(Stormwind City, Northshine Abbey...), not the list of game objects. This leads to the inability to order bots to gathering mine, collecting herbs or whatever behavior requires interaction with game objects.

Hi Syenet,

Thanks for the feedback, I'm sure Bthallid will find it useful. Please bear in mind that these sub-branches hold alpha code and although it might compile, it may just be an idea in progress (i.e not guaranteed to work).

Cheers

Link to comment
Share on other sites

Please bear in mind that these sub-branches hold alpha code and although it might compile, it may just be an idea in progress (i.e not guaranteed to work).

Yes, I know that. It's weird to me just because the "collect" part once worked perfectly.

I see there's a "ahbot" branch in your "portal", is it the "new_ahbot" form cyberium http://github.com/cyberium/mangos/tree/new_ahbot?

If I want to merge "ahbot" to my current "training" which is already merged with "loot_bt", how can I do that?

Link to comment
Share on other sites

Please bear in mind that these sub-branches hold alpha code and although it might compile, it may just be an idea in progress (i.e not guaranteed to work).

Yes, I know that. It's weird to me just because the "collect" part once worked perfectly.

I see there's a "ahbot" branch in your "portal", is it the "new_ahbot" form cyberium http://github.com/cyberium/mangos/tree/new_ahbot?

If I want to merge "ahbot" to my current "training" which is already merged with "loot_bt", how can I do that?

Yes, it worked for me too before, but like I said Bthallid is trying some new ideas out and the code is not guaranteed. I can comment on the training code as that's mine and I shall shortly merge this code with portal for beta testing

The auctionhousebot code on blueboy is based on Naicisum's code. This code is stable, requires low maintenance and works fine for moderate amounts of auction items (~1500).

To use the auctionhouse code, why not create a standalone patch that can be applied to the playerbot/training/loot-fix-bt code. This is what I use and it should merge and compile without issue.

#!/bin/bash -x
git clone git://github.com/mangos/mangos.git ahbot
cd ahbot
git fetch git://github.com/blueboy/ahbot.git ahbot:ahbot
git checkout ahbot
HASH=`git log --pretty=oneline | grep -m 1 '\\[1[0-9]\\{4\\}]' | cut -d " " -f 1`
git diff $HASH > ahbot.patch

Hope this helps

Link to comment
Share on other sites

Sorry I'm a little bit confused.

1. The first thing is to merge two branches with "portal", when merging is done, the source file should be already changed, right?

2. After handling the conflicts the solution should be compiled without issues.

3. Now everything is ready, then you commit changes. Here I wonder, since the code is already changed, it should be compiled now, why you commit changes here? Are you commiting the changes of resolving conflicts? for the purpose of making patches?

4. After commiting, you create a patch. Ok, this is what confuses me the most: right now the code is ready to go, what is this patch used for?

5. You apply this patch. If patch is made for changing code, why are you applying it to the code that is already changed?

Link to comment
Share on other sites

Hi Syenet,

The guide I provided shows you how to merge the code locally on your harddrive. True, this merged code is ready to compile, without the need to create a patch. But if you later decide to build a new server, the stanalone patch may save you some time (just apply it to a fresh download of MaNGOS). If after resolving merge conflicts you do not commit the code changes, then the merge will not take effect (git log to check merge success).

I have tested the collect/get/survey code on my box, using code merged from my instructions and it seems to work perfectly.

I gather you are compiling on Windows. If not, you might have a couple of compile issues on linux. I have notified BThallid and I am sure he will adjust the code on loot-fix-bt shortly.

1. Declaration of non-standard function itoa() for linux

2. Addition of a missing header file in PlayerbotAI.cpp (#include "../CellImpl.h")

EDIT: The code on loot-fix-bt has now been updated

/p collect

initially only allows the bot to collect profession and quest items after combat. To get the rest you must specify

/p collect objects

/p collect loot

I agree that it would be a good idea to have an 'all' option to complement the 'none' option with collect. Maybe have all collect options active as default.

/p survey

shows all gameobjects near to the bot as expected and all were accessible.

Either select the target, in the case of looting a corpse, or a HLINK [Copper Ore] in the case of a gameobject.

/p get

Bot moves to specified location and obtains the goodies.

Cheers

Link to comment
Share on other sites

When I was trying to make a patch, I got these errors:

grep:  invalid option -- m
Usage: grep [OPTION]... PATTERN [FILE]...
Try `grep --help' for more information.

I find this:

Maybe the bash shell that your running the script in does not support this '-m' option for grep.
you can add a patch by using this command : patch -p1 < nameofpatch.patch

but you can do it with svn as well

Is it the proper solution to this problem? or there's a better one?

Link to comment
Share on other sites

When I was trying to make a patch, I got these errors:

grep:  invalid option -- m
Usage: grep [OPTION]... PATTERN [FILE]...
Try `grep --help' for more information.

I find this:

Maybe the bash shell that your running the script in does not support this '-m' option for grep.
you can add a patch by using this command : patch -p1 < nameofpatch.patch

but you can do it with svn as well

Is it the proper solution to this problem? or there's a better one?

Hi,

Your grep utility is out of date.

-m, --max-count=NUM stop after NUM matches

You can download the latest version and it will work. This is the version I currently use.

grep -V

GNU grep 2.5.4

Copyright © 2009 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.

If your using Git Bash Shell then you need to find the binary grep.exe and replace it with the latest, compatible with Windows. If you are using *nix, then download the latest from GNU, or get your OS to update it.

vladex is correct as far as application, once the patch is created, but your issue is with the bash script used in patch creation.

I prefer git apply to apply the patch

git apply --check --whitespace=fix playerbot.patch

The --check allows you to do a dumby run without actually applying the patch. If you get no errors, re-run without --check

Hope this helps

Link to comment
Share on other sites

Concerning the collect command syntax: it could probably use some changes. Unfortunately, I have always been poor at the ease of use aspect. The collect command just gives you a display of what the bots are set to. The subcommands do the actual work:

combat - bot will loot after combat for the options that are set

loot - bot will grab all loot available from corpse

quest - bot will grab all quest items on corpse

profession - bot will grab any profession related item that the bot has from corpse

skin - if you have skinning, and corpse has been looted, bot will skin corpse. Most of the time you may want this option and the loot option enabled, but if you are grabbing the stuff as you are going around, the bot will skin afterwards.

objects - bot will collect things that are specified by the survey and get <shift-click> commands

none - removes any collect options that have been set

The default collect options that are enabled are combat, quest, and profession. The syntax is collect <subcommand(s)> (can be stacked with multiple on one line - e.g. collect loot skin). Each subcommand toggles that option; if you use collect loot once, it will set it, when you use collect loot again, it unsets it. I thought about using a negate/no option, but IMHO toggling works fine and is simpler. Opinions are welcome.

get while a corpse is selected, will only do the collect options that are enabled. It was put in there for those that may not want the bot to loot after combat.

Link to comment
Share on other sites

I'm using Windows and "Git-1.7.3.1-preview20101002", I thought it's from the official site so it should be up-to-date.

Could you tell me how to check my grep version and where can I get the latest "grep.exe"?

To get the version

grep -V

My windows box is offline at present, because of house decoration, so I can't give you details on how I modified the Git Bash Shell I use. However there are lots of different implementation of Git for Windows, available for download. I'm sure there must be an updated version that already includes a version of grep.exe 2.5.4 or greater.

EDIT: I will do my best to find out how I updated the grep.exe in my shell. Leave it with me.

Hope this helps

Link to comment
Share on other sites

Hi Guys,

I have just updated both blueboy and portal repos. It has been agreed that the current code on both loot-fix-bt & training branches be moved to portal for beta testing. Please test this code and provide us with constructive feedback.

Merge process

1: The existing code on portal has proved to be stable, so it has been merged into blueboy.

2: blueboy has been updated with the latest core code, MaNGOS[10968]

3. The current code on branch loot-fix-bt has been merged with portal. The loot-fix-bt branch will remain, so development can continue.

4. The current code on branch training has been merged with portal. The training branch will remain, so development can continue.

5. portal has been updated with the latest core code, MaNGOS[10968]

Hope this helps

Link to comment
Share on other sites

The server crashes everytime after it's set up, to be specific, everytime after a line of SQL query shows up in "mangosd.exe".

That SQL query seems about reading character infos from db where guid = 0, then I try disabling ahbot, then the server is fine.

So your "ahbot" is the version that requires an existing character to be the "AuctionHouseBot" right? And I need to specify the account and guid of this character in "mangosd.conf".

I remember there's version of ahbot which doesn't need a character, maybe new_ahbot. Which version is the latest and stable?

I create a patch from branch "new_ahbot" of "..cyberium/mangos.git", when I'm trying to apply it to branch "master" of "..blueboy/portal.git", I get these errors:

error: patch failed: configure.ac:363
error: patch failed: src/game/Makefile.am:17
error: patch failed: src/game/World.cpp:1329
error: patch failed: win/VC100/game.vcxproj.filters:448

I think these are small problems but I don't know how to fix.

Link to comment
Share on other sites

Hi Sysnet,

Sorry that your still having problems.

Yes, the version of autionhousebot I use does require that you create an auctionhouse guy, as you would any other character. This character will have it's own unque GUID that must be entered into mangos.conf. The character's account GUID must also be entered. They recommend that you logon at least once with the auctionhousbot character. These are my settings;

###################################################################################################################

AuctionHouseBot.EnableSeller = 1

AuctionHouseBot.EnableBuyer = 1

AuctionHouseBot.Account = 12

AuctionHouseBot.GUID = 42

AuctionHouseBot.VendorItems = 1

AuctionHouseBot.LootItems = 1

AuctionHouseBot.OtherItems = 1

AuctionHouseBot.No_Bind = 1

AuctionHouseBot.Bind_When_Picked_Up = 0

AuctionHouseBot.Bind_When_Equipped = 1

AuctionHouseBot.Bind_When_Use = 1

AuctionHouseBot.Bind_Quest_Item = 0

AuctionHouseBot.ItemsPerCycle = 20

AuctionHouseBot.UseBuyPriceForSeller = 0

AuctionHouseBot.UseBuyPriceForBuyer = 0

###################################################################################################################

You will also have to change some default values in your character database. In table 'auctionhousebot' set the minitems field for all auctionhouses to zero and the maxitems to something like 500 (Giving a total in the 3 auctionhouses ~1500). You can obviously set it higher, but this only causes greater lag.

If you do use this version of auctionhousebot it's a good idea to set AuctionHouseBot.ItemsPerCycle to a low value. This reduces the noticable lag that occurs (adding/deleting items from auctionhouse) that prompted developement of Xeross/Cyberium version of auctionhousebot.

Obviously the version I use is not the latest, Cyberium code is the latest. Difficult to say which is the more stable. The new_ahbot has been under development and has experienced many issues during this process. It is presently under review as you may know and hopefully will be in the core soon. I need to focus my attention on playerbot development and I didn't want the hassle of having to update the code every time it conflicted with the core. The old code rarely needs changing, so this is why I use it.

The merge conflicts you have are easy to fix (conflict between playerbot and auctionhousebot). If you flip back through the posts on this forum, you will find countless explanations by me on fixing these.

Example: Open World.cpp and go to line 1329. Also open the ahbot.patch (search for World.cpp) and go to the conflicting modification ~1329). You will need a keen eye to examine the code in each (git uses both 3 line patterns to locate the position for the patch modification in the code) You are looking for any difference, even an invisible whitespace will cause conflict. The easiest way is to copy and paste both 3 line patterns from the World.cpp file and replace the existing ones in the patch (This becomes easier with practice).

Example Merge in World.cpp

Initial patch from ahbot.patch

@@ -1318,6 +1354,9 @@ void World::SetInitialWorldSettings()

// Delete all characters which have been deleted X days before

Player::DeleteOldCharacters();

+ sLog.outString("Initialize AuctionHouseBot...");

+ sAuctionBot.Initialize();

+

sLog.outString( "WORLD: World initialized" );

uint32 uStartInterval = getMSTimeDiff(uStartTime, getMSTime());

Initial MaNGOS code ~ 1317 to 1326 World.cpp

1316 uint32 nextGameEvent = sGameEventMgr.Initialize();

1317 m_timers[WUPDATE_EVENTS].SetInterval(nextGameEvent); //depend on next event

1318

1319 // Delete all characters which have been deleted X days before

1320 Player::DeleteOldCharacters();

1321

1322 sLog.outString( "WORLD: World initialized" );

1323

1324 uint32 uStartInterval = getMSTimeDiff(uStartTime, getMSTime());

1325 sLog.outString( "SERVER STARTUP TIME: %i minutes %i seconds", uStartInterval / 60000, (uStartInterval % 60000) / 1000 );

1326}

You see that the patch (3 line pattern) matches the code in the game file World.cpp.

Now after you apply playerbot, the MaNGOS code in World.cpp will change (upper 3 line pattern).

Revised MaNGOS code ~ 1332 to 1339 World.cpp

1331 //Check playerbot config file version

1332 if (botConfig.GetIntDefault("ConfVersion", 0) != PLAYERBOT_CONF_VERSION)

1333 sLog.outError("Playerbot: Configuration file version doesn't match expected version. Some config variables may be wrong or missing.");

1334

1335 sLog.outString( "WORLD: World initialized" );

1336

1337 uint32 uStartInterval = getMSTimeDiff(uStartTime, getMSTime());

1338 sLog.outString( "SERVER STARTUP TIME: %i minutes %i seconds", uStartInterval / 60000, (uStartInterval % 60000) / 1000 );

1339}

You will now have to copy and paste the 3 line pattern in the above revised World.cpp, to replace that in the ahbot.patch, thus

Final (working) patch from ahbot.patch

@@ -1318,6 +1354,9 @@ void World::SetInitialWorldSettings()

if (botConfig.GetIntDefault("ConfVersion", 0) != PLAYERBOT_CONF_VERSION)

sLog.outError("Playerbot: Configuration file version doesn't match expected version. Some config variables may be wrong or missing.");

+ sLog.outString("Initialize AuctionHouseBot...");

+ sAuctionBot.Initialize();

+

sLog.outString( "WORLD: World initialized" );

uint32 uStartInterval = getMSTimeDiff(uStartTime, getMSTime());

Note: When you paste the 3 line pattern, remember to add a space to the start of each line, otherwise the patch will not work.

Have a go and let me know how you get on

Hope this helps

Link to comment
Share on other sites

Sorry, what is 3 line pattern? which 3 line?

Do you mean this:

line 1:
line 2:
line 3:
line 4: Modification........
line 5:
line 6:
line 7:

And I need to ensure lines 1~3 and 5~7 in patch are exactly the same with the ones in code?

Yes, the modification lines begin with either a '+' or a '-' symbol. There are two sets of code patterns above and below the modification, that must match the code in the file being modified (The upper 3 line pattern would be lines 1 to 3 and the lower pattern would be lines 5 to7). You would look in the file being modified for a block of code

line1:
line2:
line3:
line5:
line6:
line7:

If there is a difference you will need to either replace block (lines1 to lines3) or block (lines 5 to lines 7) or maybe both in the patch.

Cheers

Link to comment
Share on other sites

Everything's fine now, thanks for the help.

I just figured out how the "loot" part works, bots will skin only if "collect skin" is set true, otherwise they won't.

And if bots meet a failed attempt, they'll keep the gathering pose untill next "get".

Link to comment
Share on other sites

Concerning the collect command syntax: it could probably use some changes. Unfortunately, I have always been poor at the ease of use aspect. The collect command just gives you a display of what the bots are set to. The subcommands do the actual work:

combat - bot will loot after combat for the options that are set

...

profession - bot will grab any profession related item that the bot has from corpse

...

This is what I was looking for...great, now how easy would it be to have sensible responses to rolls for loot - e.g. need vs greed vs disenchant...

Would be great to have some simple rules per class that specified when something could be classed as need (e.g. Mail/Plate can only be needed by someone that can wear it!)

Happy to help, just trying to figure out where to start - not sure where the code that handles rolls lies...

Link to comment
Share on other sites

Hi quixote,

Glad you like my 'roll for loot' code :D. Seriously, we would be very interested in any contribution that will improve the playerbot code. I wrote the 'loot roll code' sometime back, as there was nothing in place to handle group looting. At the time, a random roll seemed to be the fairest way to distribute loot.

You will find the loot handling code in PlayerbotMgr.cpp, in function HandleMasterIncomingPacket(). This handles the incoming opcode CMSG_LOOT_ROLL. Let us know if you need anymore information

Cheers

Link to comment
Share on other sites

Hi quixote,

Glad you like my 'roll for loot' code :D. Seriously, we would be very interested in any contribution that will improve the playerbot code. I wrote the 'loot roll code' sometime back, as there was nothing in place to handle group looting. At the time, a random roll seemed to be the fairest way to distribute loot.

You will find the loot handling code in PlayerbotMgr.cpp, in function HandleMasterIncomingPacket(). This handles the incoming opcode CMSG_LOOT_ROLL. Let us know if you need anymore information

Cheers

Random is good, at least we have some variety :)

Hmm, looking at this, the problem is that on receipt of CMSG_LOOT_ROLL we've lost direct visibility of what the roll is for (and it seems difficult to get that info from what's in that message) - it may not be a complete disaster, but not clear how to find it without keeping the PlayerBot code nicely encapsulated...unless we do something with the outbound message to the client - SMSG_LOOT_START_ROLL has all the details we need - including the itemid from which can be derived the ItemPrototype...

If someone can tell me I'm wrong re CMSG_LOOT_ROLL params (as I am new to the vast mangos codebase) then great, otherwise, I'll figure something else out...

Right now I'm focussing on being able to understand the info in ItemPrototype and how it can be used (ItemHandler/ObjectMgr/Player all seem to have examples), then I can figure out...do we want to wait for the "Master" to respond and then have the bots determine what they should do...this would enable us to say, for example, if the Master "Needs" then the bots pass...If we want to do that, it involves storing the item info between the outbound packet and the associated response (if one comes back...) and of course managing and cleaning up that data...

Link to comment
Share on other sites

Hi quixote,

I agree, with the current code the bots make a blind decison over the item being rolled for. A good example of this occurs in instances where boss items are being rolled for. No account is made as to whether the winning bot can use the item or not. As these items are soulbound, invariably the item is wasted. It might be a good idea to make group looting configurable. Much as BThallid's looting code determines whether the bot has the profession skills needed to loot an item. It would be useful if the bot decision was influenced by their ability to use the item.

The ItemProtoType structure is an invaluable information resource to describe all items in the game. As an example, you could do something like this;

const ItemPrototype* const pItemProto = pItem->GetProto();

if (pItemProto && m_bot->CanUseItem(pItemProto) == EQUIP_ERR_OK)

choice = ROLL_NEED

else

choice = ROLL_GREED

Hope this helps

Link to comment
Share on other sites

I have a strange thing occured regarding my deathknight bot:

It seems it doesn't detect when I used a mount. Is their a parameter I miss, somewhere ?

Interesting! I tried this myself with two death knights, one player and one bot. The player had two mounts, "Riding Turtle" and a "Swift Brewfest Ram". The bot consistently automounted with the Ram (when the player mounts). However, it did not mount at all when the player mounts the Turtle. I didn't think mounting was effected by either class or mount type.

Leave it with me and I'll take a closer look.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. Privacy Policy Terms of Use