kennumen

Although personally I wouldn't go any further than all gray items, white armor/weapons of which you're wearing green or better, and perhaps under-levelled food (e.g. level 5 food when you're level 15+). Beyond this it's not easy to decide what may or may not be useful...

I lol'ed So glad I'm not the only one... As lazy as I am and as much as I'd like to tell you to take my advice and go google it (after my [sarcasm]brilliant[/sarcasm] speech on theorycrafting), I really can't after all your work. You, sir, have shamed me into not being lazy for just a moment... http://www.google.be/search?q=wow+weight+stats+3.3.5 A good place to start for which stats to focus on. http://www.wowhead.com/forums&topic=100050/warlock-faq--current-for-3-3-5 One example, in this case for a warlock, which brings us to... http://www.wowhead.com/forums&topic=100050 Being a warlock fan I can't say i agree 100% (and what's worse, there's no actual weighting as in "+spell is worth 2.4 stamina") but for a bot it should do just fine. Keep in mind with that page you will need to add your own weighting. It may tell you spell>sta, but if you equip a +1 spell equipment over say a +100 stamina equipment... You'll be having people after you with torches and pitchforks. So it's a good start but you'll need to mix in some common sense. Also, as far as this page goes, levelling = pve level 1-79; pve = level 80. For the warlock it works out that levelling gear is good enough for 1-79 pvp as well, and this page's listed pvp really means pvp level 80. http://www.google.com/search?q=simulationcraft+3.3.5 Finally the page mentions simulation craft, the old version is a bit tricky to find so here you go. There's also numerous mentions of RAWR everywhere (including some of the older pages in this topic) so perhaps that's worth looking into for class+talentspec+purpose weighting.

... Yes and no. Statically speaking it's easy to figure out which item is best for a given class + talent spec. Dynamically speaking it would be difficult to factor in future set items (i.e. this item is slightly worse but a likely future set would significantly boost this one item - you just don't have the other set item(s) yet), or also to use a slightly worse but more focused item (say +50 hit) over a better, more spread item (say +30hit, +30crit) because another item's upgrade might 'cap' (wow has a maximum for statistics, where any extra stats are useless - in this example, we'd be trying to foresee a +crit cap). There are people on the WoW forums who do nothing but theorycraft, figuring out the best combination of equipment, stats, cap limits, etc... The big problem is finding this data for WoW 3.3.5a. A lot of what I mention above is applicable to level 80s, but there are sub-80s hierarchies of stats as well - sub-80 and 80 are slightly different, as I recall +hit is more or less ignored sub-80, and so on. Good job finding an actual example. Another one might be a warrior using a +70 spirit item over a +20 sta, +30 str one. But like you said, autoequip is still in its infancy as far as ideal selection goes - itemlevel is the best attribute when using only one and a great starting point. I, like you, have no doubt Gitch realizes this imperfection and will soon get to work on it Blueboy does make a solid point that for weapons, DPS is more or less the main attribute for melee characters. (... although in some situations speed is also very significant - slow (high) = better for pvp; pve rogues with the right talent spec would seek out the fastest weapons if they depend on per-hit triggers). Yeh, it's anything but simple. Seriously, we could really use some archived 3.3.5 theorycrafting

