Playerbot

[blueboy]

Hi

Thanks kennumen for the todo list. I'm already looking at a number of the issues you raised and hopefully we can find solutions to all. I've got a small patch to try and improve on the Need or Greed choice. I've only just started testing it so it might not work. If anyone is interested here's the patch.

diff --git a/src/game/playerbot/PlayerbotMgr.cpp b/src/game/playerbot/PlayerbotMgr.cpp
index ac39b96..ed123e4 100644
--- a/src/game/playerbot/PlayerbotMgr.cpp
+++ b/src/game/playerbot/PlayerbotMgr.cpp
@@ -573,7 +573,21 @@ void PlayerbotMgr::HandleMasterIncomingPacket(const WorldPacket& packet)
                if (!group)
                    return;

-                (bot->GetPlayerbotAI()->CanStore()) ? choice = urand(0, 3) : choice = 0;  // pass = 0, need = 1, greed = 2, disenchant = 3
+                Item* rItem = bot->GetItemByGuid(Guid);
+                if (!rItem)
+                    return;
+
+                if (bot->GetPlayerbotAI()->CanStore())
+                {
+                    if (bot->CanUseItem(rItem) == EQUIP_ERR_OK)
+                        choice = 1; // Need
+                    else if (bot->HasSkill(SKILL_ENCHANTING))
+                        choice = 3; // Disenchant
+                    else
+                        choice = 2; // Greed
+                }
+                else
+                    choice = 0; // Pass

                group->CountRollVote(bot, Guid, NumberOfPlayers, RollVote(choice));

@UnkleNuke. As always, thanks for your kind words of encouragement I remembered that 'mail' was on your wish list, so I hope you like it. I've just pushed the mail patch to the new-ai branch.

One more bug to the list.

[bug] If two or more bots have the same profession (e.g mining), only one bot will succeed in collecting the gameobject. The others will continue mining a non-existent ore sample.

Any suggestions to this, or the ones that kennumen list will be gratefully received.

Back to testing..

[kennumen]

It appears my post was understood quite a bit more melodramatically than I intended (thus is the nature of the web). At least the topic got a few replies out of it I do apologize for the long post but you should be expecting that from me by now. At least it's a week's worth

kennumen, in spite of the apparent silence, I can assure you the crowd cheers with every release and update. Since most all of us lack the depth of technical skills that both you and blueboy possess, much of the discussion is over our heads, which is why there's the lack of posts. It's hard to take part in such conversation when you feel as if there's nothing worthy to contribute, sort of like being in a room full of nuclear physicists when you've barely managed to grasp algebra. :lol:

I think you may somewhat overestimate my skills. If you take a look at the commit comments you'll see what I mean (and perhaps have a good laugh in the meantime). But since this compliment was directed at the entire playerbot team (including blueboy, BThallid and quite a few others), I'll gladly take it.

As for conversation, I personally bear no ill will towards silent leechers. It is however a lot more fun to have a lively topic with bug reports, feature requests and general [on-topic] discussion than it is to have 5 posts in a row You don't need to know what part PlayerbotClassAI plays in the whole (and frankly, I don't yet know myself - although I could make an educated guess) to share your thoughts and motivate the developers. I often try to simplify [em]parts[/em] of my posts to this end, but I shall have to redouble my efforts.

As for your analogy, you do need some natural aptitude but even nuclear physicists started out learning algebra

... there's a great many people that [snip] and would be overjoyed to have autonomous bots ...

Dungeon groups, raids, arenas, and even battlegrounds seem within reach, thanks to the efforts put forth here.

I took a look at yad's easy-mangos (bg/arena bots) before getting started. The early plan was to rip his code, push it into autobots and rub it in his face for not putting it in a clean, patchable fork. The more I found code I could use, the more I came back to playerbot's master fork and saw the same code. So respect to yad02 for getting it done, but I've cursed his name far too much these past few weeks for having to do it over. The result, I believe, is superior in quite a few ways, but it's still a shame to have to redo it. Also, the code I've seen while working on autobot is so unfamiliar I've been buried a few times this week.

