kennumen

Correct, for your purposes you want to set thee rate.rest values (all 3 of them) to 320. This is a float value, it's value is not capped to a minimum or maximum anywhere. If that doesn't work, try modifying the rate.xp values to 2, basically the same thing. Also make sure you're editing the mangosd.conf file in your mangos directory and not mangosd.conf.dist.in or anything like that.

It's been a week, time for an update (even if I am, technically, triple-posting). Community has been quiet so my motivation hasn't been as high, but work has continued. I'm coming up on 3 months development which is generally when my interest in a project goes out all-together, but let's see how far I get with AutoBot before shouting doomsday messages Coding for master has been tweaks and bugfixes only, rest of work was on AutoBot. Updated wishlist - almost none of this is on my 'todo soon' list so if you're feeling the coding bug, have at it. [feature] [tweaking] [bug] [feature] Auto-Equip: Start out simple - auto-equip white and gray items with greater armor values than already-equiped whites and grays. Expand this function as we go. Didn't 3.3.5a come with gear score? Think I saw mention of it in the LFG mod. This would make expanding this feature easier, methinks. [feature] Auto drop excess quest items: Automatically drop excess quest items. Could do this after a quest turn-in, or better yet right after looting (objective: 9 of 8 items should be a hint). Might as well include BoP items that start a quest that's already turned in (like that robot head in Tanaris). [feature] Auto drop trash items on full inventory: Drop grays, underleveled food/drink, even 'obvious' whites if bags are full and a quest/desirable item comes along. [feature] Pull command: Tank pulls (furthest ranged attack) a mob, the entire party waits 2 seconds (for the mob to approach you, not other way around) before attacking. To be tweaked once proof-of-concept is out. [feature] AutoBots [kennumen - but feel free to pitch in]: independent bots. Create a bot at any level, properly geared and talented for it's purpose, with significant autonomy and limited obedience, allegiance. Current purposes in mind: battlegrounds (both team-mates and enemies - automatic for BG queuing), arenas (opposing teams only), instancing and raids (automatic for LFG queuing), world-quests. Blueboy suggested this 'creating' of bots should come with a (gold) cost, I'm divided on the issue. There would be ways around this, a disconnect would make people feel cheated, ... Perhaps a playerbot.conf setting? [feature] PvP mode for bots: does it exist? I've seen mention of dueling and some ground work here and there in the code, but I can't really test it (well that's not entirely true. Two accounts with 9 alts each would fill WSG and be enough to start an AB the other 15man BGs... but that's a lot of work to test something that may not exist). Reckong this would only be really interesting <for most people> once Autobots exist. [feature] Auto-protect healer: instead of everyone (because I am everyone) forgetting to ".bot co <name> protect <healer_name>", do this automagically. No reason I know of to have the healer hold aggro. Ever. [feature] Professions: List actual professions (like the 'link' button does for your <non-gathering> professions; with skill level, recipes etc) instead of just a link to the spell. [tweaking] Help for .bot command: To finish off the in-game help. [tweaking] Quest completion notification: I don't really want to spam '/p quest' and '/p quest report' macros that much. Why can't bots tell me when they've completed a quest? [tweaking] [optional] increased speed for bots during looting outside of combat: Optional as in a (server) setting in playerbot.conf. [bug] Need or Greed?: Bots need far too much. First clue was *everyone* needing Tigerseye. One bot had leatherworking, so arguably he had the right (although it's still bad etiquette). Only reason for bots to ninja is if the humans in the party ninja, and that's really a non-issue for AltBots. [bug] Human player ('master') healed as ghost: I noticed my bots were trying to heal me when I was a ghost. Waste of mana besides looking... well, not good. Also, perhaps, when the master is dead and bots are as well, the bots should only revive if and when the master does? [bug] Druid: When a tank is present, [Thorns] should only be cast on the tank. For the other party members it causes undesired aggro. Also, a balance druid keeps using catform. Not cool. [bug] Skill learn: Crashes my server. Works great for blueboy. Too lazy to figure it out and will only get less annoying as my bots level. ... But still irks me, so this bug will die someday, as a matter of principle if nothing else. [bug] Collect bug: Sometimes collection of a corpse does not happen. To reproduce bug: take a class with a ranged instant attack (lock's corruption, druid's moonfire, ...). Kill a mob far away from you. Mob dies, bots come to you. Bots start moving to corpse to loot, you aggro another mob. First corpse is removed from lootlist and never gets looted (unless manual intervention with /target corpse -> "get"). [bug] Target Unreachable: Had a mob in the sky. Bots couldn't reach but spazzed beneath mob trying to reach it ad infinitum. [bug] Skinning bug: Skinning does not happen if the target isn't empty on the first try. Tough to fix though. Tough but not impossible. [bug] Shaman bug: Shaman uses totems without the actual 'totem tool's. Was grouped with a new shaman (level 2 or 4 or so). The shaman was using earth bind totem, which requires an Earth Totem, which was not in the bot's inventory. Very low on my wishlist, if I even want this fixed at all... But right is right. [bug] Follow-up quest, bots claim "already completed": In Mulgore, did "The Ravaged Caravan". Turned in, got the same-named follow-up, bots proclaim they already completed it. ... But they accepted it fine, so low-priority. [bug] Mining / herbalism is flawed. Mining sometimes does not collect, Herbalism appears to never collect (both work fine when told manually using survey/get).

Did you put SD2 inside "[core/]src/bindings/[scriptDev2/...]"?

Not sure where to put this, this topic may not be the best place but at least the information's out there. What you will have by the end: 1) Name, at most 254 letters. 2) Class, values -128 to 127. 3) Purpose, up to 32 flags telling playerbot what this talentspec is best used for 4) (up to) 71 talents. 5) (up to) 3 major glyphs 6) (up to) 3 minor glyphs Creating your own talentspec: 1) Get a talent spec from a talent calculator (or other source) 2) Convert the talent names to talent IDs - using talent.dbc on wiki and/or the talent enums from src/game/playerbot/PlayerbotAI.h: By now you should have 1 to 71 talents, seperate these with a comma ','. If less than 71, put your talents at the front and fill the rest with 0. Good: 11, 1171, 8899, 0, 0, ... Bad: 0, 11, ... Bad: 11, 41, 0, 88, ... 3) Do the same for your 3 major glyphs (using enums and/or GlyphProperties.dbc on the wiki). 4) Do the same for your 3 minor glyphs 5) Purpose(s): See "PlayerbotAI.h" enum TalentSpecPurpose. Please combine hex manually. E.g. 0x00000008 & 0x00000004 & 0x00000020 = 0x0000002C 6) Class Id: See "SharedDefines.h" enum Classes for characters and "PlayerbotAI.h" enum ClassesCombatPets for pets. 7) Build Name: Any string of text NOT containing quote "'". Also recommend against semicolon ';' double quote '"' or new lines. Purely informational for developers and manual talent spec selection. 8.) Time to put everything together: Special note: All lines must end with a comma ',' except the last line which must end with a semicolon ';'. 9) Test your new SQL file by inserting it into your database. Fix errors if any (... duh). 10) Test your new talentspec in-game (must be done with a GM account or higher): Again, must be done with a GM account (or higher) in GM-mode (.gm on). Fix errors (if any). Be sure to re-check - talent spec errorcheck only displays the first error it finds. There you go, your very own talentspec. Please share it here with the community. On a sidenote, I've done a little work on AutoBots. Gotten 100k names, english-sounding (or at least pronouncable), 4-12 characters each, letters a-z, no 3 consecutive letters the same. AFAIK that conforms to Blizzard/MaNGOS character naming rules. And of course they are all unique (no duplicates). It would be unwise to generate them in-game as the first 1k names generated only took 2 seconds, but once you have 50k names it takes 1.5 seconds per name to generate, increasing the more names you have. So if you had a popular server with 2k active players, meaning roughly 10k players including offlines, equaling perhaps 40k characters... Just the name generation would lock the server (or a thread, at least) for 1,5 seconds... That would be unacceptable. 100k names should be enough to ensure that no matter what you should be able to have an unused unique name no matter the circumstances, as well as provide some diversity ("Ugh, 'Generictank' again???"). The current structure allows for names to be defined for specific race (because "Beefcake" just works best for a Tauren), classes (Tankadin would be a silly name for a mage), genders (blueboy is pretty exclusively male, methinks), purposes (tank/dps/healer, pvp/pve - because Toughtank works best for tanks... unless you're PVPing), as well as a priority flag - priority names would be picked above all others. I'll generate a newer version overnight when I'm less annoyed by how slow my PC is running (4 hours... and I just made the process more thorough -> slower). Feel free to let me know how you like them. Unless you don't. If you hate them, feel free to stay quiet <edit> new version is up. Check the sql in the autobot branch if you're interested.</edit>

Yes and no. What I've got in mind is less than that - but a good first step towards what you're thinking of. What I have in mind is temporary bots. You're waiting too long in LFG, the server fills your slots with an autobot that does its purpose and barely listens to you. Doesn't trade with you, takes fair amount of Need rolls (unless you Ninja, hopefully it will adapt to that). Once your instance is done the bot will disappear. (This could be tweaked later to keep instancing, but this particular bot would only be doing instance runs) Another purpose would be for BGs. You're in the BG queue too long so the game fills the empty slots (both alliance and horde) with autobots. These bots are there for the duration of the BG, and disappear afterwards. Yet another purpose would be to populate empty zones. You enter Silithus, it was previously empty. The server creates a PvPing bot and a few farming bots. The farming bots don't really do anything (perhaps they answer a /invite, who knows), but they make the server feel less empty. Once the last human player disappears from Silithus, those AutoBots automatically vanish. I wasn't planning on populating the auction house though. Isn't that what AHBot is for? Anyway for now I can't start on AutoBot because I'm unsure how to implement it. We're basically creating players (controlled by a bot system rather than a WoW client, but players still), which will need a name (rest can be auto-generated and, more importantly, does not need to be unique). See above for full explanation. Anyway, yes. With the above addendums.

I will use 'sell' for now (had an inkling it might, and recently noticed the 'sell' command works if any NPC is in the same zone, but hadn't connected the two). Still, it feels an awful lot like cheating. I still want a 'drop item' command (or whatever its name will be). I'm not sure which meaning you have in mind. If this is the need vs greed (vs pass) rolls, then /agree. If you mean not looting excess quest items, /disagree. They should loot everything, always (if configured that way, anyway), and drop what they don't need or want. This way there's no problem with items left in skinnable corpses. Does asking help? Well, whatever. The more the merrier. I'm on a roll now but who knows when I'll burn out <edit> I feel I've got too many double posts already, so here's an edit: I would really like a discussion about AutoBots. 1. Do we create actual characters in the database, track those somewhere, etc? This would also need an actual account in the database, etc. It seems pretty intrusive database-wise, and high maintenance. On the other hand we can keep it all-memory. The methods in Player.cpp (or wherever) get linked to memory for autobots, instead of the database. It's slightly more complicated code-wise but infinitely cleaner DB-wise. The biggest problem I see is keeping these character names 'in use' while the bot is alive (imagine someone creating a character named after an active autobot). This would probably have my preference, perhaps someone has a better idea though. 2. Aside from everything else, bots need names. Since there is no human creating these bots, ... Actually there may be. So the way I see it we have 3 options: - We have the user input it (and validate it's not in use yet) - not always an option, like enemies in arena/bg. Auto-filled AutoBots for LFG, etc. - We take it from a static table (but what if we have a table of 300 names, 100 of which are already in use by existing characters, and we need 500 AutoBots?) - We (semi?-) randomly create names. Will these need to be valid? Or can we say create a character named "123"?

Greetings fellow inhabitants of Azeroth. Some of you may have noticed the new 'help' command, which brings the bot readme into the game. This should help keep you immersed in the game, and to that end I tried to make this command seem as though the bot (rather than an impersonal readme) is explaining things to you. The help command was the result of some 6 hours of play testing last week. Having to tab out of the game wasn't the only thing that annoyed me, and I'd like to share what else is on my wish list: Help for .bot command: To finish off the in-game help. Colored text: Use colored text to make things more clear. Like the 'command' part of the help, for example. [em]Other parts may still benefit from colored text but I'm satisfied with this wish.[/em] Quest completion notification: I don't want to spam a '/p quest' macro. Why can't bots tell me when they've completed a quest? Auto-Equip: Start out simple - auto-equip white and gray items with greater armor values than already-equiped whites and grays. Expand this function as we go. Didn't 3.3.5a come with gear score? Think I saw mention of it in the LFG mod. This would make expanding this feature easy, methinks. Drop item command: full inventory? Need space for that quest item or a more valuable item? It's time for a 'item drop' command! - see 'help drop'. Auto drop excess quest items: Extension of the wish above, automatically drop excess quest items. Could do this after a quest turn-in, or better yet right after looting (objective: 9 of 8 items should be a hint). Might as well include BoP items that start a quest that's already turned in (like that robot head in Tanaris). Quest subcommands: complete / incomplete, lists only (in)complete quests upon status request. Not quite as useful once 'quest completion notification' (see above) is implemented, but could still be useful in some situations to cut down on chat 'spam'. [optional] increased speed for bots during looting outside of combat: Optional as in a (server) setting in playerbot.conf. Need or Greed?: Bots need far too much. First clue was *everyone* needing Tigerseye. One bot had leatherworking, so arguably he had the right (although it's still bad etiquette). Only reason for bots to ninja is if the humans in the party ninja, and that's really a non-issue for AltBots. Pull command: Tank pulls (furthest ranged attack) a mob, the entire party waits 2 seconds (for the mob to approach you, not other way around) before attacking. To be tweaked once proof-of-concept is out. Human player ('master') healed as ghost: I noticed my bots were trying to heal me when I was a ghost. Waste of mana besides looking... well, not good. Also, perhaps, when the master is dead and bots are as well, the bots should only revive if and when the master does? Druid tweaking: When a tank is present, [Thorns] should only be cast on the tank. For the other party members it causes undesired aggro. Also, a balance druid keeps using catform. Not cool. Skill learn: blueboy's server may do it properly, both my servers still keep crashing no matter what I try. Only other things I can think of is ScriptDev2 wasn't running for him, and he had ytdb instead of UDB. If those don't tell me what's broken, this bug could live for a long, long time. AutoBots: let's not forget AutoBots, independent bots. Create a bot at any level, properly geared and talented for it's purpose, with significant autonomy and limited obedience, allegiance. Current purposes in mind: battlegrounds (both team-mates and enemies - automatic for BG queuing), arenas (opposing teams only), instancing and raids (automatic for LFG queuing), world-quests. Blueboy suggested this 'creating' of bots should come with a (gold) cost, I'm divided on the issue. There would be ways around this, a disconnect would make people feel cheated, ... Perhaps a playerbot.conf setting? PvP mode for bots: does it exist? I've seen mention of dueling and some ground work here and there in the code, but I can't really test it (well that's not entirely true. Two accounts with 9 alts each would fill WSG and be enough to start an AB the other 15man BGs... but that's a lot of work to test something that may not exist). Reckong this would only be really interesting <for most people> once Autobots exist. Feel free to add to the list, share your own, work on these points yourself. If you do find yourself working on my wish list (and I'm not saying don't, in fact, please do) I would appreciate a heads up so we don't both work on the same thing.

Hey, I started with my UD warlock. The rest teleported to me. Much to my surprise they didn't pick up the first quest, nor any of the others in the UD starting area (although after the first 3 quests they would be either missing pre-req quests or just plain underlevelled). Leaving the UD starting area I was on track at level 6 (although while doing this alone I have been 7 coming out of this), but my team-mates were level 4, I believe (or perhaps 3). At this point I went to undercity (passing Brill for my own trainer), to use the teleporter there to get to Silvermoon City. Here I would scratch my head as to why "skill train" listed no skills, but figured I'd do it manually since having never seen it in action I figured I just did it wrong and was unable to figure it out. I wanted to do another starting area since we were supposed to be level 6. Plus reputation discounts are always nice. Since the BE starting area (up to 'level 6' at least) contains mostly BE-race only quests, the viable options were orc/troll starting area or tauren. Having a Tauren, my preference went here. At this point various little things were beginning to annoy me so I cheated and used ".tele Mulgore". At this same moment I started using ".modify speed 2" for regular play and ".modify speed 6" for travel, on the entire party. Bots aren't made to ignore aggro (for 'travel' mode), but then I also wasn't playing as intended. Coming out of the first Tauren starting area we were all level 6 (myself at level 7). At this point I found the "skill learn" crash. While testing I relied on .tele to go to the other trainers, but did so both before and after ".bot add". A ".tele" before ".bot add" should have 0 effect on it. I also made sure to test once without ".modify speed" (of course with the trainer furthest away). As for Death Knight testing, first it was with two DKs, next I added my level 1 warrior (a secondary 'master' to ensure it's not my lock's fault) as a bot, who then was teleported (as a bot, so technically summoned) up to the ebon hold, and proceeded to continue testing with him. In different circumstances I would commute every 4 levels (they come so fast anyway and it is quite far), but seeing as I'm doing solo quests with a 5man team I would just ignore the paladins until the end of Mulgore (or until I die). And while I'm posting anyway, did a few commits to master. Revamped selling output, now it's much more concise yet still comprehensive. If you really want to know which grays were sold exactly, let me know and I'll add it to the config. Knowing has absolutely no practical use though. Also changed some things behind the scenes to make it easier to program for PlayerbotAI as far as processing player commands goes - but nothing regular users would notice. Laid the ground work for a 'help' command so I don't have to keep the readme open. Will hopefully finish that today as well as some more background work.

Did the same - UD Warlock (me), 3 BE paladins, 1 Tauren druid, manually levelled to 4, all spells gotten manually. Levelled to 6, started testing. The other classes I just used .level for the first 3 then just tried with level 1s who apparently already have 1 or 2 spells to learn; None of this appeared to have any effect on testing. It went to waiting on the server to re-re-reboot that's where I don't think I've ever cleared caches, unless perhaps something hinky was going on after a client patch. Still, worth a shot, but no effect. Alas. Good. Merged, removed talentspec branch. Now that's one less to maintain First thing I tried. Got something along the lines of "not a quest", probably. Anyway, I like polish, taking it easy. Not having to logout, interrupting my gaming session. Arguably, having to command a bot interrupts it anyway, but it's much less intrusive than seeing the wow world disappear for a bit, only to show up as someone else. Anyway, if you don't feel it's worthwhile, it's up to me. It's certainly made my shortlist You'll thank me later

I for one am glad someone's verified the bug. Keeps me from doubting myself. Also, blueboy, sneaky sneaky editing your post. Almost missed it. Nope, it crashes on [Wrath] as well. The tauren in question had learned the previous skills manually. Also, not just Gennia Runetotem. I visited Thunder Bluff to be certain, still crashes. Well you are sure now. Also I have a habit to type extra spaces, but made sure to type without as well. Meaning: I type "/w drood skill learn " then shift+click, making the input "learn{space}{space}[link]". But as I said, I made sure to try with just one space. Identical results. All tested on WinXP SP3 (32 bit). [1] Release: [MaNGOS] 11831_02 with mmaps, playerbotai, loot-fix-bt, talentspec [2] Release: [MaNGOS] 11831_02 with playerbotai (straight clone from master branch) [3] Debug: [MaNGOS] 11831_02 with playerbotai (straight clone from master branch) [sD2] 2319 [ACID] 3.0.9 [DB] UDB 402 [Addon] ... *sigh* seriously? A list of at least 50 (148 folders). Also tested disabling them all (for the master branch versions), no difference. Running the debug version does grant some more information: Also, none of my 3 paladins can get their skills listed (let alone crash the server by trying to learn). "skill train" command returns an empty list of skills, when two paladins have 2 skills to learn and one I bumped to level 10 but still no skills (when there should be at least 10). So I decided to test the other classes (create, .bot add, /invite, .level 10, .modify money 10000, skill train, skill learn [skill link]): Warrior, hunter, rogue, priest, shaman, mage, warlock crash the server. I tried first skill, last skill, one and only skill, single skill, multiple skills, different masters, different trainers, short character names, long character names, (in)ability to afford all skills, ... No dice. Death knight actually does learn, no problem. Tried levelling, different race, different class (as human controller) but couldn't seem to break it. Paladins don't crash the server but that's because "skill train" doesn't list anything, so "skill learn" cannot be tested. If, however, I take another paladin, learn the skill, and link it from the spells&abilities tab, "skill learn" does in fact work. But "skill train" still does not, and it's not said "skill learn" would work with skills listed from "skill train". On an unrelated note, requesting permission to merge talentspec branch into master. I'm done with it, and the mangosd 'hang on shutdown' is apparently just because of debug compile - I have that with core and playerbotai master as well. On another unrelated note, is there a command to have the bot drop an item? Such as, for example, an extra quest item. Imagine the following scenario: you must collect 5 feathers (quest item, not sellable), your bot has 4/5, the feathers have a 100% droprate. You kill 4 more birds, you let the bot loot them all. The bot will now have 8 feathers, 3 left over after quest turn-in. These items cannot be sold, and I cannot find a "drop item" command, thus they sit there eating bag space until you log in with the bot and manually remove the items. Unless I just missed the command.

Bug Report: Problem: mangosd.exe crashes when using "skill learn [skill]" Moved level 6 Druid bot next to Gennia Runetotem (druid trainer) in Mulgore. You can learn [Thorns] 95c and [Wrath] 95c. You have 1s99c left. --> mangosd.exe crashes Tracked the problem down to PlayerbotAI.cpp line 6226: The spellId used for "skill learn [Thorns]" is spellId = 467... But it looks normal so I doubt it matters. Also happens on master branch. Beyond that, stumped. 0 experience so far with spells, this seems like a bad place to start.

First a comment that goes for your entire post - I feel (or hope, at least) we'll migrate to a point where PlayerbotAI has two modes. First, a mode where you can activate your alts as bots (from now on: AltBots). These bots are persistent (because they are in fact your characters on your account). You can build these, gear them, etc. You have total control, but you must also control totally (limited autonomy). Second, a mode with autonomous bots (henceforth: AutoBots). You're short a tank for an instance (or you're waiting too long in LFG), you run into a 3man world quest, your server is full of Horde but no allies (for a battleground), you enter a pvp zone that would otherwise be empty, ... You summon the bot(s) and/or the system does so for (or against?) you, but you otherwise have limited control. On the other hand these autonmous bots are level, gear, talentspec-appropriate by design (if you're level 70 and find yourself needing a tank but have no alts, you wouldn't need to level one from level 1 to level 70 first). Also a reminder that I speak only for myself, not (necessarily) the other PlayerbotAI collaborators. There could probably be a few more talent specs, but I'm personally content with what's available. I won't be adding any myself for a good while, I think. But if you're up to the challenge, I'm certainly willing to explain how. As for your 'random choice'... Yes for AutoBots, no for AltBots. Rawr is quite an impressive program but I fear it's use in regards to Playerbot may be limited. Rawr takes a base (what you're wearing now), takes extra information (armory suggestions as well as an extensive database) and suggests improvements for one item slot based on which stats you're missing most. Since AltBots level with you, it's up to the player to maintain them including gear and such. Granted, a simple (optional) system to automatically equip clearly superior gear would be nice but it's still up to the player to micro-manage, tweak, as well as collect the gear, etc. For AutoBots (who may come into existence as a naked level 1-80), Rawr may appear to be promising. But there is no 'base' as the bot starts out naked. Second there's an entire database of items to traverse, but no armory. You can't really suggest improvements for any one slot since you're completely free to pick all the equips and thus you must consider the entire package (including soft/hard limits - like +hit becomes useless after a certain point). But most detrimental to Rawr's system is the sheer time and computing power it takes. Taking 10 seconds (or way, way more) to equip a bot (probably stalling all other server functions) is simply unacceptable. The best solution I have (for now) for the 'AutoBot equipment generation' is to have a small-ish table with gear. The bot would then randomly pick some gear applicable to its level, class and purpose (tank/dps/heal). Unfortunately having this table would make it DB-dependent (you add some equipment. Turns out it's in UDB but not YTDB. oops.). So ideally I guess you would generate this table as a last step in your install (similar to what ad.exe, vmap extractor, mmaps do). At this point it's still an imperfect idea, hopefully I'll be patient a few more weeks and then still be motivated enough to start and finish implementing this (Also, this cannot be tested without AutoBots ("summon bot not based on existing character") so it may have to wait until after that). On a sidenote, does anyone see any use of this for AltBots? Given the assumption of course that they cannot cheat. I do like your ideas. One thing to keep in mind is I am not alone. Maybe my ideal server is one where 1-3 humans play with/against 0-80 bots (WUT?!? 80? ... Think Wintergrasp), but someone else may want a server with 2000 humans and 0-80 bots (perhaps mostly for low-level instances/battlegrounds). And so on. Something else to keep in mind is technical limitations. It should be reasonably possible to make human-esque bots. Have them heal, have the tank use raid icons to mark the first to die or which target the rogue should sap... But how much CPU can a bot draw? Is it necessary/possible to run 500 bots alongside 2000 humans? And so on. Also, how humanlike do you really want them to be? Do you want them to ninja all the instance gear (when you keep rolling greed's)? There's fun to consider as well as being 'humanlike' Hope that clarifies some things. If I misunderstood something feel free to explain further. We're always up for discussion here, so feel free to throw out new ideas. Who knows, someone else may fancy an idea I don't and code it themselves - or perhaps you'll be compelled to

I've found rawr and it looks extremely interesting (Rawr 2.3.22 - Source - Latest 3.3.5a release I think - C# using .NET 3.5 I believe) - especially keeping in mind I'm interested in independent PlayerbotAI's who would need equipment. I'm not sure if I'll add those talent specs to PlayerbotAI's TalentSpec branch. The descriptions are very short so I'm not confident in generation a purpose for any of them - plus most appear to be geared towards PvE Raid. But if you're up for the task, have at it In other news, TalentSpec now applies talents automatically as you level. ProTip: TalentSpecs are forgotten once a bot logs off. I'm happy with how TalentSpec acts, as far as I'm concerned it's working as intended. It's still undecided what ideology to use for acquiring Glyphs, so I'll set that as a distant todo (as in, rebranch in the future), pending discussion. What's left is for me to merge master into TalentSpec (after learning how, without breaking anything), and fix the major bug that makes mangosd.exe hang upon shutdown. Beyond that TalentSpec is ready for merging into master, as far as I'm concerned.

Yay me! TalentSpec is working (talent wise - glyphs are still ignored). AFAIK everything else is working as intended.

It won't be easier but I think you'll be happy because that's exactly what we're working on. I do know of addons like Talented, and there are some paid addon/guides out there with some more information and talent spec presets but I'm unaware of a free addon or program or website out there with talent specs that calculates best gear (or vice versa), or gives you a set of ideal options to follow (gear/enchants/gems/stats, talents, glyphs, skill/spell rotation, ...) based on a few choices. I you do remember please do let me know. So far, I have not found anything that did for talent specs what TourGuide did for levelling (and other) guides.

Did a redo of the TalentSpec branch, code is now completely based on master rather than new-ai. Also added in the fix for an error - thanks blueboy. One known error still remains: mangosd.exe will not cleanly shut down. Several TODOs still remain: Properly respond to 'talent spec #' commands, and have bots remember (non-persistent through server restarts, at least for now) your choices as well as have the bots act upon your choices (resettalents if necessary, learn talents, and learn talents as they level). Not sure how to best apply the glyph part from the talent specs yet... A lot more complex than the rest - either only use from inventory if available, or offer to look for one at the Auction House. We'll see (feel free to chime in with ideas / opinions). Also backported all the 'general' fixes I'd added to TalentSpec to Master, making the talentspec branch a 'clean' branch as well as improving Master. Just a few minor edits though. Went against my character and made a bunch of little commits rather than one big one. Sidenote: fun view in the network graph

You and those before you deserve all the credit for making mangos and playerbot. Others deserve the credit for doing number crunching and figuring out the ideal talent specs. Even experienced gamers may use a suboptimal build - because they misunderstand, are stubborn, or just because it suits their playing style better. In the end the only right build is one that's fun, but as far as maximum DPS (or whatever purpose) goes, these builds should get you close enough. That said, quite a few purposes are still missing builds so if you find one that's still missing, feel free to fill it in. I didn't quite explain it well enough. I'm looking for code that will allow individual bots (but two or more bots) to adjust their actions (now I'll cast "Sheep" because we have no rogue to "Sap") according to group make up or even other bot/player's actions. So if I have a party of 5 wanting to go instancing (let's put PvP and raids aside for now). 3 of them are paladins. Logic dictates it's tank + dps + healer but for the sake of arguement let's just say the other two members are random non-paladin DPS, say rogue and mage (clearly not tanks nor healers). So now clearly 1 paladin is tank (protection) and 1 is healer (holy), the third being DPS (retribution) (because an instance requires 1 tank, 1 healer, 3 DPS). From the link above: I'm actually fuzzy on what exactly judgements are (you get a buff up then use up that buff as a reagent for a 20 second debuff (judgement ) on the target, I believe), but it's a spell of sorts. So right now - unless I'm mistaken - all three paladins will act independently of one another, assume Wisdom is the best judgement and all 3 use Wisdom. The chart above states ideally the tank (protection) use Wisdom while the other two (dps + healer) judge Light. This should be a given - not a reaction. Similar with auras. But I think I've just seen your point. You mean that you should check in PlayerbotAIClass.cpp (or PlayerbotAI.cpp) as to what the other party members are (and if it's PVE), and their combat orders.

Great to hear someone take interest in what is essentially a side project. Hope the code is up to standards And yes, I tried to make good use of Excel but still a lot of manual data handling (plus fixing logical errors in my Excel formulas *sigh*) My real hope is to finish asap and have it merged into the master. Maintenance is my enemy On an unrelated note (and not to say I'm not eager for talentspec feedback), a few weeks back I was browsing some WoW information and came across the following on the wow wiki: Now I'm not really into paladins myself, but some of the most fun I've had in WoW was 6 hours instancing with 3 paladins (and a mage first, a shadowpriest second - both rolling needs on all my favorite gear :rolleyes: ), so naturally I wouldn't mind seeing if playerbot could help me re-create this fun. Plus if you get the paladin class right, that's tank + dps + healer in one blow (without having to account for shapeshifting). Anyway I was browsing the PlayerbotMgr code but couldn't really find any code where same/different classes would sort of adjust for each other (each other's presence, actions, ...) or the master. There was mention of the latter but I guess I missed the actual code of it. I'm not asking for extra code, just confirmation of whether I'm looking in the right place and if so, did I miss the code or is it up to me (or someone with even less patience) to start coding?

Updated TalentSpec branch (thanks much to blueboy for all the git help). Developers preview, adds no other value. In fact, it adds a bug: shutting down mangosd.exe results in a hang (probably from mucking about in database.cpp). It remains to be seen if the sql should be mandatory at all - discuss. As is, SQL is non intrusive - just an extra table in Characters DB. <edit> So to be clear, this preview is for the general changes, the SQL file, and spec / spec errorcheck public inspection. None of the actual using of talent specs is implemented yet. </edit> talent spec # does not even work yet (but at this point wouldn't do anything so no biggie). talent spec errorcheck checks the database for errors. Do the talents belong to the correct class, and so on. As for the SQL data, I picked some popular talent specs. For the purposes I went with my best guess (based on description), using a "best for" scheme rather than a "would work for". So the talentspec is great or ideal for those purposes rather than just adequate. Plenty of purposes missing. Add your own talentspecs or just use a close one. As for One/Zero... Would require minimal adjusting. Glyph code can be removed. SQL can easily be adapted. Talent enums and all talent specs would have to be redone - "not it" Code will not be crippled by an empty DB table (proper - at times even excessive - error checking is in place). (Current) Caveats: - Building a talent spec is still very time consuming. Did and re-did it mostly by hand - mangosd.exe hanging is simply unacceptable. Fortunately this is just a developers preview - talent spec # command is not working, and I can't seem to find the bug... yet. - talent spec errorcheck only works if you are a GM... as in ".gm on". Wish it were linked to account level, frankly. Or is that the right way to do it after all? So feel free to chime in on anything, especially coding style (I tried to copy what I saw) - the sooner mistakes get nipped in the bud, the better.

At first I thought it was a perfect work-around. The thought of bots arriving behind you (or better yet, at random intervals 0-3 seconds before and after you) even appeals to me. It would be a little touch of human which might be especially nice if/when we get independent bots (as in, non-alts not or loosely related to a 'master'). Unfortunately a 2 second delay doesn't guarantee success. It's perfect for me (I'm alone, my server is a virtual machine so no lag), but someone with a lot of lag (although 2 seconds would be quite a lot) might still be a bit bugged. Having said that it's only a workaround after all, and I'd be keen to get my hands on it. Now, I'm feeling exceptionally guilty for not contributing as much recently. I'm still here though, just busier with RL. I think everyone here appreciates the interference real life can bring (I've certainly grown to 'appreciate' it more these past few weeks). But that doesn't diminish past accomplishments. Having said that, it would be nice to see you get back to work but because you want to, not out of guilt

I could have phrased that better. I try to hide it but sometimes it shows english is my third language. Apologies for the misunderstanding. I'm afraid I still don't understand what you mean when you say there's no command for heal. Clearly you mean something else than the automated ".bot co [character] heal". It would seem the manual spellcast also doesn't suit you ("/t BOTNAME cast <SPELLID | (part of) SPELLNAME | SPELLLINK>"). I don't understand what else you might mean, please enlighten me (before there's another misunderstanding, there's no sarcasm in this post). As for autodress, I completely agree it would be handy and improve fun. Personally micromanagement is a thorn in my side. All I meant is that a "simple" auto-equip-upgrade would either be very broken or very not-so-simple. Having said that I would of course welcome development in this area. Great! The more the merrier. Perhaps you'll be the one to code an autodress?

I think I see what you're getting at. There's no need for a 'dumb' auto-dress when you can already do it manually. Given, it's not hassle free, but it still sounds what you're looking for. Since you missed the readme in the first post, here's the link: Yes it's manual but it works like a charm. Granted, an auto-equip would be better but that feature as a viable alternative is a lot of work so even if someone started right now you'd still need to be very patient

If you'd read the documentation (or used .bot help, i believe) you'd know you can assign combat orders (.bot co, IIRC) such as tank, heal, dps, protect, ... As for auto-equip, that's a good point, but it's really not as easy as you might expect, at least not with the current system. Does a druid prefer agility or intelligence? Would a paladin prefer spell hit or spell crit or spell damage - or just strength? Does your warlock prefer stamina or intelligence? How much does higher weapon DPS offset a useless stat? Having said that, in my quest for independent bots (as in, not alts but just "i need a tank for Scarlet Monastery: Armory" *poof* level 37 properly talented/equipped tank), my next TODO (after talent specs) is a simpe-ish list of gear for various levels and situations. But - in contrast to talentspecs - I honestly don't see how that would benefit Playerbot alts in any significant way.

Depends on your level of computer/programming savvy The best way is to first clone the mangoszero repo, then patch playerbotaizero into it. This may however require you to manually fix problems in the patch file (as in, know at least a modicum of C++ programming). If that's too complicated, try just compiling the playerbotaizero (but make sure your DB isn't too new): Note to blueboy: some KISS git instructions on the first post. Seriously, consider it IIRC botguy is an administrative NPC for playerbotai, makes things easier but in no way required. <edit> also, the reason your server.log didn't get debug info - did you remember to set the variable in mangosd.conf as I previously requested? LogFileLevel = 3 Have you tried compiling a debug instead of release version? (please don't list the *entire* server.log again - last 10-20 lines should be plenty)</edit>

Compile the debug version and/or crank up your debug logging level, and check the server.log Does it mention why it crashes?