kennumen

once compiled treat it as an ordinary mangos distro. copy the .exe and .dll files to the proper places, etc. Only other difference is the playerbot.conf file.

This is in fact incorrect. Soulbound items can be entered into the trade window in the special 'will not be traded' slot, and can then be enchanted by the other party. The soulbound item can of course not be actually traded. Jewelcrafting just sells the jewels which the owner then puts into his equipment. Armor patches work in the same way. Do keep in mind that every profession has some 'owner only' perks, such as a enchantments that can only be cast on own gear (or is it that they are only effective if worn by someone with enchanting 325+ for example). Probably the latter (else you could just enchant non-soulbound gear with the very best and still trade it). Also, most engineering things do in fact require engineering, so what I said above is not a catch-all statement. But then enchanting is probably the only one that uses the 'will not be traded' trade slot. Hope this helps. Will be working on sharing my branch later tonight or tomorrow. It's not complete (roughly halfway?) but I'm eager to share and get notes.

I looked into part of this a while back before I was away. I had revamped the code for the bots to enter instances by using SMSGs at appropriate points or in response to other pieces (I am a strong believer in trying utilize the server handlers instead of trying to recreate the procedure inside). This process though brought forward a glitch that is in the core code to happen 100% of the time. The glitch in the core is when a you enter an instance with a group of other players, but some (or just one) of the other players are invisible to you. With the instance changes in place that I had, the bots were always invisible to the master. I could have another player already in the instance or enter after the bots were there and everything would be okay. The only way I was able to get around this was to put some delay code with an added bot state in the bot code to have them wait a few seconds before following after the master. After that, it worked great, but I didn't like the idea of using any delay code. I started to investigate which part of the core was the problem, but got busy with the real life stuff that happens to all of us. Striving for perfection is admirable... It's your code to do with as you wish, but an imperfect fix is still a fix. Personally I'd just put in the fix along with a TODO comment, to fix/improve myself (or by someone else) later. I also agree with your SMSG comment - it's always best to work on a high level using methods already present than reinventing your methods, that would be inviting bugs. Having said that, I may be re-writing some things myself simply because I don't know if or where they are. Sometimes you just have to let it go and accept imperfections or you'll never get anywhere It's not about unlearning old spells, I think it's just hard-coded to use the bottom rank spell. All it needs is one line of code. I'd take a look myself but I'm not yet familiar with spellIds plus I have that talent stuff to finish. Thanks for reporting it.

165: /w BOTNAME nt [Powerful Soulbound Item] As far as trading and having a bot enchant your items (or those of fellow bots), no, that's not supported. ... Yet, anyway. Would respond to the other posts but just got no time right now, catch you guys later. How about I would enchant bot's gear. - I would initiate trade and then I would /w enchant ITEM. - Bot would put that ITEM into "Will not be traded" slot. - I'd do the enchanting. Maibenrai As i said that command's already present: /w BOTNAME nt ITEM so in the case of Akuba: /w Allod nt [Golden Bracers of the Gorilla] ... for example. then you enchant. /w - whisper BOTNAME - whisper target nt - command: no trade -> put item in no trade slot ITEM -> item to put in no trade slot.

165: /w BOTNAME nt [Powerful Soulbound Item] As far as trading and having a bot enchant your items (or those of fellow bots), no, that's not supported. ... Yet, anyway. Would respond to the other posts but just got no time right now, catch you guys later.

I've made all these plans and hadn't even tested instancing (but in my defense, my main is stuck at level 6). Tried out RFC with a level 80 lock and a level 80 hunter (with pet - nice clue here). Enter RFC, the wolf spawns next to me and starts running off. Look at the minimap, the hunter is southeast but too far even on max zoom out of the minimap. I go back out (because I have the start gear at this point), the hunter stays in RFC. "not close enough to vendor to sell" ORLY I go back in, wolf spawns next to me running off again. I start attacking a mob (to see if I can clear my way to the bot) when as the first mob dies the hunter starts running in. I go out of RFC, the wolf spawns next to me and starts running off. I go back in, the hunter spawns (relatively) close but in lava. I got back out, wolf starts running off again. Check the world map, the hunter is in Stonetalon Mountains (where I am in Orgrimmar, obviously). From what I can tell it works, just teleporting coordinates gone haywire. Something worth looking into.

