Bot observations

[ZombieSoul]

I switched over to bots from mercs a while ago, overall pretty nice, but the things that really bother me about them and I'm poking around the code trying to figure out are:

If you get engaged(in combat) and the bot doesn't have line of sight. they just stop and twiddle their thumbs. I have them currently moving to their owner so you don't have to ^summon every corner in a tight dungeon seems to work but I need to figure out the proper way to move them, right now they just slide to me and if I am in los of the target they will pick up and fight as normal.

The other things are pretty much the same as I've seen mentioned here.

Group disbanding/ bots depop or get broken(stand there and stuck in group until group is disbanded) on zoning: this seems to only happen since a friend of mine started grouping with me. so over 1 client in a group makes the groups bug out with bots.

and the last thing is the terrible rubber banding while they are moving, I can watch them run to a target, and it seems like they do it over and over again until the server says they are there. like the client thinks they are moving faster than the server says they are. The same thing happens when they are following. or really just moving at all. but my pet seems to have very little of that. the mercs didn't seem to do that either.

These are the things i'm looking to improve, any ideas or pointers are welcome. I still am trying to wrap my head around the code.

Thanks for reading.

[Uleat]

I just pushed updates for Bot Bards (songs and song twisting) and Wizards (familiar casting.)

The line of sight issue is next in my sights and the rubber banding issue is near too.

Grouping is a whole other beast..but, it is on the list.

[GRUMPY]

When it comes to the grouping/following glitches with the bots, I was always curious of the comparison between mercs and bots. (as far as the coding goes).
I don't know anything about that end of the headaches, but is the coding similiar with each other ?

[Uleat]

When mercs were first introduced, they were pretty much a cut-and-paste of bots.

They (mercs,) of course, we standardized a little more since they are a part of the live gaming experience.

Bots tend to be bastardized since they are exclusive to the server code..and then bastardized even more since they are not part of the standard server.


When I work on bots, I focus exclusively on them because:

1) There are no dedicated devs working on bots..

2) I don't know how mercs work on live and have no reference to make changes to them with.


I haven't played with mercs to see how their grouping works...

Do they have similar issues with grouping as well?

[ZombieSoul]

I'm glad to hear those are on your radar, looking through the code, i'm a bit confused, it seems like there should be simple solid npc movment for npcs, mercs, pets and bots etc to move/path through and they all should work about the same as far as movement goes unless something fancy is needed. but I my vision is clouded as I drown in the code. haha.
I can't help myself but to unravel it piece by piece, its like a jigsaw puzzle to me.
If I can figure it out, i want to make playing solo more like bards tale or might and magic. where you pick up your group from the local inn and go work to level the group up and equip them as you do. If players want to join you, you can just have a bot sit out.

Thanks again, for all the work

[ZombieSoul]

I just saw you replied at some time before I made my post, as for the Merc grouping, I can test that, I moved to bots before a friend was interested in joining the server. that is when the bots started to really have problems with groups. after work tomorrow I'll do some zoning with more than 1 client, it happens every time on zone with more than one actual player in the group for bots.

[GRUMPY]

When mercs were first introduced, they were pretty much a cut-and-paste of bots.

Do they have similar issues with grouping as well?

No, I don't find any issues with mercs at all when grouping, zoning, following. That is the reason why I am wondering
what the overall difference is between the behavior. (in the coding) For example, why the mercs follow so faithfully
and the bots don't. I can run all over, zoning and the merc, for the most part, keeps up. But the bot will take the
scenic route. Haha I just figured "some" of the mechanics in the source code would be the same for both ?

[ZombieSoul]

I was looking over this today while at work on my breaks, the grouping issue seems to start with this:
// Handles all client zone change event
void Bot::ProcessClientZoneChange(Client* botOwner) {
if(botOwner) {
std::list<Bot*> BotList = entity_list.GetBotsByBotOwnerCharacterID(botOwner->CharacterID());

for(std::list<Bot*>::iterator itr = BotList.begin(); itr != BotList.end(); ++itr) {
Bot* tempBot = *itr;

if(tempBot) {
if(tempBot->HasGroup()) {
Group* g = tempBot->GetGroup();
if(g && g->GetLeader()) {
Mob* tempGroupLeader = tempBot->GetGroup()->GetLeader();
if(tempGroupLeader && tempGroupLeader->IsClient()) {
if(tempBot->GetBotOwnerCharacterID() == tempGroupLeader->CastToClient()->CharacterID())
tempBot->Zone();
else
tempBot->Camp();
}
}
else
tempBot->Camp();
}
else
tempBot->Camp();
}
}
}
}
Which camps out bots on zone if they don't belong to the group leader.
I'm going to try just looking for clients that are in the group instead of just group leader and see where that leads