Your last comment is a bit unrelated to autobots. Dungeon groups and raids are possible (for 25/40 man raids you'll need BThallid's sharedbots to overcome playerbots 9bot maximum). LFG/LFD would be nice but I think we'll need to wait until Cyberium's work gets completed and accepted into the core. BG and arena... Well actually I don't know the status. I suspect it doesn't work, but it's very difficult to test, which brings me to:

The past week I've been thinking more and more how Autobots will be great for development, as a testing tool. Bug report about a level 50 priest spell? Ah, hold on, let me level and gear a priest, etc... Oh wait, let's just autobot it You'll be able to summon bots to test their viability in battlegrounds, instances, etc. Not to mention it's a much closer first step to what I had in mind at first. It's been a lot tougher than I expected. It's nothing concrete, just a change in my mindset, but I thought I'd share it anyway. Correct me if I'm wrong, but it seems like a well hidden feature of autobots will be that it's a very powerful development and debugging tool.

You and blueboy, and the Playerbot pioneers who have come and gone, have enriched hundreds of worlds that exist on small servers across the globe. My own adventures are no longer as isolated or daunting, knowing I can summon forth a party to help me as I explore my own little realm. All of you who have contributed to Playerbot have my heartfelt thanks for adding more knowledge and more fun to my spare hours.

MaNGOS may be just a learning project, but it is one that has given a great deal of happiness and expanded horizons for countless numbers as they've passed through these grand halls where knowledge, skill, dedication, and even love pours forth from so many talented hearts and minds. Stay the course and continue on for as long as you can. Every line of code is a treasure to the rest of us.

Your adulations continue to humble me.

Thanks kennumen for the todo list. I'm already looking at a number of the issues you raised and hopefully we can find solutions to all. I've got a small patch to try and improve on the Need or Greed choice. I've only just started testing it so it might not work.

-                (bot->GetPlayerbotAI()->CanStore()) ? choice = urand(0, 3) : choice = 0;  // pass = 0, need = 1, greed = 2, disenchant = 3

You know, I actually suspected this might be completely random but I'd never looked it up. I lol'ed when I read it in your post This may well be why sometimes rolls go into time-out mode (invalid options selected by one or more bots, an unlisted bug). Thanks very much for working on that, by the way. I should do more work on my/our list but between motivation, time constraints and autobots I'm all out of code A feeble excuse since we're all in that same boat, but despite it - or because of it - really, thanks for chipping away at it.

I wasn't entirely sure how the disenchant roll works, so I looked it up. In short, the disenchant roll is available for the entire party (and perhaps raid?) as long as one party member has a high enough enchanting skill. Here, you're only using it for the enchanter (which I actually agree with, no change suggested), but you fail to check for a sufficient Enchanting skill to disenchant. If I were nitpicking, a Need roll should supercede full bags (and drop the least worthwhile item in the bags), but the code infrastructure isn't really there yet to do that. If anyone is interested in writing this infrastructure, you could start with dropping the gray item with the lowest sale value. But I digress.

For the slightly longer explanation, look here and scroll down to "Loot options: Need, Greed, Disenchant and Pass". Highly recommended read for understanding looting rules.

As for the rest, I've noticed you're a better tester than I. Let me know when it gets pushed to master and I'll recompile my 'Release' server, and we can tweak it further if necessary

I've left several off because I don't want to lengthen an already long list, but blueboy's post reminded me:

[bug] Mining / herbalism is flawed. Mining sometimes does not collect, Herbalism appears to never collect (both work fine when told manually using survey/get).

As for other bugs/tweaks/features, let's see if and how long they annoy me All reported bugs/tweaks/features have been edited into the list a few posts up so it's a more or less comprehensive list at the moment. Hopefully someone can think of a better place to put this. Someplace everyone can edit and easy to find. Perhaps the wiki? Or a simple html file next to the bot's readme in github/distro?