Nice! But if you were to use any one attribute for a simplified test version (aside from armor class and can_i_equip_this (level, weapon, ...)) why not check for the item level (note: i'm not talking about level requirement which as a variable is probably named very similar)? If I'm not mistaken, blizzard even made this value for simple item comparison. It's not a final solution but it should be the best available from any one variable. Of course you've already indicated this will never work properly without a per-class detailed evaluation (note: is 'gearscore' useful for this or not?). As for optionals, I would hope for a config file setting (server-wide disable) and a per-bot setting which (for obvious reasons) defaults to 'off' upon login. Great job though. This was fairly high on my list of 'coolness'

Good job on that fix. They're supposed to, to increase chances the bots are standing next to you (not off looting 200 yards away) when you wish to enter combat. As for commits / branches, I'll let blueboy handle that, but don't be afraid to post code even (potentially) broken code. It's why we have branches...

FYI, a great website for info on pets is petopia. It has been updated for cataclysm but most of the pet stuff hasn't changed (aside from a few extra pet families and starter pets). I also found the following while browsing so my previous suggestion (pet stay + character running out of range - instead of dismissal) still stands, assuming the core supports it: <edit> Keep in mind, of course, that tamed pets are at most 5 levels below the player. </edit>

Sorry, I was not referring to temporary dismissal of the pet, but permanently abandoning the pet. You won't be able to tame a new pet until you either stable the old one or get rid of it. The 'dismiss pet' spell won't do. I know my son loves to acquire a more and more exotic pet and this patch was for him. I would be interested if someone with an 'Uber' hunter bot could test whether it can tame exotic pets. I have a feeling that a more advanced taming spell will be required. Cheers There are two ways to get [temporarily] get rid of a pet - you can dismiss it or you can command it to 'stay' and then run a certain distance (it might be 40 yards, probably a bit more). If you dismiss it you receive (or did) a penalty to the pets happiness so common practice was to simply have it stay and run away from it to get rid of it. On vanilla this worked to get rid of the 'temporary' pets from these quests but just tried it (with UDB and as self, not a bot) and no-go. If you run out of range you do lose control over the pet but it doesn't disappear... Must be a core issue. <edit> woops, spent too much time testing I forgot: As for exotic pets they're just the same as regular ones with the sole exception that you need a talent to be able to tame them: Beast Mastery -> Beast Mastery (the talent is somewhat confusingly named the same)</edit>

Order the hunter's pet to stay, run out of range. Unlike a regular pet you will not be able to recall those pets but then that's half the point. No hunter worth his salt ever uses the 'dismiss pet' spell anyway, on account of it lowering the pets happiness. Another helpful little nugget: Cast 'aspect of the monkey' before taming a beast. 8% dodge can actually mean the difference between a tamed beast and certain death... But wow... nice work, blueboy

Already created by BThallid: try the sharedbots branch: https://github.com/blueboy/portal/tree/sharedbots

Just to be a PITA and rub it in, I told you this 2.5 months ago Anyway, glad the list is getting shorter, and great job as always And props to Gitch for his much clearer description of the issue.

Concerning skill learn [skill]: Server: OS: Win XP SP3 32bit IDE: VS2010 SP1 mangos: various (including clean playerbot, new-ai, talentspecs, combination of those with or without latest core + mmaps) db: UDB 0.12.2.401 / 402 I really should test ytDB for this like I've been meaning to... I don't actually use breakpoints in mangos (as my compile machine is not my server), but I recall from years ago the directory structure (of the Run/Debug command) is rather funky. Something about putting the data files a folder up from their normal relative location.

Looks good. I'm not completely sure what a worldsession is (and it doesn't help that MaNGOS english cannot be counted on to be descriptive) but near as I can tell is it's an account's life-cycle upon login. You can't create a player without it. Although I probably shouldn't try explaining it - this is the part that's tripping me up with autobot development. In addition, am I supposed to debug the code only by examining logs? I tried debugging directly in VS2010 and it told me it couldn't open program 'game.lib'. Can I debug it line by line using break points? This is actually not a new issue. Someone reported it, I confirmed it, blueboy could not reproduce the bug (which I can also confirm), and was later brought up by a few more people. You are, however, the first to provide us with logs and a crash dump. Oh, by the way, which database are you using? As for VS2010 debugging, it's not always helpful (and I'm sure blueboy's linux debugging tool is superior), but I get a stack trace when I debug with VS2010, resulting in about 2/3 chance it leads me back to the offending function. Breakpoints could help, assuming you know where to look, allowing you to see the server state before the crash.

