blueboy / portal Goto Github PK

bot wont collect skins until I log bot in and skin one creature the first time. after that, bot will always skin.
This is speaking of the very first time. After the bot has skinned one creature, after learning the skill, it will always skin
even after being logged out.

The command 'get' doesnt work even, until that char has been logged in and skinned one creature. (not as a bot but as main)

They all have instant casting. This can result in e.g. 10+ instant shadowbolts on a single target.

Easy test: login a mage (with both conjuring spells... is that level 4+ or 6+?). Instantly conjures both food and water.

I've checked and re-checked the PlayerbotAI::UpdateAI() function but it starts by setting a 2second 'timeout' then proceeds to call DoNextCombatManeuver and returns (at which point it should wait 2 seconds until the next spellcast).

PlayerbotAI::UpdateAI() calls PlayerbotAI::DoNextCombatManeuver calls PlayerbotClassAI::DoNextCombatManeuver calls PlayerbotClassAI::CastSpell() calls PlayerbotClassAI::CastSpellNoRanged or PlayerbotClassAICastSpellWand()

I know I broke it but I can't seem to fix this. It can't be that m_ai->CastSpell() suddenly acts differently or needs a stopcast call or some such.

Bots are not drinking to regain mana. Easily reproducable case is taking a paladin healer to an instance such as Ragefire Chasm. When told to use [Milk] the milk is used/drank just fine. After that, milk is still not drunk automatically.

Milk is a level 5 item and the bot was level 17 at this point, but I've seen the same problem with other bots (including the Mage of this party).

On a possibly related note, the mage was not creating food or water either.

Okay, I encountered this glitch with a low level spellcasting druid (just him and me) - important: NO TANK. I let the druid get aggro (just tell it to attack and do nothing), and he somehow aggro'd a second mob. So now he's got 2 boars on him, getting him the maximum of 0.5 * 2 pushback on his spellcasting. In other words, the first two attacks during any one spell cast cause that spellcasting to be 0.5 seconds longer (per attack, up to a maximum of 1second).

So a 1.4 second (or 1.5, whatever) spellcasting for Wrath would turn into 2.4 (or 2.5) second casting. Thing is, the loop delay for NextCombatManeuver was set to 2 seconds which caused it to stop it's nearly-finished Wrath and start over. Nowhere (that I know of) does it account for the spell pushback which may make spellcasting take longer than intended. Likewise, for channeled spells (like say a priest's Mind Flay) each pushback takes off 0.5 seconds. Also unaccounted for but far less critical (at worst the bot will stand there for a second).

There also lies danger in the imprecision of the delay code, with a maximum precision of 1 second. So you can't have the bot sleep 1.6 seconds for a 1.4second casting. You can't have it wait 3.2 seconds for a 3second mind flay. You can't have it wait an additional 0.5 seconds because a pushback occured. Have been wanting to redo that system but took a quick look and was thoroughly discouraged ;)

Nobody likes to die so I only saw this once. My bot tried to resurrect me, but before I could even accept she was resurrecting me again (spellcasting and saying she's resurrecting). Note that proper functioning is not impacted, you can ress just fine after it's been cast the first time (and you accept).

Probable cause: The bot probably expects it to be auto-accepted (as it is by other bots) and is confused that you're still a ghost/corpse.

First adapt GetHealTarget() to take extra input:

• TYPE to heal. use the enum (make it public), make sure the enums can bitwise checked (0x01, 0x02, 0x04, 0x08, ...). Allow function to specify only healers and tanks are valid targets (if, e.g., the healer has aggro)
• 'ignore max health' toggle - could be used with type above to e.g. target a full-health tank
• possibly add OOC toggle?

Copy GetHealTarget() into GetResurrectTarget() code.

• ensure you're not in combat (... doesn't the druid have a special in-combat res? the shaman certainly has an in-combat self-res)
  ** prioritise the healer CLASSES (ignore IsHealer()) because they can help resurrect
  ** prioritise tanks next
  ** anyone else left over