As for my weekly update...

* [new-ai] Did an update to druid, should handle shapeshifting a lot better (no longer shifting out of a form to go to another, and being better at selecting a proper form to shift into even at the odd levels where bear (<10~13) or cat (<20) isn't available and subsequently using the proper form's spell sequence). Ironically, untested. In one group my druid is <10 spellcaster, and in my other test group I'm the feral druid.

* [new-ai] Did an update to priest, noticed my priest was OOM (out of mana) a lot. Looked closely, the priest occasionally spammed renew on me even if it was still up. Fixed that, and (hopefully) improved it's general healing. Also noticed it only healed group members (other than itself and the master) when they were under 25% health. Which would likely have included the tank? Anyway, better, hopefully. Also untested.

* [autobot] Made several steps forward on autobot. With the latest commit you can completely add autobots (to the database). Remove only by (re)starting mangosd, at this time. Doing so after your 'ooh's and 'aah's should ensure a clean database. '.autobot add <purpose> <role>' to test. Which choices are valid purposes and roles? '.autobot add' will help. Assuming you can read red error text.

The bots do work, I had a few logged in before I improved the code and broke that (unfortunately they were created using my accountId which broke your login once you logged out - so yes, it really is a code improvement).

Short term: Next few steps on the autobot dev path are probably having the bots log in, then adjusting their level (just after creation, not on/after login), and applying a talent spec. Also shouldn't forget that players under ~50 (or so) shouldn't be grouped with Death Knights (min level 55).

Mid/long term: After that it's back to new-ai or a new branch to figure out automatic equipping of 'better' equipment. <edit> Recently implemented gear score in mangos core, should be useful and provide some hints. </edit> Once that's ready, merge that code into autobot and figure out how in the hell to select gear. Given that the (item)database is a variable, we can't work with a (mini) loot table (similar to the name table used here). I guess there's no other way than to -somehow- select the appropriate gear from the mangos (udb/ytdb/...) item table? Should be a few weeks (at least) until I get here so hopefully we'll have some dev discussion on this.

[Unkle Nuke]

In regards to this bug, couldn't you simply use the function that prevents two players from using the same object at the same time? By that I mean using a value returned from it to make the other bots "snap out" of being stuck looting/mining/gathering something that is already in use/been looted.

Take an ore node, as an example. If more than one player's character is attempting to mine the ore, the first player that clicks the node flags the node as in use. Others who then attempt to mine the node will simply get the message "That item is already in use by another player." or the like. Could this be used as a flag to send a "cease and desist" order to the other bots?

Not sure if it's one of the core loot handlers, LootHandler.cpp or LootMgr.cpp, where the code is that you'll need, but would it need to be ported into Playerbot or just called by the bot module?

[kennumen]

I haven't looked at that code (... ever) or witnessed the problem so keep that in mind and take my comments with a grain of salt.

There may be a big clue in the 'get GameObject' code as to how to fix this bug (get as in playerbot commands survey and get). When this is used for quest objects, several bots may attempt to get the same GO but then (all but one) error out. If this is not the case, try adding a minute 'bot.move' after collection failure, that's how I always stop my mining/herbing/casting/anything in WoW.

Having a "snap out" check would be ideal (or would certainly exude intelligence), but it might be error-prone. Who's to say both bots won't stop collecting? See my 'group awareness' comment below, and expand that to 'everyone eligible to loot this item/object'.

Flagging nodes seems like a great solution, in theory. But you'd have to have players flag it as well as bots (if I mine, the bot should notice it just as it would notice it from a fellow bot). Then you really get into core territory, I feel. I *think* there were technical limitations against doing this (server-wide for non-bot players). Pretty sure that culprit is called 'lag'. Also there's a *lot* of game objects. It might cause a small performance issue.