Tough to say without inspecting the AddOn in question. Is Pallod perchance the healer? Tank? Focus target? Or perhaps it's linked to who you're targeting? Perhaps he's selected in HealBot?

Correct, the entire config file failed loading. I missed that... I like the database table. It seems by far the cleanest and most extensible way. But not as a blob. If you're going to have a custom table, might as well do it right (see my blueprintbelow). Each TalentSpec will fit on one line and should load without error. True, it will work just fine. But in essence it's the same as hard-coding: for each seperate config file variable you need matching playerbot code to load it. This essentially defeats the purpose of having it in the config at all. You could take your idea, and do something like: It should be possible this way to load a variable number of talent specs. However it's hard to maintain and very prone to human error. What if you've got 30 specs and you want to remove #8? You would need a manual counter as well (of how many specs there are) which again very prone to human error. It's certainly possible but this just makes a database table look that much better. Suggestion (I invite you to comment on this): Name - Varchar (255) - text, up to 255 characters including string zero terminator (as I recall). No plans to support localization (except enUS). Class - tinyint (signed) - 1->127 for actual classes as per "enum Classes" in SharedDefines.h; -1-> -3 for pets (cunning, ferocity, tenacity); 0 errors out. Purpose - either INT (unsigned), severely limiting additions/removals of the purpose types, or a Varchar(255) to fit the text version. Still very undecided on this. INT is clean, fast, obviously great... IF you never ever ever intend on adding more than 10 PVE or PVP purposes. ... Although in that case just split it into a PVE and PVP int, problem solved. So I vote INT, but welcome your opinion. See my current TalentSpecPurpose enum below. Talents - 71x SMALLINT (unsigned: 0-65535) - you lose support for servers with more than 71 talents. But a blob is just slow and... dirty. I suppose if someone asks it should be possible to have a variable amount of talents in the table. Glyphs - 6x SMALLINT (unsigned)- no question as far as I'm concerned. Quick, sleek, ... Good advice always does, so keep it coming.

Okay, I've made some headway. All the errors are gone (yay me), the code compiles (even in debug), it runs fine, I've turned on the debug file logging, and the commands... They don't do as expected but they also don't crash the server (which is sort of a win already). When using the command "talent spec" on a bot, the following debug comes out: The only place that logging could come from is the PlayerbotMgr constructor, where I've placed: Playerbot.conf, on the other hand, contains (an unshortened version of): Best guess, the config loading code sees the double quote, assumes text, sees a newline, ends input, ignores the lines below - it does not process until the double quotes are closed as I'd hoped. Would you agree with that assessment? If so, I either need some other form of input or I simply scrunch the PlayerbotAI.TalentSpecs data onto one line (which would wreak havoc on maintenance - and possibly text editors. That would seriously be one looong line). If so I'd probably use yet another seperator such as |. Any suggestions on how to best input this data? ... There are a finite amount of 'good' talent specs, perhaps I should just hard-code them? I dunno. Time to sleep on it.

Haha, big step from my initial intentions. I'm telling you up front chances are between here and a few months I'll lose the willpower and motivation to work on this. If that's fine with you, my github username is the same. <edit> I guess you already found it, thanks for the invite. </edit> Thanks for the link. I've gone over the entire thread but back then I must've thought "interesting... but it's not like I'll ever be a developer". The patch is 'huge' (note to self: define huge - too big for a forum post at least). Though most of it are enums of the various class and pet talents. The problem is there's a few things my rusty C++ can't seem to iron out <just yet>, and even if new-ai is an alpha branch the code should at least compile. While I've got your attention, have you got some sort of "onLevel" handling yet? I did a search in the playerbot code and a quick one in player.cpp. If there's none in Playerbot I'll implement a hook, but if you've done it already and I looked over it I'd appreciate if you could point it out for me. (Put simply, yes I'm lazy but this is about you telling me in 5 minutes what I'd look for for 2 hours - not about you looking for it for 2 hours instead of me). Also, you may want to think about adding some basic Git commands to your first post. It's a question I've seen come up time and again, and you shouldn't have to repeat yourself. A few basic commands: Full download of playerbot code // download the entire playerbot code into a folder 'playerbot', optionally using the 'new-ai' branch // recommended if you want an easy copy of playerbot and the mangos version doesn't necessarily have to be the latest git clone git://github.com/blueboy/portal.git [-b new-ai] playerbot creating a patch (show example with playerbot code, including git clone of mangos core) creating a local patch with local playerbot and local/web core/playerbot (see post 101) maybe even a developers crash course... although that might confuse people who aren't developers And with that an explanation of the differences between the branches. The first post also mentions a wiki of sorts "which may be out of date". Link it as well?