Find a way to generalize HealTarget. It's mostly the same code. Can it be done with a simple 'minHP, spellToCast' table passed along?

What better way to test (1v1) PvP rotations? Add a 'duel' command (must have target selected) and the bot will challenge that target (if valid target) to a duel.

It would be like battle bots except no-one holds the remote! :)

Not all corpses are looted. This is more obvious with quest loots (if some bots have finished the quest, it only requires one bot not to loot to be obvious), but can happen with any mob.

New-ai, right before skillbot merge (ok, I guess we could use a versioning system - too bad git doesn't autoincrement):
2015c33

Easy steps to reproduce bug:

• 5 man blood elf team (mine was 3x pala - tank, support tank, healer + mage - support healer + hunter - me). Level 1-6 should be fine. ".modify speed 2" on yourself or party should help gather the mobs without dying.
• Go southwest, hug the mountain on the right until you see the circle with the flowing water in the middle. Here are 20ish easily aggrod trees. Just run the outside of the circle until you've got all of them. Kill them. Wait for bots to finish looting. About 20% should remain unlooted.

Best guess - loot corpse table gets deleted somewhere in the middle, at random per bot. Just a feeling, but the healer felt particularly susceptible to this issue.

• Oh, and a manual 'get' command does lead to looting.

What we hoped to be fixed by the turn-and-face fix is still a problem. I have seen my warlock and druid still lock up. They won't react at all, won't move, turn or attack. After a little while (30seconds?) they return to normal. Haven't pinpointed exact reproducible circumstances - certainly occurs [sometimes?] while fighting multiple mobs. Keep on fighting, take some time for looting every few mobs, the error should occur soon enough. Should work (or rather, fail) with just level 1 bots. Mine was a 5man party, the warrior and (healer) priest were just fine meleeing.

On a possibly related note, bots appear to be casting 'backwards', as in, to a target (which -at least- to the player appears to be) behind the bot. Is it possible your turn-and-face-target code isn't communicated to the player client(s), or is something more hinky going on?

I wanted to train My "already apprentice skinner' bot to journeyman..

I had no other skinner bots, so I just gave the command "skill learn" in /p chat..

They all learned the "Journeyman" skill..... Only the one, was even a skinner.

Just a heads up

was testing, priest kept getting aggro and spamming 'casting fade' every tick.

1. check and make sure it's not a chat glitch and that he's actually casting fade rather than just saying he does yet going his merry own way
2. see if cooldown check can't be added to PlayerbotAI::CastSpell (assuming (1) holds true).

It was using hard-wired values. Simplified things with just inputting the m_CombatOrder var.

(1) When restoring, make sure ORDERS_PULL is off
(2) when restoring, make sure it's not checking for hard-wired values
(3) combine primary and secondary order uint8 variables from SQL into one uint32.

Think that's about it.

CombatRestore may not work properly until then.

I looked at my warrior and druid and suddenly they were mostly naked.

Could also be a bug in the sell command listing stuff they're wearing.

This was with all gray/white gear.

Not much info to go on, I know, but this could be one disturbing bug to players who spent days getting decent gear for their playerbot alts.

I've been pondering this for a while now. How can you best make the bots cooperate as a group? And as important (or rather, a part of that) how can you let other bots know what you're about to do (e.g. "don't heal him, he's taken care of"). Fortunately, as a group it's not that necessary, but it does when it comes to a raid. Imagine a 25man raid.

E.g. 1:
5 healers, 3 tanks (I think that's how it works) of which 1 main tank and two offtanks. You'll want a healer or two on the MT, a healer or two on the off-tanks and the other healers to top up anyone. If a druid healer is present you'll probably want him to top everyone up with HoTs. As it stands, all healers (on the same AI tick) would pick the same healing target (thanks to my GetHealingTarget addition).

E.g 2:
There are 3 paladins in your group/raid. How do you ensure each gives the proper blessings? Each uses an appropriate aura? You could probably get by by analyzing the group make-up and guessing who does what. Or you could have a group handler which tells each bot what to do setting toggles or whatnot.

I'm sure there's more uses and use cases than off the top of my head. I do feel there is merit to a group/raid wise intelligence (or rather, AI) :) but it is an invasive addition so I wanted to put it up for discussion. I certainly wouldn't be able to do this on my own.

• No real merit to this idea as alternatives are already available or can easily be added
• Merit to this idea but the difficulty of adding and/or maintaining such a feature outweighs the benefits it may bring
• May be difficult but should prove to be worth the time investment

Did a pull merge on the current cmangos code and got a ton of errors from the bot side =/.

You have skinning, bot has skinning. You start skinning first, before you finish bot starts skinning. You get the leather, corpse disappears, but bot will continue skinning animation and (more annoyingly) sound. All returns to normal next time the bot succeeds in skinning, and normal bot operation - including combat and further skinning - are not impacted. Do note that combat does not clear the infinite skinning animation.

Sidenote: if bot skins first, he succeeds, you stop skinning (and mangos incorrectly tells you the target is 'out of range' but that's not a playerbot issue). No problems there, playerbot-wise.

In an attempt to logically spread these commands as well as clean up the base 'help' response:

• "/s .bot co|combatorder BOTNAME COMBATORDER [TARGET]" -> "/t BOTNAME orders" and appropriate subcommands
• remove legacy .bot co command
• /t BOTNAME resumeorders -> orders resume
• /t BOTNAME combat delay <0-10> -> orders delay <0-10>
• /t BOTNAME follow (+subcommands) -> orders follow (+subcommands)
• adapt help to include new 'orders' functionality and subcommands
• don't forget the readme.txt file

'skill fetch' is not listed under playerbot 'help'

FirstCombatManeuver is nice, but what if you could predict combat will start and cast a spell before it?

E.g. You give the pull command. 3 bots give the group a readycheck. The priest casts a shield BEFORE combat, thus receiving 0 threat for this. The priest subsequently gives the group a readycheck. The tank attacks.

... Might even be possible to use the in-game /readycheck for this so humans can chime in :) - although I believe only the group master gets the actual 'everyone ready' tell while we want the tank to be told.

Integrate 'IsBetterEquip' [not actual function name] from Equip Auto into need vs greed roll (rather than 'can i equip it' which I believe is used now).

Note this may not be a 'skill learn' issue, but ...

This is the first time I've notcied this... of course this is the first time I've had a paladin as a bot also..

paladin bot trained his first few spells, but now won't train any more.

He has his starting spells...
When I try to 'skill learn' on any paladin trainer I get the following response:
I can train the following spells blah blah
such and such money left...

but no spell list.

I logged him in just to check and he could train the spells...

I've not noticed this with any other character, is it something on my end or...

Hes a blood elf paladin and hes level 10 now.

Hi there, not sure if this counts as an issue because it's more of a question.

With the bot commands, are there any ways to force the bots to drop their target and follow you or make them flee to X distance from target and is there a way to make them follow another player?

Loving the bots btw :3

Report made at:

http://cmangos.net/thread-74-post-737.html#pid737

Frankly I'm not 100% sure they were healing before (I'll be assuming they were).