So my vote would go to 'let it fail and have the bot stop collecting this GO once it fails'. It's not perfect but it feels like the safest way to do it and should be relatively simple to implement.

In addition to this, bots should be more aware of their group. Perhaps with 2 miners, one should be randomly selected per 'ore' detected (if both can mine it). With 3 quest items or 5 corpses to loot, the options should be spread across the bots - or at least the sequence of items to collect should be random. Too often am I now rolling my eyes at all 4 bots going through 10+ corpses in the exact same sequence. (this group awareness also goes into healers being primarily concerned with a tank's health and many other things)

[Unkle Nuke]

*sets aside algebra textbook and jumps off into the deep end of the pool*

Heaven forbid it should be necessary to flag every object in the game for the bots!

Conditionals are applied in the core, such as IsNear or IsVisible (not actual function names, just illustrating a point), to determine if any given character can even interact with an object in the first place. Only those objects that can pass such a condition would need to be further handled by the Loot modules, so the idea of using a CanLoot or IsLootable flag value to handle the lemming-like behavior of bots looting or gathering isn't as global in scope as it seems.

As for deciding who gets to loot or gather from a corpse/object/node, assuming two or more bots manage to simultaneously attempt it, you could use a "need or greed" roll to settle matters.

After all, for bots to behave like players, won't it be necessary to treat them as such in resolving these issues?

[EDIT]:

Nevermind, it appears blueboy solved the trouble in his next post even as we were typing.

*towels off and goes back to algebra book*

[blueboy]

Hi Guys,

Thanks for the ideas.

[bug] If two or more bots have the same profession (e.g mining), only one bot will succeed in collecting the gameobject. The others will continue mining a non-existent ore sample.

I have fixed the above issue. If one bot casts a profession spell (e.g. Mining - 2576) on an item first, it it possible for other bots to try indefinitely to get this item, although it has gone. I suspected that this maybe the problem, but I needed to find an appropriate place in the code to cancel the spell for the other bots. When the item is removed, an error message is sent through SMSG_CAST_FAIL, reporting SPELL_FAILED_BAD_TARGETS. Here I cancelled the spell, and the other bots now stop what they are doing shortly after the first. This should work for all collection type professions.

I have revised the 'NEED OR GREED' code in PlayerbotMgr.cpp. The roll will now correctly assign the 'roll choice' depending on the usefulness of the item to the bot. If the bot has the required skill (e.g SKILL_MAIL or SKILL_WANDS) then they will choose NEED. I have updated the function IsItemUseful() in PlayerbotAI.cpp to include ARMOUR and WEAPON skills. I also added a check on 'ITEM_CLASS_GEM' items (e.g Tigerseye) These items will be needed only by bots with (blacksmithing, engineering or jewelcrafting as suggested by WOWHEAD). I take kennumen's point that order of choice will need to be revised (i.e to take account of enchantment skill level), but at least it functions correctly. We may need to tweak the IsItemUseful() function more as well.

I have updated the GOSSIP_OPTION list in findNearbyCreature(). I found there were some questgivers from whom the bots were unable to interact with.

case GOSSIP_OPTION_TAXIVENDOR:

case GOSSIP_OPTION_GOSSIP:

also the bots seemed to be reluctant to approach the NPC with MovePoint(). I have disabled the default option to 'generatePath'.

I will shortly push the above changes to the portal master branch, for testing.

New Feature

I have revised the use command so bots can now apply certain items (e.g Sharpening Stone or Armour Kits) to those equipped.

use [Rough Sharpening Stone] on [bladed Weapon]

I will push this code to the 'new-ai' branch for testing.

Hope this helps

[kennumen]

Great work blueboy and BThallid. Got some nice momentum going

If anyone cares to test the new priest code (branch: new-ai), particularly the healing, or test the new druid code (branch: new-ai), particularly DPS at levels 5, 15 (with bear), 25 (with cat), 55 (with moonkin), see if those work correctly as expected, I would appreciate it. Won't be able to test these until the weekend and perhaps not even then.

Also I would like some feedback and ideas on how to automatically select gear for a character. For this you may assume some sort of check is available as to what item is best for a given character (e.g. a +40 strength mail shoulders would be better for a DPS warrior than a +50 spirit, +50 intelligence plate shoulders).

Personally I would like some sort of system that isn't pre-generated, so it works with any database (and consequently does not need maintenance, easier to modify to zero/one/future). This solution would however need some starting point, and not all items have a required level. So we would need to base it on itemlevel, which as I recall is not only in some way related to 'required level' but also jumps up as quality (green/blue/purple) goes up? I'm unsure if this would be efficient enough to do per character, *13 (? or is it 21?) equipment slots. And then add appropriate food, drinks, buff items, ...

Perhaps someone has a better idea, I'm all ears.

[plumkis]

evening is what you can do with a source mangos and more integrated vehicle in

j'esaye because to do so but knows not easy:)

[blueboy]

Hi Guys,

[bug] Paladins,Druids would exhaust all their mana trying to buff a warlock's imp.

This is not really a bug, but more an omission in the playerbot code. I tracked the problem down to the imp spell 'Phase Shift'

While phase shifted, the imp is now targetable but will remain an invalid target for all spells and attacks except self-cast spells.

So while phase shift is active, the imp can only be buffed by the warlock pet owner. If the imp attacks it will lose phase shift ability and this will give the other bots the opportunity to buff the imp before entering combat.

[solution]

The bots will not buff the pet if it HasAuraType(SPELL_AURA_MOD_UNATTACKABLE)

I have created a patch and I will push it to the portal master shortly.

@kennumen I am at present testing the latest code on new-ai, with the following party

[level 17] Paladin Holy SpellPower Focus (51/20/0)

[level 17] Paladin Protection Tank (0/53/18)

[level 17] Druid Balance DPS (56/0/15)

[level 18] Hunter Beast Mastery Leveling (53/18/0)

[level 17] Warlock Demonology Leveling (16/55/0)

Sorry I haven't got a priest bot in the team. Works a treat so far, but they're not tough enough to party so I haven't ventured into Shadowfang Keep yet

One tiny thing that I noticed with the talent tab, of the inspect window on the client. If open, it was not being updated as new talents were being added, using talent spec #. I created a help function InspectUpdate() that refreshes the inspect window, without having to re-open it. I have taken the liberty of amending the code so this is now done.

Hope this helps

[kennumen]

[bug] Paladins,Druids would exhaust all their mana trying to buff a warlock's imp.

This is not really a bug, but more an omission in the playerbot code. I tracked the problem down to the imp spell 'Phase Shift'

Had a feeling it was related to Phase Shift or Blood Pact - Technically that [em]is[/em] a bug, but a logical one (our logic failed to account for this eventuality). They're the toughest to track down, so good job.

Sorry I haven't got a priest bot in the team. Works a treat so far, but they're not tough enough to party so I haven't ventured into Shadowfang Keep yet

Thanks for testing. I'm not familiar with the lowered levels for dungeons but you should be prime to rush through RageFire Chasm (orgrimmar) and have a good time in Wailing Caverns (The Barrens). If you're alliance, The Deadmines should be good.

So the druid is acting as expected? That's great to hear.

One tiny thing that I noticed with the talent tab, of the inspect window on the client. If open, it was not being updated as new talents were being added, using talent spec #. I created a help function InspectUpdate() that refreshes the inspect window, without having to re-open it. I have taken the liberty of amending the code so this is now done.

Nice.

[ZPS]

Some playerbots improvements:

https://github.com/mangosR2/mangos/commit/64370c7a4e0c712ec8d7a3ac11fef198af64ffa3

https://github.com/mangosR2/mangos/commit/6e797003f0f372bfcd41171d8bb869f5d3dcbf89

[Unkle Nuke]

Thank you for giving back to the community, ZPS.

I hope many other developers will follow your example.

[blueboy]

Hi Guys,

Sorry for the delay in responding to the thread, I've been absorbed in dev work.

@ZPS Thanks for the links to the playerbot improvements and I'll monitor the work you are doing, cheers

I think I have a breakthrough in profession management. Are you tired of having your bot bags filled with reagents that they cannot directly use. Well, I'm pleased to say that I have found a solution in the new craft command.

Sometime back I was examining the feasibility of mangaing enchantments, but I hit a brick wall when it was suggested that the bots should be able to enchant soulbound items via the non-tradable slots. This worked if one of the traders was the player character, but not if both were bots. I got frustrated with the server continuely crashing so I shelved the idea. I have now utilized the code I created to manage other professions that rely on the consumption of reagents.

The initial craft command will allow your bots to create items, if they have the profession, the right tools and or appropriate spell focus (i.e near to forge, anvil, loom or cooking fire)

First aid

list all learnt spells to create medical supplies, indicating the number of items that can be created from all reagents in a bot's bags.

craft <firstaid | f>

[bot Name] whispers I can create:

[Linen Bandage][9][Heavy Linen Bandage][4][Anti-Venom][Wool Bandage][Heavy Wool Bandage]

[silk Bandage]...

craft [Heavy Linen Banadage] Create a single bandage

craft [Heavy Linen Bandage] all Create all [Heavy Linen Bandage] from available reagents

Cooking

list all learnt recipes, indicating the amount of dishes that can be created from available reagents.

craft <cooking | c>

[bot Name] whispers I can create:

[spiced Bread][basic Campfire][scorpid Surprise][4]....

craft [basic Campfire] required to cook by.

craft [scorpid Surprise] Create a single dish

craft [scorpid Surprise] all Create all [scorpid Surprise]

and so forth for all other professions. I haven't tested all yet, but I hope you will help and provide feedback

craft <blacksmithing | b>

craft <leatherworking | l>

craft <tailoring | t>

craft <smelting | s>

craft <jewelcrafting | j>

craft <inscription | i>

craft <alchemy | a>

craft <engineering | e>

I have a working patch and will be pushing the code to new-ai shortly.

Hope this helps

[ZPS]

Crashfix: https://github.com/mangosR2/mangos/commit/7165eaed1db6fd20072219fc0cd0c95040e7898d

[blueboy]

Crashfix: https://github.com/mangosR2/mangos/commit/7165eaed1db6fd20072219fc0cd0c95040e7898d

Thanks for the fix and I hope this stops your crash on mangosR2. I don't think this really effects playerbot on MaNGOS. I looked at mosst's crash dump and I don't think the problem is with a NULL pointer being passed in 'm_bot'.

if (!m_bot)

return;

This fix may treat the symptoms, but not the cause of the crash. I believe there is something else causing this bus error. This code has worked without issue for ages on MaNGOS. Like I said on GitHub, I cannot comment further without more information concerning the crash. I do realise your bots are in combat, but can you shed any light on what happens at the time of the crash?

How reproducible is this crash?

What is the nature of your bot group? (i.e small group, raid group and or mixture of bots and real players) and not dual faction.

What is the nature of combat? (i.e. are you just attacking a solitary target or storming a stronghold with many targets)

When I have time I'll try to test out mangosR2 and see if it crashes for me too.

Let me know

[sart13]

this crush impossible reproduce without mtmaps environment (parallel map processing). may be appeared after teleport master to other map, probability 0,000(period).

[blueboy]

this crush impossible reproduce without mtmaps environment (parallel map processing). may be appeared after teleport master to other map, probability 0,000(period).

Sorry, I think you may have misunderstood what I meant by 'reproduce'. If I was to create a server from mangosR2 code, under what circumstances would this crash occur?

[sart13]

If I was to create a server from mangosR2 code, under what circumstances would this crash occur?

1. working threads in server >2

2. online >200 (approx)

3. active bot usage.

[Joubarbe]

Hi,

I'm just registered to this forum because I guess this is the main place to see further development of Playerbots. I was searching for that...

Playerbots is IMO the main reason to have a private server, WoW becomes a kind of a old-school RPG where you have to customize and improve each one of your character.

I've got one question. I see a lot of repacks coming on various forums, but few on Mangos. I'm under Trinity and I'm wondering if Mangos is stable as some other emulators right now. I remember that Mangos was not stable, nor "complete" about one year ago.

So maybe I'll go to Mangos if the DB is quite complete, because playerbots are far from perfect in Trinity (is it possible to easily have playerbots compatible with Trinity ?)

Thank you for continue supporting this fantastic feature

EDIT : and I'm talking about the 3.3.5

[blueboy]

Hi Joubarbe,

We're glad you enjoy playerbot, and I agree with you that a year or so ago there were still major fixes being posted to resolve server instablity in the MaNGOS. However, those instability issues have all but gone. I can't remember the last time my server crashed (low population) due to the core code. Instability occurs when you start adding a multipicity of modifications to the core, that often conflict with one another. For this reason, I would avoid using repacks if you can. It's better to keep the number of mods to a bare minimum, and repacks don't always give you that choice.

The project Playerbots began on TrinityCore and the original developers then brought the playerbot project to MaNGOS, where it has since evolved through contribution from many developers. Unfortunately the TrinityCore project stagnated through lack of interest, all but the occasional burst of enthusiasm to get it going again. We have added playerbot support for MaNGOS Zero (WoW Classic), but time restrictions prevent us from providing support for all cores. I have been asked many times whether we will provide support for Cataclysm, but and as you probably know most code is based on a flavour of TrinityCore. One day, MaNGOS and we will be there.

The guys at mangosR2 are also doing excellent work and I was taken back by the number of mods they have incorporated in the code. This may well account for why the playerbot code seems to be causing them issues at present. My advice to you is keep the makeup of your server simple and if you have the know how, build it yourself. There is plenty of support here and on the other threads, if you get stuck.

Hope this helps

[Joubarbe]

Thank you for your answer Mango It's pleasant to have this forum, because a lot of players don't want to hear about playerbots ; don't know why... Being a GM and have the last Tier is not interesting for me.

So I think I'll switch to Mangos, if I can compile.

By the way, in the Trinity Repack I tried, the "attack" command was not working, so bots only focused on one target ; hard to manage with boss adds.

[Joubarbe]

I had an error : "automatic merge failed; fix conflicts and then commit the result".

I typed "git pull git://github.com/playerbot/mangos.git" after "git bash here" my "source" folder. So now I have the "playerbot" folder in C:\\Mangos\\source\\src\\game

And I'm really not sure of what I'm doing

Is this error normal ? (how can an error be normal ^^)

[blueboy]

I had an error : "automatic merge failed; fix conflicts and then commit the result".

I typed "git pull git://github.com/playerbot/mangos.git" after "git bash here" my "source" folder. So now I have the "playerbot" folder in C:\\Mangos\\source\\src\\game

And I'm really not sure of what I'm doing

Is this error normal ? (how can an error be normal ^^)

Hi,

Have you taken a look at our Wiki site. playerbot wiki

If you are merging only playerbot into MaNGOS you shouldn't get any merge conflicts. I will check this out just in case something has changed in the core. If you are using others mods in addition to playerbot then you will need to fix these conflicts before building. The normal directory tree is as follows,

<Source Root>src/game/playerbot

We have two main repositories with several alpha branches holding the latest code under development. (you are welcome to use these, but feedback is for developers information only (minimal support)).

playerbot playerbot release code This is tried and tested code (full support)

portal playerbot beta code This holds most of the latest playerbot features under test (full support)

If I were you, I'd start with a clean download of MaNGOS using the 'clone' command rather than 'pull'

git clone git://github.com/mangos/mangos.git <source root>

then choose which playerbot code you wish to use. You can merge the playerbot code in two ways, either directly or via a patch. I like to use standalone patch as this give you an opportunity to correct any merge conflict before actually applying the code. Once you have fixed the patch you can reuse it should you need to build the server again.

cd <source root>

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

If it merges without conflict, then remove '--check' and re-apply.

Merge Conflicts.

git uses code patterns (normally 3 lines) above and below the patch mod (patch sandwich), in order to find the appropriate location for insertion into the main code. The conflicts occur when these patterns do not match those in the main code (generally occurs if you apply more than one mod). git helps by marking the conflict in the main code with (use an editor and search for HEAD)

<<<<<<< HEAD

conflict

>>>>>>>> <hash>

Remember to remove the conflict markers before saving the code, otherwise it won't compile

Look at both the patch code and the main code and compare. (You are merging into to main code so this is your standard). If one or both patterns differ, then copy and paste these from the main code to the patch ans save. Also remember to insert a space at the beginning of each of the 3 lines copied, otherwise the patch will be broken i.e.

<one space>If (this is the first line)

<one space> hereisthesecond();

<one space>andTheThirdLine();

+ first line of patch to insert

<one space>If (this is the first line of the lower 3 line pattern)

<one space> hereisthenext();

<one space>andTheLast();

This link may also help you resolve any conflicts http://book.git-scm.com/3_basic_branching_and_merging.html

Occasionally the conflict occurs in the patch itself, say for instance they suddenly decided to rename a function in the core. A keen eye is required and alot of patience.

Hope this helps

[blueboy]

Hi,

O.K there is one conflict which is to be expected. A DB reference for playerbot has been inserted into revision_sql.h. This conflict will be flagged each time the core or playerbot modifies this file.

Direct merge method

git clone git://github.com/mangos/mangos.git MaNGOS

cd MaNGOS

git pull git://github.com/playerbot/mangos.git master

CONFLICT (content): Merge conflict in src/shared/revision_sql.h

Automatic merge failed; fix conflicts and then commit the result.

To fix this, replace the 3 line pattern above and below the playerbot reference

Before with merge conflict markers

#ifndef __REVISION_SQL_H__

#define __REVISION_SQL_H__

#define REVISION_DB_CHARACTERS "required_11785_02_characters_instance"

<<<<<<< HEAD

#define REVISION_DB_MANGOS "required_11852_01_mangos_gossip_menu"

=======

#define REVISION_DB_PLAYERBOTAI "required_1_playerbotai_talentspecs"

#define REVISION_DB_MANGOS "required_11831_02_mangos_command"

>>>>>>> c2bd780b4aed5982c9535fcfe896700291759e48

#define REVISION_DB_REALMD "required_10008_01_realmd_realmd_db_version"

#endif // __REVISION_SQL_H__

After with conflict markers removed

#ifndef __REVISION_SQL_H__

#define __REVISION_SQL_H__

#define REVISION_DB_CHARACTERS "required_11785_02_characters_instance"

#define REVISION_DB_PLAYERBOTAI "required_1_playerbotai_talentspecs"

#define REVISION_DB_MANGOS "required_11852_01_mangos_gossip_menu"

#define REVISION_DB_REALMD "required_10008_01_realmd_realmd_db_version"

#endif // __REVISION_SQL_H__

save the changes and then build

Hope this helps

[darkfr3ak]

With this help i got one of the errors solved, but now i forund another one:

9>..\\..\\src\\game\\playerbot\\PlayerbotAI.cpp(7555) : error C2660: 'Player::GetTrainerSpellState': Function doesn't accept 1 arguments

The error-message is freely translated, cause i'm german.

I hope you can help on this one.

I really love your work with the playerbot, and i really want it in my game