Bot AI Re-work

[Uleat]

The bot ai processing code was horrifically out-of-date...

It has been re-worked to take advantage of the recent changes in positional updating.

The end result is that bots have a more 'natural' look about them - or as natural as can be had in the current environment.


In addition, several 'features' have been added.


Bot Leashing

Bots will now be limited to how far they can travel - both in- and out- of combat.

They will also have a 'leash owner.' This owner is determined by the group they belong to. Any bot in a group whose leader is a client, that
client becomes the leash owner. If a non-client is assigned as group leader, the leash owner defaults to the bot's owner. All limitations are
based on this secondary owner.

Combat will break, regardless of hate, if either the target gets too far away from the bot or if the bot gets too far away from its leash owner.


Main Assist

Bots will now obey the targeting of a 'main assist' - if one exists.

To set this, just assign the role of 'Main Assist' to one of your group members. This only applies to groups that contain clients. 'Botgroup'
groups do not yet have this functionality - even if their owner has assigned it in their own group.


Combat Abort

Combat may now be aborted if the owner turns off auto-attack. This only applies if the target contains no hate for both the bot and owner. Each
bot must be processed, so aggro may be returned if hate is discovered during the abort process.

Line-of-sight issues will also cancel combat (until LoS is re-acquired) if both the bot and owner lose sight of the target.


Combat Jitter

In addition to the existing 'rogue' jitter code, new conditionals exist for non-'rogue' classes.

Melee classes will 'randomly' adjust themselves on an arc around their target.

Melee and caster classes both have 'back-off' code based on their combat range.

All jitter code is dependent on the bot not being the target of their target (!HasTargetReflection().) So, a summoned bot will adjust their distance
once they are able to.


These are 'rc' changes, so please report any issues.

[rhyotte]

Nice! Man I really need to go ahead and roll up another server to tinker with.

[Proxeeus]

Thank you so much Uleat for those changes, I cannot wait to try them!

[jpyou127]

Uleat, has anyone updated the current BOT binaries that can be downloaded with the update tool?

[Uleat]

I think Akkadius and I are (were) the only ones with that access.

Regardless, he is VERY busy at the moment and I have no idea if I still have access to that repo, much less if I can remember the password...

I'll see if we can't work something out.

[Uleat]

I adjusted the rogue bot's melee distance when behind a mob - they really should be close to perform any back-stab attack.


Also, there does seem to be quite a bit of 'after-adjusting' going on when the jitter code hits.

I'll probably make a new 'plot' function that keeps them on their current arc around their target to avoid forward movement adjustments when they jitter.

[jia_jacky]

Great! If I understand correctly you will continue to work on this, right?
I noticed that spell classes bot didn't know to avoid attacking or back off when mobs turned to hit them. And female dwarf bot always has beard.
So could you consider improving this? Just a expectation.

[Uleat]

Caster bots still don't know how to turn down the hate..that's still handled in the spell ai portion.

I can look into that at some point. (No comment on the dwarves...)

[jia_jacky]

Choosing spells to control the hate might be too complex. Perhaps when caster bots were hit by melee attack they could run away or back up a few steps instead of standing at the same place waiting to be hit.

[Akkadius]

I think Akkadius and I are (were) the only ones with that access.

Regardless, he is VERY busy at the moment and I have no idea if I still have access to that repo, much less if I can remember the password...

I'll see if we can't work something out.

Added you to EQEmuInstall repo

[Proxeeus]

Tried those changes with a fresh compile tonight and.... my bots no longer cast any kind of spells. Strange. Dunno if this is due to the global npc spellcasting AI rework or not though.

[Proxeeus]

Small update: after adding the "min_hp" and "max_hp" columns to the bots spells entries table, the issue resolved itself. Maybe those are missing from the bot db update script?

[Uleat]

Those are new fields to the 'main' db and it looks like we'll have to update - thanks for that report!

(I thought that I had verified bot casting during that work..but, it may have been before the actual fields being added.)


On caster bots backing away, they do back out of melee range when they are no longer the target of their attacker.

It has to be done this way or the mob constantly pursues them and your 'combat arena' is forever moving.

I tested it without that 'reflection' feature and had to constantly move to stay near the action...


EDIT: Thanks Akkadius!

[Proxeeus]

Great changes all around !

While we're on the subject of AI refinements, I was wondering if it'd be somehow possible to have the Bot AI work while in "Guard" mode?

By that, I mean that as soon as Bots enter "Guard" mode, they stop meditating and/or casting/rebuffing - you need to make them Follow you again to have their AI resume the work, and it's a bit hard to manage all that while camping at a spot in a dungeon. (this behavior has been present for ages, it's not a bug report about the current changes)

Dunno if I made myself clear, but that'd be a nice improvement !