The Druid was (rather inadvertently) my testing platform for the new healing code, which got pushed and integrated into the Druid (at which point I had the good sense to wait for successful testing before patching into shaman, paladin, priest).

Symptom: quite simply they don't heal at all. Does attack as normal though.

(this issue is mostly a reminder for myself)

Specifically the new GetHealTarget() function, and adapting (mostly removing and some restructuring) the class's healing code.

Done:

• Druid

TODO:

• Shaman
• Paladin
• Priest

NOTE:
This is an improvement but all classes currently heal just fine (this is not a fix as a fix is not required).

note to self:

Clean up autoequip transfer after testing changes.

TODO:

• test changes to ensure there are no boo boos
• reconfigure help
• remove old autoequip code (mainly removing "PlayerbotAI::_HandleCommandAutoEquip()")

Pretty sure this is not a new bug. My druid was buffing the entire party marvelously but left out the warlock.

Current hypothesis:
The PlayerbotAI::Buff() function looks at the warlock, sees his demon armor, goes "Wow, +90 armor? My mark of the wild only gives +25. Yep, this guy already has a better buff on him than I can give".

All handy dandy, except you can have both Mark of the Wild and the warlock's armor spells.

Confirmed. Level 20 priest, level 10 druid (with level 6 spells from starter area).
Inner Fire on -> no Mark of the wild.
Remove IF -> get MotW.
Add IF - MotW stays (of course).
Remove MotW - no new MotW
Remove IF (at this point no MotW) - get buffed MotW.