Edit: forgot to mention, mercs handle this way differently. So unlikely to have similar issues.

[Burningsoul]

Coming from a 2014 build where bots use the # command, I just can't get behind new bots. They're clumsy, too verbose, and ADORE standing around drooling. Like 5 steps forward in the amount of commands available (and stability I'm sure), but they feel and operate radically different and I'm not that big a fan. Not declaring war on Uleat, you do amazing work man. This just isn't my cup of tea is all.

[GRUMPY]

I have always had a preference for boxing, which is a great alternative when you can't find a group, but I see the bot system as a
work in progress and don't take them too serious yet, (more like a beta version still) but they could be interesting down the road when
they get a little more smoothed out, if that's Uleat's intentions on the bucket list.

[Uleat]

They're clumsy, too verbose, and ADORE standing around drooling.

I think I started playing sometime around March of 2012.

I do know that a former dev made some changes to bot behavior between then and the time that I started working on them more mainstream.

The only real changes, previous to the recent ones, that I've made were the new command system and heal rotations.

I know the command system seems a bit unintuitive, especially coming from the old system. But, it is completely separated from the main system
now and allows much more flexibility without all of the duplication that the original system had. (Not trying to sell it :D)


Not declaring war on Uleat, you do amazing work man.

Thanks and thanks! ;)


This is what causes bots to stand around and drool: https://github.com/EQEmu/Server/blob/master/zone/bot.cpp#L2217

Casters stop much further out if they are moving (following) when the target is engaged. This led to the problems listed in the remarks above that line.

That is my next project..figuring out what to do in those cases.


Bard song twisting got fubar'd for a number of reasons..one being my timer hack for instant recast songs.

The reason that was done was to fix an issue where only one song within a certain level range was being cast repeatedly.

That particular issue has been resolved with the bot using proper recast time.

[ZombieSoul]

This is what causes bots to stand around and drool: https://github.com/EQEmu/Server/blob/master/zone/bot.cpp#L2217

Casters stop much further out if they are moving (following) when the target is engaged. This led to the problems listed in the remarks above that line.

That is my next project..figuring out what to do in those cases.


What makes sense for me is if the fight starts, and the bot can't see, move to towards whoever they normally follow until they can see what to attack.

[Uleat]

Yes, that does make sense :)

That's just not how they are coded atm..


EDIT: It's hard to switch projects in the middle of them when they contain db changes..it will come :D

[ZombieSoul]

Rock on man, I am just enjoying the discussion on how the bots are moving forward, please at no point take anything I am saying as trying to coax you to work on anything but what you have planned, I tinker and tweak in the mean time figuring out how it all works.

[Uleat]

Ok, I pushed a fix for line-of-sight combat issues.

Let me know if it isn't working or is causing other issues.

[Uleat]

I updated the los code to include the new node-based pathing change that I put in the follow code.

There is also an update to how position update packets are sent. This seems to help with the rubber-banding effect.


Both of these have optional rule scripts (see changelog.txt.)

[ZombieSoul]

I have tested these out a bit, and so far it is a big improvement, i'm wondering what the root cause of this is, while this mitigates it quite a bit they still look like they reset themselves every few steps. I was reading some past threads indicating that the bots follow didn't always do this. either way, appriciate the time you've spend working on working out the kinks in the bots, they are coming along nicely.

[Uleat]

You did add the optional rule to turn on the update packets?

If so, and you're still seeing issues, you can try enabling the else clause and recompiling.


I didn't want it enabled by default due to the increased bandwidth usage.


EDIT: Note: Node pathing is on by default, movement packet updates are off by default.

[ZombieSoul]

I have the optional rule for the updatepositionwithtimer added and set to true. the usepathing is also added and set to true. I will take a look at the else clause and poke and test at it for a bit and see if I can give anymore feedback.

[Uleat]

Bots are viewed as other clients by the client.