I'm somewhat close to having a patch ready - except I don't know how to create it. I know how to make a local copy (aka download everything): and I know how to make a patch file from a github source to patch into a local copy: Of course this is the other way around; Every + should be a - and vice versa. What I don't know is how to make a patch file from a local copy (for someone else) to patch into a github destination. I did a few searches but it looks like I won't figure it out without a lot of research. Any chance someone could sum it up?

Well, quite a few ideas, but I was actually specifically asking if that config file would load. Whether it would ignore the newlines and keep loading the string until the second double quotes '"' had been reached. But as I realised last night, that's something I can look up myself. <edit> Actually, I did look it up, got to Configuration.cpp line 1933ish, couldn't decrypt what was there. Will just cross my fingers and try it instead. </edit> In these cases I tend to prefer to shy away from database changes. If you were to add a seperate table instead of modifying an existing one, that would minimize the impact. Of course it would mean yet more .sql files Correct, so far I've been looking at it solely from a server admin's perspective. Then again, the config file is a very simple way of adding things. Having a user enter 71 talents + 6 glyphs (can you imagine how many lines would be typed? far more than one, for sure) is... Frankly, a bit mind-staggering. I was and still am planning on ignoring the end-user. WoW is pretty much a game where there is a 'best spec' for every class+purpose combination. If I do my job right and/or get enough help, 95% of the players would be satisfied with the build for their own characters, let alone characters they aren't personally playing. The rest will have to make do with a simple "learn talent X" command. Times 71. Per bot. If you disagree... wait a few weeks for my patch and improve on it As for how to use a talent spec... I was thinking of keeping it simple. A step-up scheme (like a pyramid - every step eliminates a few choices): .bot <paladin_char> talent spec 1. Paladin Protection Tank (0/53/18);PVE_TANK,PVE_INSTANCING 2. Paladin Holy SpellPower Focus (51,20,0);PVE_HEALING,PVE_INSTANCING 3. Paladin Fast Leveling (0/10/61);PVE_LEVELING,PVE_DPS .bot <paladin_char> talent spec PVE_INSTANCING 1. Paladin Protection Tank (0/53/18);PVE_TANK,PVE_INSTANCING 2. Paladin Holy SpellPower Focus (51,20,0);PVE_HEALING,PVE_INSTANCING .bot <paladin_char> talent spec PVE_INSTANCING,PVE_HEALING 2. Paladin Holy SpellPower Focus (51,20,0);PVE_HEALING,PVE_INSTANCING .bot <paladin_char> talent spec use 2 Applying talents using: 2. Paladin Holy SpellPower Focus (51,20,0);PVE_HEALING,PVE_INSTANCING For a simple example. Can be refined later on using user feedback but that will probably also be the fastest and simplest way to get a working proof of concept. First next thing would probably be to issue a warning if wrong talents and/or out-of-order talents are already learnt along with a reset talents command/link. have fun coding and I'll speak with you soon, Cheers I think I've actually modified those to be a bit clearer. Guess it's a race to see who gets their patch done first. Safe bet's on you You've given me a lot to think about but I think I'll just go ahead on my path and adapt once it's 'finished'. Until you see the patch I'm just a meatbag filled with air.