Okay, so using ".modify speed 6" isn't exactly normal usage, but the bots never forget about a target and keep running off. Reset nor follow help, only logoff + logon (or waiting until they've killed them all + adds).

Suggest we add a check to see if target is too far (75 yards?), if so, remove. I may be a special case but this should be a good check in any case.

Can your warrior equip a 2handed axe? Can your hunter hold a staff? ... Wait, do druids ever support 2H maces and did I remember to weapon train him?

Obviously the biggest gain here is for weapons (and perhaps the occasional brainfart). List out in some way which rewards can be equipped by the bot.

Personally I'd lean towards 2 lists (in the same party chat line). E.g.:
"[QuestCompletedName] rewards: I could equip [X] [Y] [Z] or sell [A] [B]"
"[QuestCompletedName] rewards: I could sell [A] [B]"
"[QuestCompletedName] rewards: I could equip [X] [Z]"

Feel free to be creative. Listing sellables by value and/or equippables by 'score' (most likely to be an upgrade first).

Had the genius idea to put this as a dynamic check in CastSpell (playerbotai has its own anyway), that way all are done at once.

And found it in all of half an hour. In good Kennumen tradition this patch will be community tested. (... what? At least it compiles) :)

If no errors are found I will:

• proceed to remove all checks from each class as they are now unnecessary (and most likely inaccurate and erroneous)
• prepare for global domination
• close this issue
• remove the manacheck branch which is still illogically dysfunctional but ultimately unnecessary (why do you either never remember, or remember right after posting?)

Fix pushed to new-ai. Go test, minions.

Following the recent commit for 'auto equip', I thought it might be a good idea to save and restore the bot(s) Automatic Follow Distance to the database too.

o Default FollowAutoGo , can be FOLLOWAUTOGO_RUN (Enabled) or FOLLOWAUTOGO_OFF (Disabled).
o I first assigned meaningful enum labels to replace the existing FollowAutoGo values.
o Save bot(s) FollowAutoGo as the feature is toggled by command >follow auto.
o Restore the bot(s) FollowAutoGo values, using command >resumeorders
It was important to associate the FollowAutoGo values with meaningful combat orders. If we were to restore without appropriate orders, (via say BotDataRestore()) the bot(s) may behave very strangely.
o Create subcommand 'info' for 'follow' command, to show Automatic Follow Distance toggle status.

You can setup a macro to provide useful information. Once you set combat orders in-game, they will be remembered for future sessions so it not necessary to include these setting in the macro.

/p resumeorders // restore previous combat orders
/p equip info // show 'auto equip' status
/p follow info // show 'auto follow' status

I have a working patch and I would be interested in your thoughts.

Cheers

User uses command pull

A) target is not elite -> skip to step (3)
B) Target is elite -> start at step (1)

(1) [optional, probably tweaked in later] some sort of readycheck
(2) pre-combat stuff. I'm specifically thinking of cheap (mana-cost) HoT spells (renew, rejuvenation, probably not regrowth). Optionally a shield (if a priest is present) - somewhat expensive but 0 aggro if cast before entering combat.
(3) tank does one hostile action, the longest range one he has. For a warrior this would be using a gun/bow, for a druid faerie fire. If nothing over 20 yards (or whatever, should be 30 except for paladins, really) is present, give a warning and do nothing.
(4) everybody waits until the target is in melee range of the tank +2seconds or until tank no longer holds aggro. DO NOT DISABLE HEALING AT THIS POINT. Healing the tank is worth the risk of getting aggro.
(5) Everyone attacks.