They are expected to update with some regularity (sub-'whatever rate we update update them now') or the client will 'postulate' their position based on
previous vector and velocity.

The more updates you send, the less postulating that occurs :)


EDIT: Clients always disappear first when things get laggy.

[ZombieSoul]

I spent the evening playing with my bots and this code, and what it looks like to me(speculation) is that when the bots move the client is getting the wrong speed for the client side prediction, so it runs them out ahead of the server position. the increased updates make the rubber banding much less noticeable because it corrects more often and smaller rubber band steps before correction.

I found this interesting post: https://www.eqemulator.org/forums/showthread.php?t=40058&page=2

and also remember seeing a comment in the code about bot speed calculations. So, all together, I am leaning towards a speed calculation bug.

That is my feedback so far, I'll let you know if I notice or discover anything else

[ZombieSoul]

Well after a bit more testing I'm not sure my assumption was correct, something very odd going on here, to observe the movement more carefully I set the speed statically to 8 for the follow section of the code and just watched them walk, while the effect was nearly not noticeable at that speed, if you watched closely, you could see the target ring jitter slightly at a fairly high rate, and beside the shuffling sound of walking slow, there is another "landing" type of sound playing repeatedly. I've noticed that sound in the normal follow speed. I haven't noticed that with anything else that moves in the game. I imagine as the speed scales up so does this "jitter".

[ZombieSoul]

I enabled Mercs added a Tank(warrior) merc and spawned a warrior bot, same race etc and made a little video of what I am seeing:
https://youtu.be/C_pK_ORv41M

The encoding is terrible but if you watch the bot, it jitters, but the merc seems pretty good.
This is with both pathfinding and the extra pos updates enabled. pathing is understandable, but I can't understand the difference. They can join groups, fight, cast spells and have very similar movement code.

Does the client really handle bots that differently? Are you seeing something similar or is something wrong on my end?

If you want a more clear video I can provide the source mp4, but I think you can see what I am trying to describe.

EDIT: Link updated to try to avoid terrible ads for those that don't have ad-blockers

[Uleat]

It's not really that the client handles other clients differently..but, there are more expectations for them (npcs can't go link-dead...)


Those notes that you saw were most likely mine after I made the first adjustments.

You probably want to go back to before those initial changes were made: https://github.com/EQEmu/Server/blob/d8519bc270ad932047679fa1c2c86870ff29a176/zone/bot.cpp#L2488

[Uleat]

Thanks for your help in tracking down the movement issue!

[ZombieSoul]

I was glad to help, if anyone is following this you should check out the recent changes, the the rubber band has been broken by the awesome work of Uleat

[ZombieSoul]

Not sure if I should keep this thread going, but this bugged me.
This seems like a simple fix, just emulated what they do with mercs

diff --git a/zone/client_packet.cpp b/zone/client_packet.cpp
index 5411dbf7..143bb381 100644
--- a/zone/client_packet.cpp
+++ b/zone/client_packet.cpp
@@ -13043,7 +13043,11 @@ void Client::Handle_OP_TargetCommand(const EQApplicationPacket *app)
}
if (GetGM() || RuleB(Spells, AlwaysSendTargetsBuffs) || nt == this || inspect_buffs || (nt->IsClient() && !nt->CastToClient()->GetPVP()) ||
(nt->IsPet() && nt->GetOwner() && nt->GetOwner()->IsClient() && !nt->GetOwner()->CastToClient()->GetPVP()) ||
- (nt->IsMerc() && nt->GetOwner() && nt->GetOwner()->IsClient() && !nt->GetOwner()->CastToClient()->GetPVP()))
+ (nt->IsMerc() && nt->GetOwner() && nt->GetOwner()->IsClient() && !nt->GetOwner()->CastToClient()->GetPVP())
+#ifdef BOTS
+ ||(nt->IsBot() && nt->GetOwner() && nt->GetOwner()->IsClient() && !nt->GetOwner()->CastToClient()->GetPVP())
+#endif
+ )
nt->SendBuffsToClient(this);
}
else


buffs are able to be seen when targeting bots, one more thing off my list, now time for bed

EDIT: So since work was slow and for completeness - the following allows you to click buffs off of the bot and the window updates when they are removed or added. Would really like to find a cleaner way to match the entityID to the bot- but this works