[Uleat]

Ultimately, I want to see Bots become a pseudo-player object rather than just an advanced npc 'pet' .. so, changes I make will bear that where possible.

I do see what you're saying with the 'Guard' command. I'll look into a change for that.

[Uleat]

A few more tweaks to the 'jitter' code.


If casters have target reflection and the target is rooted, they will now attempt to move out of melee range only, not the full caster range as they do without target reflection.


Also, modified the position calculation code to accept non-heading change position updates.

This helps a little when bots 'adjust' themselves during combat. (They did a lot of facing movements before...)


I know there are still issues and they will be addressed as I find solutions for them.

You are welcome to report ANY bot movement or targeting problems here since the re-work affects both areas directly.

[Uleat]

@jia_jacky

Funny thing... My female dwarf bot always spawns without a beard and I can't get it to show at all (RoF2 client.)

[Uleat]

Added a little functionality to the ^guard command.


Bots will now 'park' themselves at the point where they are when the command is issued.

No movement is allowed while in this mode. Any attempts to 'force' them to a new position will trigger a 'warp' back to the set coordinates.
(Just release 'guard' mode by issuing a ^follow command and re-issue the ^guard command at a new location.)

This new 'guard' behavior will override the current 'leash' behavior. As a result, combat is currently disabled while in 'guard' mode due to its exploitable nature.

Bots will process 'idle' spell casting while in 'guard' mode.

[Proxeeus]

Interesting, that was quick ! Thank you :)

Does 'idle' spell casting include healing? what about meditation?

[Uleat]

They essentially perform all out-of-combat functions - save movement and target selection.