I recommend we also disable pull for anyone not marked 'tank', to start with.

Died while testing healing code. Looked somewhere else, returned to find Druid attempting to resurrect me (tons of chat saying he's doing so). Doubt level 5 Druids (or at least this one) even have resurrect. Likely just missing a check along the lines of "IF (SPELL_RES > 0)". Should be a fun one to test ugh.

I found an issue with the 'repair' command while testing the code. The account I was using already contained a guild of three characters. It was necessary for me to create two new characters. The current playerbot code does not allow you to add additional characters to an existing guild.

The 'repair' command checks whether the bot is a member of a guild. If it is, then guildbank money is used. If the guildbank does not have sufficient funds, the bot is not repaired. Although the bot may have enough personal money.

Solution:

I have now made it possible for the guild master to invite bots to an existing guild, and if they meet the necessary requirements will automatically accept the invitation.

I have also modified the 'repair' command to check whether the guildbank (if bot is a member and allowed to remove guild money for repairs) contains enough money. If it doesn't, then a check is made on the bot's personal funds. If the bot doesn't have enough, only then is it not repaired with a warning to this effect.

I will be pushing these changes to the new-ai branch shortly.

Hope this helps

Sometimes the sell command simply will not sell or sell in a very delayed fashion. It does not lock the bots - they are free to move and such. The bot will not even acknowledge the command output (if the new "gm chat" command is toggled on). If you're patient the bot may get through - although it appears only the last sell command the bot has received will go through (uncertain of this point).

When using party chat to sell (which is virtually always for me), if this occurs it occurs for the entire party.

Haven't tested sell all yet.

autoequip toggle is not saved once the bots log off. Save this in the MySQL database, recommend using same table as combat orders / combat delay.

You can kill your own Bots for earning honor. Maybe you can add a feature to disable it?
Probably an autoinvite to group or something like that?

Thanks for your amazing branch and your perfect bot System :)

Instead of staying back and attacking ranged, the hunter playerbot shoots once, then runs in and melees.

Hey blueboy,

I get this when compiling:

[ 90%] Building CXX object src/game/CMakeFiles/game.dir/playerbot/PlayerbotAI.cpp.o
/root/portal/src/game/playerbot/PlayerbotAI.cpp: In member function âvoid PlayerbotAI::DoCombatMovement()â:
/root/portal/src/game/playerbot/PlayerbotAI.cpp:3066:63: error: no matching function for call to âPlayer::GetCombatDistance(Unit_&)â
/root/portal/src/game/playerbot/PlayerbotAI.cpp:3066:63: note: candidate is:
/root/portal/src/game/playerbot/../Unit.h:1151:15: note: float Unit::GetCombatDistance(const Unit_, bool) const
/root/portal/src/game/playerbot/../Unit.h:1151:15: note: candidate expects 2 arguments, 1 provided

Playerbot commit 3e59649
cmangos commit c7309f5
This is on ubuntu 12.04 64bit

Combat Delay is not remembered and defaults to 1 for the tank, 2 for DPS, 3 for healers. When you set "combat delay 0" and log off/on the bots, it resets to 1, 2, or 3 - not to 0 like it should. I suspect this is a conflict between auto follow distance (which I presume resets the values) and the storing/loading of the combat values from the SQL database. Frankly, it's debatable whether auto follow should take precedence, but I feel not. When the auto follow values are used, they are (or should be) saved to the database - if manual settings are chosen to override those values, those should be saved and used from then on. The user can always reset to auto follow, after all.

Spent a few hours looking into this already, lead to some tweaking of the load/save code, but haven't found where the values are reset to 1, 2, 3. Will check into myself if the issue stays open, may not have the time for the next few days - feel free to leave this open or assigned as you wish.

Healer, next to target, generally getting an extra aggro or 2...

No. ... Just... no.

I'd leave in a priest's wanding because that's debatable but never, ever move within melee range (unless the target is <6 yards away perhaps?).