diff --git a/zone/client_packet.cpp b/zone/client_packet.cpp
index 5411dbf7..a2d3a539 100644
--- a/zone/client_packet.cpp
+++ b/zone/client_packet.cpp
@@ -3899,7 +3899,20 @@ void Client::Handle_OP_BuffRemoveRequest(const EQApplicationPacket *app)
m = this;
else if (brrs->EntityID == GetPetID())
m = GetPet();
-
+#ifdef BOTS
+ else if (!m) {
+ std::list<Bot*> BotList = entity_list.GetBotsByBotOwnerCharacterID(Character ID());
+ for (std::list<Bot*>::iterator itr = BotList.begin(); itr != BotList.end(); ++itr) {
+ Bot* tempBot = *itr;
+ if (tempBot) {
+ if (brrs->EntityID == tempBot->GetID()) {
+ m = tempBot;
+ }
+ }
+ }
+ }
+#endif
+
if (!m)
return;

@@ -13043,7 +13056,11 @@ void Client::Handle_OP_TargetCommand(const EQApplicationPacket *app)
}
if (GetGM() || RuleB(Spells, AlwaysSendTargetsBuffs) || nt == this || inspect_buffs || (nt->IsClient() && !nt->CastToClient()->GetPVP()) ||
(nt->IsPet() && nt->GetOwner() && nt->GetOwner()->IsClient() && !nt->GetOwner()->CastToClient()->GetPVP()) ||
- (nt->IsMerc() && nt->GetOwner() && nt->GetOwner()->IsClient() && !nt->GetOwner()->CastToClient()->GetPVP()))
+ (nt->IsMerc() && nt->GetOwner() && nt->GetOwner()->IsClient() && !nt->GetOwner()->CastToClient()->GetPVP())
+#ifdef BOTS
+ ||(nt->IsBot() && nt->GetOwner() && nt->GetOwner()->IsClient() && !nt->GetOwner()->CastToClient()->GetPVP())
+#endif
+ )
nt->SendBuffsToClient(this);
}
else
diff --git a/zone/spell_effects.cpp b/zone/spell_effects.cpp
index a2841ee8..c6182bfe 100644
--- a/zone/spell_effects.cpp
+++ b/zone/spell_effects.cpp
@@ -4156,7 +4156,11 @@ void Mob::BuffFadeBySlot(int slot, bool iRecalcBonuses)
SendPetBuffsToClient();
}
if((IsClient() && !CastToClient()->GetPVP()) || (IsPet() && GetOwner() && GetOwner()->IsClient() && !GetOwner()->CastToClient()->GetPVP()) ||
- (IsMerc() && GetOwner() && GetOwner()->IsClient() && !GetOwner()->CastToClient()->GetPVP()))
+ (IsMerc() && GetOwner() && GetOwner()->IsClient() && !GetOwner()->CastToClient()->GetPVP())
+#ifdef BOTS
+ || (IsBot() && GetOwner() && GetOwner()->IsClient() && !GetOwner()->CastToClient()->GetPVP())
+#endif
+ )
{
EQApplicationPacket *outapp = MakeBuffsPacket();

diff --git a/zone/spells.cpp b/zone/spells.cpp
index f37f2fc5..08374c85 100644
--- a/zone/spells.cpp
+++ b/zone/spells.cpp
@@ -3291,7 +3291,11 @@ int Mob::AddBuff(Mob *caster, uint16 spell_id, int duration, int32 level_overrid
SendPetBuffsToClient();

if((IsClient() && !CastToClient()->GetPVP()) || (IsPet() && GetOwner() && GetOwner()->IsClient() && !GetOwner()->CastToClient()->GetPVP()) ||
- (IsMerc() && GetOwner() && GetOwner()->IsClient() && !GetOwner()->CastToClient()->GetPVP()))
+ (IsMerc() && GetOwner() && GetOwner()->IsClient() && !GetOwner()->CastToClient()->GetPVP())
+#ifdef BOTS
+ || (IsBot() && GetOwner() && GetOwner()->IsClient() && !GetOwner()->CastToClient()->GetPVP())
+#endif
+ )
{
EQApplicationPacket *outapp = MakeBuffsPacket();




It probably could use some improvement but all the basics are there, Mercs are most of the way there, and if live lets you click of buffs on mercs would just need to update the entityID check in Client::Handle_OP_BuffRemoveRequest, the rest is already there.

EDIT 2 = I was looking over the code, might want to add a break in that loop? I wasn't thinking of someone having 70+ bots. The more I look at it I want to make a function to check for a bot with the entityID belonging to this client and Keep most of that in bot.cpp

[Uleat]

I tweaked that submission a little bit..but, it is in now.


Note: Right-clicking bot buffs does not allow for removing them..but, just a standard left-click will.

[Garudan]

Hi, since I am still experiencing this Rubber Band to an extreme extend, I wanted to ask if it is possible for a user, to just have them like they were before, i.e. running through walls no matter what, but w/o the rubber band. That way at least they were playable. now one has to summon them for every single meele fight.


One thought out of the box on the rubber band (I have not dived into the code yet):
might it be possible, that they are simply coded in a way, that they are permanently over encumbered? This would explain why the client thinks they should be faster (calculating not over encumbered).

[Garudan]

At this point i would be happy, if some1 could give me a hint, how I make the bots just warp instead of trying to go with the pathing algo.

[Uleat]

I have not loaded any bots since the newest navmesh code updates went live...

The only conditions that 'should' cause failed engagement:

- Target is initially farther away than the leash distance (bots do not engage)
- Target/Leash Owner moves beyond leash distance (bots drop engagement..mob may still have aggro, however)
- Bot and leash owner lose LoS with target (if not engaged)
- Leash owner turns off auto-attack before engagement

It's been awhile since I've looked at the changes and I'm going off of recall.

Is there a specific zone(s) that this occurs in? Or is it a generalized problem?


I've been letting the recent inventory and navmesh changes bake, and trying to finish up a few smaller projects..

..but, I do plan on a more comprehensive rework of the bot ai.

They should behave more like pets by default..but, will have per-owner settings that can tweak overall bot behavior.

[phantomghost]

At this point i would be happy, if some1 could give me a hint, how I make the bots just warp instead of trying to go with the pathing algo.

I have ^summon spawned in my ^attack spawned hotkey in the event the bots get stuck... although they have actually been following very well for me.

[Uleat]

Ok..I loaded up my bots last night and there are some definite movement issues.

AI rework is #3 on my list now - first two are small projects that just need to be finished.

[superpally1]

When bots are summoned on my server, they appear and if you stand still for about 10 -20 seconds the bots vanish. If you move they reappear. Stop again they vanish again. I am using fairly new source, i updated it about a week ago.
Any idea the reason for this? It is quite annoying especially if you are trying to give a piece of gear to one of the bots.

[Uleat]

Bot behavior was changed when navmesh was updated a few months ago.

It's on my immediate list...

[superpally1]

oh i see. thank you for the reply and thank you for all your hard work!

[phantomghost]

When bots are summoned on my server, they appear and if you stand still for about 10 -20 seconds the bots vanish. If you move they reappear. Stop again they vanish again. I am using fairly new source, i updated it about a week ago.
Any idea the reason for this? It is quite annoying especially if you are trying to give a piece of gear to one of the bots.

Use ^invgive as an alternative.

[Uleat]

I have tracked down the issue to a small range of changes back in early November.

I'll post again as soon as I find and correct the issue so that interested parties can update their binaries.

[Proxeeus]

I have tracked down the issue to a small range of changes back in early November.

I'll post again as soon as I find and correct the issue so that interested parties can update their binaries.

Thank you so much for taking care of this ! <3

[Uleat]

Ok, anyone who updated their binaries after the first week of November, 2018, and are experiencing bots not moving after spawning and grouping..

..there is a fix for this in the current master branch.

Glitchy bot movement is still in-work...

[Uleat]

More bot movement fixes today..

- Movement speed is sync'd properly

- Animation glitches when stopping have been resolved

- Bots no longer disappear after 10 seconds of inactivity


Demo: https://youtu.be/LWQwxpwn9Gw

[superpally1]

Very nice, thankyou ! I will compile this update as soon as I get home!

[Proxeeus]

This looks soooo slick. Compiling this asap!
Thank you Uleat!!

[Uleat]

If you guys run into any issues, let me know.

This appears to fix most issues not related to actual ai behavior.

And please thank KLS for the new movement manager .. I just hooked the bots up to it :)

[Uleat]

I just pushed an update to address any lingering ghosting of bots.