|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Development::Bots Forum for bots. |
02-25-2017, 07:07 PM
|
|
Developer
|
|
Join Date: Apr 2012
Location: North Carolina
Posts: 2,815
|
|
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.)
__________________
Uleat of Bertoxxulous
Compilin' Dirty
|
02-25-2017, 09:02 PM
|
|
Sarnak
|
|
Join Date: Jan 2017
Posts: 31
|
|
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.
|
02-25-2017, 09:13 PM
|
|
Developer
|
|
Join Date: Apr 2012
Location: North Carolina
Posts: 2,815
|
|
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.
__________________
Uleat of Bertoxxulous
Compilin' Dirty
|
02-25-2017, 09:32 PM
|
|
Sarnak
|
|
Join Date: Jan 2017
Posts: 31
|
|
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.
|
02-25-2017, 09:49 PM
|
|
Developer
|
|
Join Date: Apr 2012
Location: North Carolina
Posts: 2,815
|
|
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.
__________________
Uleat of Bertoxxulous
Compilin' Dirty
|
02-26-2017, 01:01 AM
|
|
Sarnak
|
|
Join Date: Jan 2017
Posts: 31
|
|
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/sh...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
|
02-26-2017, 01:55 AM
|
|
Sarnak
|
|
Join Date: Jan 2017
Posts: 31
|
|
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".
|
02-26-2017, 02:06 PM
|
|
Sarnak
|
|
Join Date: Jan 2017
Posts: 31
|
|
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
|
02-26-2017, 08:58 PM
|
|
Developer
|
|
Join Date: Apr 2012
Location: North Carolina
Posts: 2,815
|
|
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.../bot.cpp#L2488
__________________
Uleat of Bertoxxulous
Compilin' Dirty
|
02-27-2017, 11:27 PM
|
|
Developer
|
|
Join Date: Apr 2012
Location: North Carolina
Posts: 2,815
|
|
Thanks for your help in tracking down the movement issue!
__________________
Uleat of Bertoxxulous
Compilin' Dirty
|
02-28-2017, 12:23 AM
|
|
Sarnak
|
|
Join Date: Jan 2017
Posts: 31
|
|
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
|
|
|
|
02-28-2017, 01:39 AM
|
|
Sarnak
|
|
Join Date: Jan 2017
Posts: 31
|
|
Seeing Bot buffs in target window
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
Code:
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
Code:
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(CharacterID());
+ 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
Last edited by ZombieSoul; 02-28-2017 at 01:10 PM..
Reason: More stuff
|
|
|
|
03-03-2017, 06:52 PM
|
|
Developer
|
|
Join Date: Apr 2012
Location: North Carolina
Posts: 2,815
|
|
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.
__________________
Uleat of Bertoxxulous
Compilin' Dirty
|
01-17-2019, 06:14 AM
|
Sarnak
|
|
Join Date: Jun 2005
Posts: 38
|
|
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).
|
01-17-2019, 12:00 PM
|
Sarnak
|
|
Join Date: Jun 2005
Posts: 38
|
|
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.
|
Posting Rules
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is Off
|
|
|
All times are GMT -4. The time now is 07:05 AM.
|
|
|
|
|
|
|
|
|
|
|
|
|