Regardless of the fact that bots shouldn't talk to party chat (which could be whispers as well), there is quite some addon chat going on in my client. Enable an in-game toggle to turn outputting this on/off.

Specifically:
PlayerbotAI::HandleCommand()
-> DEBUG_LOG("chat(%s)",text.c_str()); (except, of course, sending this in-game as well).

Either they're not being set, or they're not being reported correctly, but setting combat orders results in a "no orders set" message.

'skill learn ' is free. Furthermore, you don't need the funds at all.

"Spell costs 95c, 80c left"
-> "spell learn "
"spell learned, 95c spent, 80c left"

Same goes for professions (first aid).

Oddly enough, does not affect weapon masters. Learning 1H Swords on a mage spent 9s50c with not enough left for daggers or... the other one.

Some spells are cast without (e.g.) a mana check. Let's face it, those with mana checks may well be based on wrong values. I propose we add a check straight into m_ai->CastSpell(). It's centralized so all we really need is a way to lookup the required power (mana, focus, ...) from within the game. The player is bound to have such checks, should be a good first place to start. Then we can stop worrying about it in each classes DoNextCombatManeuver (and other places).

Group seems to be attacking random targets rather than assisting the tank - despite explicit 'assist tank' combat orders.

Nuke down same target - same target as tank. Pros: quicker reduction of the number of mobs attacking the group, easier for tank to hold aggro (tank is made to take less damage so better survivability for the group and less strain on the healer)

There are two exceptions:

1. (easy to check) Healer has aggro. Any DPS with aggro is always better than healer with aggro.
2. (difficult to check) if there are a ton of targets, one or more of which are elite (tank tries to hold aggro), one or more are normal (DPS nukes these down ASAP, possibly even with high-cost AoE skills)

Bots will eat and/or drink, but will (generally) only stay seated until next Update loop.

Proposed solution:
My intended solution would be to have some sort of toggle (boolean) set after drinking and/or eating (you can do both simultaneously) which ignores everything except battle for 20 seconds (and when refined, however long the drink/food lasts).
Bool check must be done outside of class AI as preventing movement is as important as preventing any other actions.

Currently, I'm forced to use my Android phone instead of my PC because it's my only access to the internet.

I'm using AGit, a jgit port for Android. Functionality is extremely limited, allowing to only clone and then update repos with pull. Unfortunately, every attempt to clone Portal hangs at "receiving objects" with progress stuck at 99%. Clones of other repos, MaNGOS and ScriptDev2, work flawlessly.

Is there perhaps some blob corruption in the Portal repo or was it perhaps created with a non-standard format? Could there be some bad commits causing the cloning to stall? I haven't tried doing a bare clone, but I want to keep the history intact so I can keep my repo on the PC up to date.

I just want to be sure if it's a bug in AGit or a flawed repo causing the problem.

It correctly sets "m_targetType = TARGET_THREATEN;" over in GetCombatTarget(), and switches targets properly, but the TARGET_THREATEN flag isn't used anywhere. I understand why it's unnecessary for tanks (because they will always have ORDERS_TANK flag active) but it really should be used/obeyed to get aggro off a healer or other protect target by casting high-aggro spells by non-tanks.

More difficult to do on classes that never tank (identify high aggro skills and put them in a special tanking/aggro section), but should be reasonably easy on the tank classes (which is 4/10).

Using 'quest add' for 'Moonglade' druid quest results in getting the quest, but not the spell. I decided to this manually after accepting the quest through the bot and the spell was missing. Dropping and accepting the quest manually does add the spell. Completing this quest would require GM intervention to add the spell because it would otherwise be inaccessible (I believe, untested, but it was unavailable from the trainer for me).

Reproducing this bug:
Get a druid, .level 9 (so the druid is level 10), .tele Thunderbluff (or the alliance town - teldrassil?), visit the main druid trainer (Horde; Turak Runetotem), 'quest list', 'quest add [Moonglade]'. Log in manually to see the spell (normally under balance) gone.