and you should have 2.5.4 or greater. If not, this would account for your error You are correct, I have 2.4.2. Since my replacement line works, I'm not really bothered by it; In fact I'd rather keep it this way so any future installations will 'just work' rather than having to remember I updated grep. Anyway I've done some work on talents in playerbot. I'll make you a .patch file once I get something more complete, but I wanted to get your thoughts on this first. I needed a readable way to get a variable number of talent specs into the config file. Readable of course meant multi-line, but none of the config files had that yet. Will this work? Or is there a better way to do it? I also noticed something strange when I was hunting for talent code: In PlayerbotAI.h, looking at enum TaskFlags (+/- line 144), the flags are not combinable: SELL_ITEMS 0x01 + BANK_WITHDRAW 0x11 = BANK_DEPOSIT 0x12 If they are meant to be combinable, 0x0B, 0xB0 - if not, simply run up ..., 0x02, 0x03, 0x04, 0x05, ... Since there's 9 options + the reset, you'll just need to use a short if you want combinable flags. Off to code some more... Zug zug.

That's what I based my procedures off of (thanks much) but the HASH line gave me errors on windows. Instead, I adapted it to: Don't ask me why or how (especially since I did that 4 months ago) - google is your friend It does the job though, and does it well.

AHBot has been integrated with the core, no need to patch it in anymore (doing so would probably explain your error). As for armory, I wasn't aware it needed to be patched into the core (thought it was 100% website) but it should play nice with playerbot. From the log it definitely looks like the rogue was trying to pickpocket a pet. [em]During combat[/em]. Did I read that right? The 'talent' command allows you to add bot talents as they level up and you can even get the bots to reset all their talents, if necessary (cost increasing each time it is done, for a particular bot). I added this to playerbot in reponse a request by someone who also going to develop the playerbot ai further. He then promptly disappeared The code is in place and I'm sure it can be further adapted if required. Hope this helps Honestly I wasn't planning on doing much coding. My attention span is generally aroundabouts 3 months and I wanted to avoid helping out, quit midway, and end up doing more damage than good. Anyway, I'll take a closer look at the talent code you did a while ago, hopefully this weekend, and see if I can't whip you up a nice little patch. Thanks for pointing me in the right direction. There is an awful lot of code to simply dive in.

We were all WoW newbies at some point, so don't sweat a lack of knowledge - it can be gained easily enough. Talents become more important for anything high-level. Not just for PvP, also PvE. With talents your spell rotation/queue becomes different. Some spells become stronger, or you get a new spell from a talent. It's not as important as good gear, but it's definitely up there come level 80. For now, my main goal for talents in playerbot (beyond understanding and using them better) would be to have the bots acquire their talents (once levelled) according to a player-chosen talent spec. Once this is in place, it would provide most of the framework for any other talent things in playerbot (including stand-alone bots). In any case, have fun getting "some experience"

