kyle1

To Syenet: There's no need to log bot actions to understand what happens during combat. Just look at the code and you'll see that combat performance cannot be efficient now. All class AIs use same idea - spell sequences. Usually there are three of them. Bot iterates over one sequence and switches to another one. I wonder if this code was written by bots as well... If you know a bit of C++ then fixing combat for a chosen class wouldn't be a big problem. Playerbot has most of functionality required in combat. To fix compilation try to add this to PlayerbotAI class: typedef std::list<uint64> BotLootList; typedef std::list<uint32> BotSpellList; Blueboy probably forgot to include typedefs into last commit.

When posting about compile errors make sure you have copied compiler output into your message. This will make devs' life a bit easier

There is a benefit of keeping SQL updates as separate files - anyone can update MaNGOS database to revision he/she needs. Automating updates is great but writing executables will make people on other platforms sad. Maybe a python script?

Thank you for your work. Once again you're fixing stuff I'm interested in Playerbot mod will greatly benefit if you implement RangedChaseMMGen, cos right now there is no clean way to make ranged combat bots to follow their targets.

If "my mmaps system" is faramir118's project then there's nothing to force. Pathfinding works fine for bots. If "jumpin around" means "teleporting while moving" then mmaps has nothing to do here. It's a playerbot problem which I hope will be solved soon. Cheers.

These are the words that should have appeared in the first post. There is no need to take it personally.

Then it's a hack which never lands master.

Wait for blueboy or me to update github repo. Current MaNGOS revision in portal repository is 10720 and yours is 10744. And portal does not crash for me. Looking at your log and previous post about merge conflict, I can say that problem is in Object class. Maybe it is MaNGOS problem, maybe Playerbot one, or maybe it is your merge problem.

Fix pushed. I can't really test it cos I have no VC, but error log was verbose enough to see the problem. GCC is not so picky as VC... sometimes

Please post compilation errors here. Latest portal code works fine for me.

Thanks, Schmoozerd. Your patch should also help Playerbot mod. Bot orientation update is a long standing problem there.

Oh man. Press SHIFT when buying several items from vendor.

I've updated Lynx3d's patch to revision 10667. Link: http://paste2.org/p/1070438

Bots should have same quality mounts as their master has. For example if your mage has 100% ground mount and hunter has only 60% one, then he won't mount at all after master.

I believe it is way it should work. You can read blue post about buff stacking http://www.wowwiki.com/Buff#Buffs.2C_debuffs.2C_and_raid_stacking_in_WotLK

Bump once again! This code works for almost a year. Please merge it upstream.

Ideas can always be discussed. I usually create a branch for new stuff, so people can leave comments on the code before it gets merged. Of course you can post pull requests from your own git repo. Thank you. I've been thinking of implementing it as well. Speaking about reagents I think bots should always use them. They are not so expensive.

There is a new branch in portal repo called 'buffs'. It is a try to implement sane buffs for bots. New buff() method performs several checks before casting a spell which include: 1) Target level. If level is too low, then AI looks for a lower rank of the spell. 2) Target auras, If spell applies an aura which is better then one that already exists on target, or target does not have such aura at all, then spell is casted. This check allows to overwrite auras from same spell if new aura has better modifier. One example is talented Blessing of Might. MaNGOS core does not perform this check and always overwrites such auras. So far only paladin AI was updated to use this method. There is one flaw in current implementation, I want to point to. Since paladins can have only one blessing per target, in several scenarios paladin bots will "lock" their talented spells for buff targets. One way to solve this problem would be implementing buff manager, which will decide how each bot buffs each target. This will require some kind of command queue for bots.

HasItemTotemCategory() has single argument of uint32. Boolean expression will give you true of false. So in this case it is equivalent of calling HasItemTotemCategory(true). There is also Gnomish Army Knife, which has its own totem category. We have two options: 1) Call HasItemTotemCategory() for all pickaxe categories, or 2) write own method which would check all types of picks in single iteration.

Pushed to portal. Thank you.

If i understand you correctly you merged latest mangos into blueboy. Linker can't see Playerbot headers. Was your merge clean?

Hi, Famine Blueboy's repository includes support for Playerbot. There is no need to patch it. If you want to build your own flavor of MaNGOS with custom patches and addons, then I'm afraid you must learn how git works. Because almost all the forks are on github too. When you do it, you'll see how powerful this tool is.

Yes, merge them please. I see Vladimir is replacing uint64 guids with ObjectGuid in recent commits. We are going to face new compilation problems soon.

No, you are not I've just pushed compilation fix to portal repo, grab it now. Can't update blueboy repo as well due to very slow internet connection. I guess its time to learn cherry-pick feature in git... Fix is known only to compile, report bugs if you find any.

Sorry, I was wrong on GUID format. Regarding resurrection I can't check it right now, but from my experience on retail you can revive player anytime, even after release. The only thing that stopped players from release was death during boss fight cos they were losing their rolls on loot.