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.) |
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.
|
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. |
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.
|
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. |
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 |
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".
|
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 |
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 |
Thanks for your help in tracking down the movement issue!
|
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
|
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 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 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 |
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. |
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). |
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.
|
All times are GMT -4. The time now is 12:25 AM. |
Powered by vBulletin®, Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.