Felt like contributing, thought I'd go look at the talent code to see if I could help somewhat with talents in playerbot. After a little searching I found the talent tab info, as well as the talent info... Except I didn't find any link between the talent description and the talent ID. It makes sense that the description wouldn't actually be necessary server-side, so I set out to link it (mostly to be used in a possible future playerbot Talent Template processing, but also to have a correlation between IDs and names, to easily look up). I got the info from the gamestool 3.3.5 talent calculator - no direct link because that site is NSFW. The result was made to be pasted into Excel (or Calc or whatever your office suite's spreadsheet software is named). The information is actually probably out there already and I should've done it more automatically instead of typing it all over manually (so yes, there may be a typo or two - but I sure hope not), but too late for that now. If you happen to do the talent enums (should be easy enough with a concatenate), these would probably go in "src\\game\\dbcenums.h". Oh, and all the "#N/A" errors you get near the end is because I simply didn't do the Pet talents. Concerning your LESSER_HEAL solution it's more elegant. I don't agree with the pecking order though. Flash Heal is a viable spell even later on due to its speed (as I recall it's main weakness is not a lack of HPS but its mana drain), good for emergencies. Also, I think it's HEAL that replaces LESSER_HEAL, without having anything to do with FLASH_HEAL. But it's been a while since I played a priest, let alone a healing one. Since LESSER_HEAL isn't ever really meant for emergencies I'd simply have HEAL replace LESSER_HEAL when HEAL becomes available and leave FLASH_HEAL out of the replacement conditionals. Since you're so enthusiastic I have more information for you to read. I don't agree with all of it but it's probably less biased and a bit more complete (but less detailed in some areas) than what I wrote before, so it's certainly a good read. Instance Grouping Guide and Newbie battleground guide.

Arena As for Arenas and Battlegrounds... Let's start with arenas. They should be simple: it's still only a party (2v2, 3v3 or 5v5). There's different optimal gear, different talent specs and different spell rotations (geared towards burst damage rather than maximum dps) but frankly I don't see why it wouldn't work with the current playerbot (albeit suboptimally) - with the relatively small modification to attack players instead of mobs. The arenas are more or less square and the only objective is to kill the other team. The only real difficulty will be finding opponents. And perhaps getting the bots to join your team. Battleground Basics On to battlegrounds which are quite a bit more complicated. In addition to what I've mentioned above, I see three big steps that need to be taken for playerbot to be viable in battlegrounds. Maps and such can be found here but ignore the level ranges, those apparently have changed for Cataclysm. This is mostly for blueboy and those who haven't (or barely) played battlegrounds. The AI needs to be able to work individually as well as in small groups, and there also needs to be map-wide coordination. While it's generally better to be in 'groups' of 2 or 3 (and/or a giant swarm or two), sometimes a few single players going off on their own can mean victory. In any case it's very different from the PvE minded AI now where the entire party/raid should stick together. Quick example: WarSong Gulch, 10v10. A group of 3 defends, a group of 6 goes through the middle to defeat the enemy, slowly going towards the enemy flag. Finally, a single player goes off alone by the side - Perhaps there is only 0 or 1 defender, or the defenders are too busy fighting the swarm to notice a single player. Perhaps there's 2 defenders, a swarm of 5, and 3 trying to sneakily get the flag. Make it random, unpredictable, and it should be fun for the humans. The AI needs to understand the objectives of the battleground in question. See list below The system needs to be able to add playerbots not linked to actual human players. Since battlegrounds (and arenas) require two sides - while not strictly necessary - it would be beneficial to have playerbot add AIs not under the command of players. Further explanation below Battleground types information: - [em]only for those not familiar with BGs[/em] There are flags to acquire and bring back home to your own flag/base. Likewise, when the enemy has your flag, you must return it. If each team has the other, the enemy flag must be defended in your own base while attempting to retrieve your own. (First Person Shooter (like Unreal Tournament): Capture The Flag) There are 'bases' (call them immobile flags if you will) to capture. Here you need to channel a 'capture' spell for a bit without being interrupted by an enemy. Once that succeeds, it takes a bit longer for it to actually become yours - the enemy usually has a minute to cancel your 'takeover'. Holding bases can yield various advantages.(FPS: Domination) Destructible items can be objectives. Towers or gates are the only ones, I believe. Some battlegrounds are mixed offense and defense. Others are one side does offense first until time runs out or they win, then the other side tries to beat that time. (FPS: Assault) These objectives are combined in different ways: WarSong Gulch: Capture the Flag. 3 Flag captures wins the match. 10v10. Levels 10-19, ..., 70-79, 80 Arathi Basin: Domination, 5 bases. Holding more bases gets exponentially more points (over time). 15v15. Levels 20-29, ..., 70-79, 80 Eye of the Storm: mix of Capture the Flag and Domination. Single flag to bring back to a friendly base, 4 bases. Holding more bases gets exponentially more points (over time and per flag capture). 15v15. Levels 61-70, 71-80. Alterac Valley: A kind of assault but where both teams attack and/or defend at the same time. 4 towers (or so) to destroy/defend, with PvE boss (+ 1 crony per still-standing tower) at the end. 40v40. Levels 51-60, 61-70, 71-80. Strand of the Ancients: Alternating assault. 3 to 5 gates to destroy before destroying a crystal. Then the other team tries to do the same faster. 15v15. levels 71-79, 80 Isle of Conquest: Domination (bases held also activate various things like siege weapons, a zeppelin, ...). 3 Gates per team to destroy. Frankly forgot the winning objective. PvE boss probably. 40v40. levels 71-79, 80 World Zone - Silithus: Capture the Flag, sort of, except there are lots of flags, each making you slow and highly visible. World Zone - Eastern Plaguelands: Domination. 4 towers. World Zone - Others World Zone (WotLK - not listed in link above) - Wintergrasp: Assault, the winner of the previous Wintergrasp is defending. Gameplay has a lot in common with Isle of Conquest. Stand-alone playerbots - [em]advantages[/em] This is something I've been thinking of quite a bit, but I haven't got much to show for it yet. The idea is simple. Example: A player wants to run through an instance of shadowfang keep. Instead of creating 4 more bots and levelling them to that point, he simply uses a command to summon them (or, once it's working, playerbot interfaces with Dungeon Finder to fill out open spots). Another example: The player finds out about dragon flying mounts. He goes through the quests. All of a sudden he comes to a 5man party world quest. Woops, hope you've kept levelling alts. Or you simply run a few commands, ".bot request tank", ".bot request healer", ".bot request dps" x2. A few moments later *poof* there they are, ready to auto-accept your party invite. Yet another example: You enter Silithus. Unfortunately this is an unpopular zone (mostly due to outlands levelling/gear). So Mangos loads the zone (because there were no players before), when it does that it also loads a few playerbots and flags them PvP. You no longer feel alone in the zone, [em]and[/em] the world zone pvp becomes a whole lot more exciting. And yet another example: You're 48. You (or you and a few friends) want to do some Arathi Basin. Your server has low population so BG queues are pretty empty, let alone at the 40-49 bracket. But fret not, playerbot immediately fills your battleground to 12v12 (80%, plenty room for human players - better yet, setting for playerbot.ini). Should more humans join you can even remove a bot or two. Stand-alone playerbots - [em]Enough about why I want them. Onto what we'll need.[/em] First you'll need a way to add players. The right way of doing it would be to use Mangos' functions to add an actual account, add a character to it, and log it in. It looks hard when I look over the database, but it should be easy enough with the core's functions. The quickfix way of doing it would be to simply add a new table under characters. It probably wouldn't really be quick though. Things would quickly creep up like bot exploration XP, bot inventory, ... Although, come to think of it, playerbot uses 0-9 bots from one account, so perhaps you could do it with a single account adding 50 characters to it? Once you've created characters you'll need to set their race, gender, class, level, appearance. Summoner's level +/- 3? Another setting for playerbot.ini. You might also want to (optionally) allow this to be specified by the summoner, within limits (as in, max level = summoner + 4). There's also talent builds. Each talent build can of course have it's own glyphs and spell rotation (if not specified, fallback to default). As many ways of input as possible (e.g. [5/5 Toughness], or just {[10, Toughness], [11, Toughness]}, ...). Will need to be specified with: class, PvP or PvE (... or both?), function (tank, healer, dps, hybrid/assist-tank, hybrid/assist-healer) and Description. For example: Death Knight, PvE, tank, "Blood Tank 51/17/3". Actual talent build: "DEATHKNIGHT","Blood Tanking (53/8/10)", [5/5 Toughness, <SNIPPED FOR READABILITY>, 3/3 Will of the Necropolis, 5/5 Blood Gorged, 1/3 Bloodworms] [Major Glyph of Disease,Major Glyph of Death Strike,Major Glyph of Vampiric Blood,Minor Glyph of Horn of Winter,Minor Glyph of Raise Dead,Minor Glyph of of Pestilence] [em]Protip: don't hardcode this. Put it in the playerbot.ini or even an extra .ini[/em] Let's not forget equipment. Here I suggest a trickle down system. You create a character level 27 for ShadowFang Keep. There are no hands listed for (that class, function, and) level 27, look at 26,25, and so on. TODO: expand for a bit of variation. It should be possible for equipment to be tagged PvE or PvP, but also to link those equips to an instance. Once you're level 80, level doesn't tell you much as to how good the equips should be. TODO: Add coefficients to the playerbot.ini to make gear better/worse for bots (seperate setting for PvE and PvP). Change difficulty of instances and battlegrounds (or, in other words, increase/decrease human contributions). Perhaps even allow these settings to be changed in-game for that particular instance/party/side/... [em]Protip: don't hardcode this. Put it in the playerbot.ini or even an extra .ini[/em] There's a few more thoughts I have but this post is in danger of becoming a wall of text so I'll leave you to ponder and reply to the above.

You were absolutely right, GM was on. I was under the impression I had one admin and one regular player account but I guess I got fed up of switching pretty quick. Thanks for the advice. I second that desire for a BG & Arena viability but I feel like an instancing AI is much closer to being finished and shares many of the same building blocks (of things to come as well) so I'm currently throwing my interest behind that As for raid markers, you could do it simply with commands or some sort of automatic list, and eventually that's probably where it's going (the tank generally does the marking so if the tank is a bot...) but you're talking about a complex algorithm there about which targets to mark and how. For now I'd be excited just to see a prototype of the bots following the raid marking 'orders'. As for your addon idea, it sounds like all you need is an addon supporting very long macros (which, I believe, exists already). Then just look into adapting spell sequences (and/or spell priorities which I believe -only- paladins use) into playerbot sequences. Still, that's some pretty low-level micro-managing you're talking about. Personally I'd get burned out quick and thus am in full support of something like this being automatic. Also, if I understand correctly, most of this is tweaking. Such as - this sequence on that mob, that sequence on that boss, ... Good catch. I checked a few sites but lesser heal is no longer on them (I guess it went away with Cataclysm). As I recall though, at a certain level lesser heal becomes either replaced or just functionally obsolete (by regular HEAL, isn't it?). So your if check should probably include a level check or better yet a check whether that replacement spell has been learnt. Anyway, very nice work for a quick fix. I would however suggest changing the hp check to something like hp < 50 (because that's health %). Assuming it is HEAL, just change this line: That way it will simply use the better of the two.

Bit of a wall of text, but hopefully that makes it more clear. I figured as much, but thought I'd mention it anyway. Now that AHbot is core, and loot-bt-fix + vendor is in playerbot, I'm not using any other mods. Of course, there's the possibility it's DB related. Anyway, don't worry about it, I'll look into it later. You mention several good ideas there (reminding me of one I forgot to mention) but none relate to what I suggested. The pull command would be (mainly?) used in PvE instances and elite world mobs. The whole point of it is to aggro as few mobs as possible, including nearby mobs and patrols. Thus you 'pull' a mob towards you with a ranged attack, waiting for the mob (and as few of his friends as possible) to come to you. I did go on to a few alternative actions when a pull command is issued, thinking ahead a bit. If you try to pull a mob, first you have the tank (or whomever) cast an attack to aggro the mob. If the mob starts casting, chances are it will never come to you. Two options - run away a bit (in an instance, this would be towards the entrance a.k.a. back to an area previously cleared), until they follow you a bit, thereby 'pulling' them (in relation to their starting position) in a roundabout way, or you could throw caution to the wind and jump in there like a leeroy jenkins. Easiest - for proof-of-concept, before tweaking - would probably be to just pull, [have the system issue a 'stay' command and] wait ~5 seconds, and then [have the system] issue an 'attack' command. If you try to pull a mob and it changes position, chances are it's coming to you (or, albeit unlikely, it's out of range of it's spells). In this case you could simply wait until the mob is within, what, 5 yards, then [have the system] issue an attack command to the party. What I was trying to explain about healers previously (and I can't say definitively if this (already/still) applies to 3.3.5a mangos) is that threat is increased based on range to the mob. So a tank within 5 yards might get 130% threat to that mob whereas a healer 30 yards away would get 100%. For in-game info on this, I think they added an in-game threat meter, if not, try the Omen addon (should be able to find it at wowinterface - 3.0.9 is the last pre-cataclysm version). I'm sure you realize the core of any group is the tank and healer. If the healer gets aggro, the tank must go berserk (so-to-speak), or the entire group ([em]almost[/em] always) dies. In that way, imagine a equilateral triangle, each 25 yards distance. Point A has the tank and melee DPS. Point B has the ranged DPS. Point C has the healer(s). If a melee DPS gains aggro on a mob, only that one character is in danger (and, frankly, deserves it for not watching his threat level). Even if a ranged DPS gains aggro, the healer still remains far away from danger. It also helps [us humans] see if a mob is aggroing towards the healer (red alert) or just towards a DPS (... meh, he probably deserved it - assuming the tank's doing his job). A bit of a lengthy explanation but hopefully that should be all clear now. On to what you reminded me of, I wonder how difficult it would be to have assist-tanks or assist-healers. A DPS paladin or DPS feral druid who aggro's single mobs that escape the main tank's aggro. A moonkin druid or shadowpriest that heals when the party is in a tough spot. I imagine those would be a few quite difficult algorithms. I barely raided myself. But the raid icons are available in a party and are quite useful, I've found. As for shuffling threat (I think we misunderstood each other there), there is no doubt that aggro should always be held by a tank, if possible. The only reason I recall to not have a tank pull in an instance is because the tank was a paladin back when their highest range spell/skill was a paltry 20yards. Well, that and silly reasons like player impatience You're joking right? If anything I should be thanking you. So thanks yourself.