Non-combat healing of a group member in combat may seem like an exploit (which it is..) but, it is highly countered by the inability to engage
in combat and to use combat spells (bots can die if they get aggro from a target and don't react.)


This is just an initial behavior change and is subject to change as refinements occur.

[Uleat]

Fixed a few issues with the bot ai code..

Fix for bot 'stop melee level' not honoring setting level over rule level
Fix for missing bot combat spell casting when within melee range
Fix (in-work) for bots 'forgetting' current target when it flees



I have more issues to look at and I need to review all of the current behavior..

..but, if you guys have more problems to report or would like to see behavior changes, please post.

[Proxeeus]

Thanks for those fixes !

I've been playtesting old world raids as of late and I've got a remark, regarding botgroups. Let's say that I've got a few bot casualties due to a nasty fight. If I re-summon those bots individually, they don't automatically re-join their botgroup -- I'm kinda forced to redo a "^bgload the_group", even if said group has only lost one member. This, in turn, also restarts the whole group buffing session (it looks like botgroup buffs aren't saved, compared to regular groups?). Moreover, it's kinda hard to keep track of which bot actually died. A command listing botgroups (which already exists I think) and their members + current status (spawned/not spawned) would do wonders !

Unless I missed something ? (which is very possible)

This is no deal-breaker or anything but...think it could be possible to have a look at that?

Dunno if I made myself clear, don't hesitate to ask if you need more info !

Cheers :)

[Uleat]

I'm familiar with the group joining issue..wasn't so much on the buffing one.

I've added these to my list.


(A marquee message on a bot's death would be nice, no?)

[Proxeeus]

I'm familiar with the group joining issue..wasn't so much on the buffing one.

I've added these to my list.


(A marquee message on a bot's death would be nice, no?)

Yeah that's a definitive step in the right direction for sure ! Think an update to the ^bglist command listing botgroup composition (+ their spawned/despawned state) would also be possible? Or too much of a hassle?

Other unrelated, random-ish stuff:

- possibility to configure & persist the songs Bards can twist (on an individual basis) ?

- tweak hybrid tanks AI to include aggro-generating spells ? I tried to refine that using the botspells table but it's kinda hit or miss. SKs will actually use Disease Could so that's great, but spells like Flash of Light & the Stuns line for Paladins is trickier and doesn't really work with the existing system.

- sometimes during a fight where you get multiple mobs, the bots will "split" targets: one will attack mobA, and two will attack mobB, even if you explicitly order the to stick to a target, they automatically go back to their split targets after a few seconds.

- speaking of multi-mobs fight, is there already some implemetation regarding Enchanters auto-mezzing adds? right now the leader has to manually ^mez adds, it definitely works but depending on the situation, stuff can get tricky :P

- i've seen Ranger bots Snare fleeing mobs, so that's good, the problem is that it's being cast really late in the fight. Ideally you'd need to Snare a bit before the mob Flee threshold. Could also add SKs/Necros with the Darkness line as well

Sorry about that info-dump, but those Bots are amazing and I'm only eager to see them become even more so :D

[Uleat]

Note on losing botgroup buffs..

I had no issues with bots in my test botgroup keeping their buffs after camping or zoning.

The only time I had casting was when either a bot died or when a wizard's familiar was involved - which is not bot-related.


Most of what you're suggesting is going to be addressed when I look at spell-casting ai and spell selections.

That's not in the immediate future, though...


I do plan on making bots a little smarter so they can handle mez/nuking opportunities better.

The mob splitting is unfortunately a current design flaw..but, that can be modified.

Try setting the 'main assist' feature of your group to see if that helps (or hurts..) for now.

The 'flee' code addition recently added will force all bots to target the furthermost fleeing mob away from its leash owner when a target
is returned from that function.

When the spell ai and group roles are updated, I can do a lot more to enhance their spell casting capabilities :)


On the bard songs..

Anything like that will be extremely tricky...

They will likely have some 'specialization' when group roles are expanded.

From there, I can look at additional tweaking options.


EDIT: I just heard that familiars are not supposed to be buffed..so, an adjustment for that is incoming.

[Proxeeus]

Note on losing botgroup buffs..

I had no issues with bots in my test botgroup keeping their buffs after camping or zoning.


Oh ?! That's mighty strange... When I'm grouped with 5 bots for a regular xp group, buffs get saved no problem, but in a bot-only group (when I'm raiding), a full rebuff will always happen (and now that you mention it, bot-only groups never zone with me, only my own group does)

Most of what you're suggesting is going to be addressed when I look at spell-casting ai and spell selections.

That's not in the immediate future, though...

Oh no problem, take your time :D

Try setting the 'main assist' feature of your group to see if that helps (or hurts..) for now.
Ah-ha, I wasn't aware of that feature, I'll take a look !

On the bard songs..

Anything like that will be extremely tricky...

They will likely have some 'specialization' when group roles are expanded.

From there, I can look at additional tweaking options.

Alright :) I did think of something along the lines of maybe having a separate db table storing a botId and maybe 3 songsId, and those would be set via a bard-specific ^twist songId command...since Bards are already capable of using Songs it'd "only" be a matter of actually loading those songs from the table instead of the current method......or that's only the tip of the iceberg maybe? :p

[Uleat]

If you are running your own server, I would take a look at the logs to see if there are any error messages for saving bot info.


Adding a 'tertiary' table for bard bot songs probably won't happen.

I pulled bot spells(/songs) out of the primary npc spells table so that non-bot server admins could completely gut bots from their
server code if they wanted to.

User-added spells are really not an option with the way the npcs use spells .. and bots eventually go into npc code for casting.

That would require a re-work of the entire spell casting system to allow for something like that..and I'm not really the one to say
that change is acceptable to the base code.

I'll keep that in mind as I make changes..but, I just don't believe that something like that is possible at this time.

[Proxeeus]

Alright, that clears things up! Thanks for the explanation :)

[Uleat]

Proxeeus,

What are your thoughts on these 'additional' songs?

What would they do that the base songs wouldn't?

[Proxeeus]

Well to be honest I'm pretty unfamiliar with Bard (and Bard AI in general) so bear with me :p

My line of thought was, maybe during a raid a player would like to have, depending on botgroup compositions, Bards playing different sets of songs (ie: a melee-heavy group would get melee buffs, a caster-heavy group would get mana regen songs, a magic-heavy encounter may require heavy elemental resistances etc).

Unless this kind of reasoning already exists? As I said I'm still pretty much ignorant in that area. If this is the case you can pretty much ignore this :D

[Uleat]

Proxeeus,

I kinda ran into what I think you may have been describing as not saving botgroup buffs.


Try camping the existing botgroup first. (Or, all bots and just respawn them all...)

The code wasn't really meant to handle that particular activity and there does appear to be a database locking issue..
..since no 'bot saved.' messages are generated.

I'll still look into this more when I get a chance.

[Proxeeus]

Proxeeus,

I kinda ran into what I think you may have been describing as not saving botgroup buffs.


Try camping the existing botgroup first. (Or, all bots and just respawn them all...)

The code wasn't really meant to handle that particular activity and there does appear to be a database locking issue..
..since no 'bot saved.' messages are generated.

I'll still look into this more when I get a chance.

Interesting ! I'll try that this afternoon and let you know :)
Thanks again for looking into it !

[Proxeeus]

Well, this is remarkable. It looks like this is it indeed.

I did a ^bgload my_botgroup, waited for everybody to get buffed, and then manually camped them.
I then re ^bgload'd that particular group and lo and behold, they didn't rebuff themselves.

Interesting...

[John C]

I would still love to see an option to allow Bot's to break Mez upon command. For an enchanter in a group of bots, the ability to do so is somewhat important. It isn't nearly as big of a deal as it once was for me though since I compile my own binaries, but it would be nice to have it as part of the standard code.