This is the reasoning behind why I suggested the rotation command being added as a playerbot feature. It would allow players to choose a bot's best spells, based on the bot's talent spec, or establish custom rotations for boss fights. Rehash of an old discussion; I still remain that any *optimal* rotation can and should be set by playerbot itself, recognizing which are its best spells, and picking a rotation based on the situation (regular, specific boss, ...). There is one perfect answer given a set of spells, and instead of expecting all players to figure it out and then enter it using spellIDs... I've mentioned above that there is one perfect rotation given a bot and situation. If you still wish to add custom rotations, are you implying players might want suboptimal rotations (just for plain taste, or disagreement over what the perfect rotation is)? Or do you believe finding this perfect rotation is so difficult we should have a rotation command in the meanwhile, not only to hotfix suboptimal rotations, but also as a testing bed for getting nearer that perfect rotation? -- No sarcasm, I genuinely wish to know. Have you checked if it's set to cast spells in the rotation? The priest used to go melee, perhaps there's a clue there.

Nice work! You can really expect a player to conform to a 'set' talent spec. Even with an 'ideal' talent spec it's often tweaked to taste, so it's generally better to check for single spells and ignore the passive talents, at least to start out with. Yo. Autobots are a bit stalled (unfortunately I'm unable to dazzle you with a hidden behind-the-scenes major update) as I'm struggling with creating a session (or rather, another session?). Once that's done things should fall into place somewhat quickly. I've set myself a deadline to get them working properly (including items, etc) by mid-february. It's tight but let's hope I make it. I don't see any reason why mmaps would fail to merge with autobots (as long as mmaps merges fine with playerbot, that is). As for the current state of autobots, they do in a very limited way 'go online' but they're not actually added to the world. Just new characters are created and then set to online in the database, which is why they cannot (yet) be invited.

to enter the spells used for when the bot is set to aggressive mode. Of course the flags could be abbreviated, aggressive = a, defensive = d, and passive = p. I like this, in theory. Of course, defensive (with the connotations to pets) could probably be worded better. But in practice I see problems. First there's more or less one 'ideal' rotation. So once it's that ideal a player could only worsen it - and if he does improve it, it merits inclusion in Playerbot. Personally I use bots with classes I haven't and probably don't want to play, so finding that rotation would require quite a bit of research. Per bot. After that, I'd have to look up all of the appropriate spellIDs. Per bot. I'm all for customization but it seems this should be automated, using a system based on combat orders and talents. Which, trust me, is not any one person's fault. Don't be sorry. Instead, pat yourself on the back for trying. Something people tend to forget all too easily - we all start out as newbies. In a series of IF/ELSEs (which, if it's not entirely, this should be), you (... generally) want the most restrictive clauses at the top. For example: As for having a Retri paladin heal, isn't that what combat orders are for? You could still have an ideal healing rotation based on his (mostly) retri talents though. For example. Nope, conditionals inside an IF clause, while using AND (&&) are only evaluated while the previous clause is true. HEROIC_STRIKE > 0 -> true, continue -> false, skip the rest of this IF clause I haven't realy worked with warriors (except for a small fix) so don't expect me to be an expert but that code looks solid. The only hickup I found was looking up the GetRageAmount() code: I'm reading that correctly, right? It calls a function, gets a uint32, casts it to a float and then casts it to a uint8? Messed up as that is, it's not gonna change values <= 110 (or however high rage can go). Make sure you're running your latest code, and (unless someone else finds an error) then proceed to mess with your code.

Hmm... pastebin's a lot worse than I remember (course it beats the code tag hands down as it stands). The reason your heroic strike is never called is because it's at the end of a long list of IFs, which I think are somewhat broken - it should really only try one action per CASE. Either an IF should come with a break or be followed by an else-if. I imagine the server catches the bot trying to do 5 spells in 5 milliseconds and only does the first, so functionally it's OK but it's messy nonetheless. Anyway, move your heroic strike to/near the front of the CASE and you'll have more luck. You want it to always be called when you have 80+ rage, as it stands it's only called if you have 80+ rage AND all the IF's before it are false. As for counting the talents per tree, it appears (after a quick glance) this code does not exist. If you're up for it, check out GetTalents() in Player.h/cpp and ApplyActiveTalentSpec() in PlayerbotAI.h/cpp for some good clues. These function(s) should of course go in PlayerbotAI.h/cpp because all classes would use them - just use a generic tree 0/1/2 and have the ones calling this function figure out that 0 = arcane, 1 = frost, 2 = fire (for example).

Just automate it based on which talent tree has the most talents. Keep the user (and more complicated orders) out of it <edit> to be clear, I would base this on actual talents, not on the playerbot's talent spec settings. talent spec is in no way a required command, after all. Plus it's better to base it on actual talents than on 'supposedly future' talents.</edit>

This could use some clever party-based calculations. For example, once the (healer / party.size) ratio <= 25% (as in, once there are 1 healer per 4 party members, or less), healers only heal. Blueboy made a good point (that I share): playerbot is used by various people and while I with my 5man party may wish my healer only healed, someone else with a 2man party may curse a healer for not DPSing (and then curse it for not healing when it goes OOM). I haven't read all the classes code but in general health is % based, and mana is % based BUT (very broken) % of base mana (before item bonuses and such). If I'm not mistaken. Very clever solution and I'll commend you for it even if I don't want to use it myself. Personally I'd rather see this coded properly without a workaround. Until it is, of course (and perhaps after) this should be a relatively simple solution.

Frankly I don't much like this idea. It's basically cheating, and actually quite unnecessary. Skip the quests with item collection, do the ones with kills (which go by superfast), and beyond that go instancing. In fact, according to Dugis, even with moderate waiting times to find a party (which, with playerbot, should be zero), the fastest way to level by quite a margin is instancing. This is a bug reported and confirmed a while back but could not be reproduced on either of blueboys servers (WinXP and Linux). We never did figure out what was causing it. Might I ask though, are you using UDB or YTDB (or something else) for your database? <edit> and yes those quests drive me insane as well, but I do them nonetheless (who else wants the Loremaster achievement? ) That's even a moderately easy one - random drops on mobs are the worst. How come only every 10th troll has a single ear? How do these mobs hear me coming a mile away? </edit>

That part, at least, is working as intended Bots are meant to act intelligently, rolling greed and need as applicable. blueboy recently made some good, much-needed improvements in this area. You can, of course, trade with the bots and take the items back from them, or in reverse using them as item mules. <edit> quote added for clarity </edit>

I wouldn't dream of it. The code is perfectly portable, although anything glyph related can be ripped out for clarity... Or left in for better patch compatibility. Of course all the enums are incorrect (talent Ids) for Zero, as are all talent builds. Redoing all this data will be a lot of work, assuming the correct data is already out there. I also described how to do it quite a few posts back, so... "not it" You can also shrink the DB table; As above, shrink = clarity, as is = better patch compat. Once the enums have been added, don't forget to update all the places they're used - IIRC this is only for error-checking purposes. Talentspecs are only polish, not crucial in any way, so I'm not sure it's worth the time to port it. But if anyone's looking to learn, it's a fairly simple addition so if blueboy decides not to do it (and it's highly unlikely I will), this would be a good project to start with. Beware there will be a lot of manual labor <edit> Oh, to be clear, 1.12 did have talents, but others and the tree wasn't as deep. Instead of 20/51/0 now (for example) it might've been 20/31/0 back then. Talents have been removed/added/renamed/etc since then. There were no glyphs at that point (which is part of the talent spec in playerbot, but not linked to any functionality yet). Obviously there was no Death Knight class either. Alliance did not have Shamans, and Horde did not have Paladins, but since you're only ever shown your own classes talentspec that doesn't really change anything. </edit>

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. 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. Nice.

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.

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)

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 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 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. Your adulations continue to humble me. 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.