Hmm... Patched the new-ai branch into the latest mangos and SD2, and now all mobs are yellow (passive aggro) and I can't aggro any of them - but my pet and my bots can. Anyway, noone's reported this for a week so I probably just did something wrong. What I'm really posting for is to suggest an additional feature: a 'pull' command. This would mostly be used by tanks, I suspect, but people can be surprisingly creative sometimes so I suggest you don't limit it as such. First the bot commanded to pull does a ranged attack. Wand, throwing knives, (cross)bow/gun - if ammo, spells, ... You can be creative here - prioritizing high threat spells if in tank mode, prioritizing long cast times if the mob hasn't been aggro'd yet, ... At this point do some sort of check whether the target remains stationary (may be difficult - some mobs it's better to wait out an initial spellcast because they actually are melee and will soon come in range - but this would be tweaking). If yes - remains stationary - rescind pull command and issue attack command to party (and of course don't do the next steps) Next all bots in the party/raid act as though the stay command was issued. Finally, once the mob comes close issue attack command to party/raid There are several ways to improve on this as well. You could have a pullmax command, where the ordered bot would first move to just below the maximum range, lining up the other bots in an appropriate formation and appropriate distance away. Other melees would stand to the left and right, ranged would be a distance away left and right and the healer would be distanced on its own (because unless I'm mistaken this is best: the further away, the less threat is generated, so this would be just in case a ranged aggroes a mob). I can see this would be a lot of work though. You could also have the bots obey some rules based on raid targets. I'm sure experiences will vary, but for every party/raid i've been in the following held true (and as an example): Skull marks first target, X marks secondary (as in switch to after skull, and/or secondary tank), moon and diamond are crowd control targets. I have a few more ideas but I won't throw them out there without putting some work into them myself. Anyway these are only suggestions, take or leave them.

Versions (All newest from yesterday): Core r11549 ScriptDev2 r2134 ACID 3.0.8 UDB 401 Playerbot AHBot Noticed a problem yesterday: Auctions were added, but when looking at the AH in-game, virtually none would show. Once I saw 7 horde auctions (out of 8500), 1/8500 alliance, 0/2200 neutral. Removed all auctions, restarted server, saw 0/8500 horde auctions, 1/8500 alliance auctions, 0/2200 neutral auctions. After quite a bit of searching, I found all player-added auctions had moneyTime of 0, whereas barely any (8 first time, 1 second time, correspending with viewable-in-game auctions) of AHBot's auctions had moneyTime of 0. Setting all auctions to moneyTime of 0 (and rebooting server to reload auctions from database) showed all auctions in-game. Fix (keep in mind my line numbers are after PlayerBot and AHBot patches): // AuctionHouseBot.cpp // function (line 1257 here): void AHB_Seller::addNewAuctions(AHB_Seller_Config& config) // line 1335: auctionEntry->bid = 0; auctionEntry->deposit = 0; auctionEntry->expireTime = (time_t) (urand(config.GetMinTime(), config.GetMaxTime()) * 60 * 60 + time(NULL)); + auctionEntry->moneyDeliveryTime = 0; auctionEntry->auctionHouseEntry = ahEntry; item->SaveToDB(); sAuctionMgr.AddAItem(item); Also, ahbot.conf.dist.in contains a typo. Checked the config loading code which does not expect this typo (so it ignores this setting and defaults to 10, max) AuctionHouseBot.Class.Reciepe = 6 // should be AuctionHouseBot.Class.Recipe = 6