Movement Issues thread

[John Adams]

Jab, since you have taken an interest in movement (related to combat or otherwise), here is my list of previous bugs related to movement.

This older thread is LOADED with bugs related to combat and movement (warping, ghosting mostly). Scan backwards from this post, you'll see extensive lists by me and Donnarien (some may already be resolved).
http://eq2emulator.net/phpBB3/viewtopic ... 469#p15469


Bug about wanderers who, once attacked, never continue on their original path. Like roving guards who attack rats, then stick there forever after the fight (still an issue?)
http://eq2emulator.net/phpBB3/viewtopic ... 574#p18574


One of the bugs I think you are fixing right now --
http://eq2emulator.net/phpBB3/viewtopic ... 429#p23429


This one is actually an "immersion bug" hah, kinda throws off the whole mojo of the game when a Running NPC hits a new trajectory and halts for 2-5 seconds even though delay=0.
http://eq2emulator.net/phpBB3/viewtopic ... 073#p17073


Vertical movement has ALWAYS been crappy. We never did figure this one out, ever. This is for players that jump, mostly.
http://eq2emulator.net/phpBB3/viewtopic ... 996#p23996


There are more, I'm sure. But forum Search is not revealing anything else.

[Jabantiz]

I meant to post info on movement (I could have swore that I did) when I was looking into it, I obviously never did though so will post the main things I noticed (this is based off memory though).

When a mob walks around all that is sent is a packet to control the movement, not an update to the spawn struct, the problem is I don't think the spawns location (x, y, z) is updated on the server for a while, it just sends the packet. Also when mobs are resent, do to the player leveling, the location part is completely skipped (as well as another part but can't remember what it was) causing spawns to port back to there spawn location for the client that just leveled.

I also noticed that the ghost opcodes don't use structs the same way as the rest of the code, was this by design or were spawns implemented before the struct system was finished?

[John Adams]

I also noticed that the ghost opcodes don't use structs the same way as the rest of the code, was this by design or were spawns implemented before the struct system was finished?

Excellent research again, Jab. As for the spawns, yes I am sure they were one of the first things implemented very early on, and LE might have changed how structs work since the beginning. If there is room for improvement, let's take a look at it.

[Jabantiz]

I finally found where the position is updated for moving spawns on the server and in the end it all relys upon the following

Code: Select all

data->end_time = (int32)(data->start_time + ((((float)distance)/(float)speed)*1000));

The way movement works (from what I can tell) is the server sends a packet to tell the client is moving, in this packet it has the destination location the speed and the next destination (if any), the client then takes that info and moves the spawn. The above code determines how long it will take for the spawn to reach the destination on the server and is used in calculating the position. If it does not match the time it takes the client to move the spawn we get that porting effect.

Currently it appears that the calculation is wrong, the time it comes up with is longer then what the client comes up with, causing the mob to port back when attacked, this may also be the reason for mobs standing at there location and not advancing on when it is 0 delay, the spawn actually hasn't arrived at its location on the server yet even though the client shows it standing there and waiting.

I did some test with a player on a flat surface (bridge to qeynos in antonica) and changed my speed ran for aprox. 1 sec and got some values, these will not be accurate though and I am not even sure that the speed the player uses is the same speed that spawns use. I got the following reulsts though.

Code: Select all

speed          distance
1              9.8310
2              10.6195
5              10.6461
10             11.0577
20             12.2894
40             14.8420

Again this was all for aprox 1 sec, was done manually so not going to be accurate. If the speed value works the same for the player and npcs, and if we can figure out an equation that is close to the above results, then our spawn movement should be improved, this is also where I satart to suck so will need some help figuring out the equation.

EDIT: I figured out how to get an equation from open office and it gave me 0.1250311702 * speed + 9.8327662134 so i figured I would try it out, have gotten mixed results at best, in ruins it looked great on the orc that runs in a loop non stop, on roaming guards not so much. It seems like it works good on mobs with a speed of 4, most have a speed of 2 however and in that case it looks like the equation is to fast (they port ahead). Will do some more tests but right now it appears that the speed variable for npc's is handled diffrently then speed variable for players.

EDIT2: After searching through the code more I stumbled across the packet code that uses rules (code John pointed out to me a while ago I just forgot about since it had been so long) to modify the speed value. So speed variable is used diffrently for players and spawns. Going to have to figure out a way to do simple tests like I did for the player and try to get a new equation that way.

EDIT3: I made a simple spawn script that upon hail would move the npc a short distance, once I timed that I changed the speed in the script and /reloaded every thing (thank god for in game macros). Once I got all the data and did all the math I put it into open office to get the equation again and came up with 1.4694381818 * speed - 0.18582 I tried this equation and it seemed to work great for the gatherer person in queens colony, as soon as she stopped moving she did her animation, it seems that the further the distance the worse it gets however. It appears to start to lag behind the client (port backwards). I will try to dig out an actual stop watch to try and get my timing more accurate as well as doing more tests with longer distances.

[Jabantiz]

Did some more tests with an actual stop watch and while it won't be 100% it is the closest I can get it, did tests for speeds 1-10 at distance of 21.88 and 58.46 and came up with the following equation, 1.1043506061 * speed + 0.1832966667, I also noticed how heavily movement on the server was depended on calculating times, but it would only update and check times once every second.

With this new equation, some code I borrowed from EQEmu, removing the dependency on calculated times, and removing the timer so it updates every time the spawn loop loops (10 mili sec) I got spawns on a movement loop working great. There is no porting around when you hail them, they obey the delays at the waypoints, no more standing around waiting at a waypoint with 0 delay set. However combat movement is iffy at best. Spawns will get stuck in a spot and all jerky (run like a foot, if that, and port back non stop).

Combat movement (handled in npc_ai.cpp) has its own timers separate from the movement loop timers, I attempted to change those timers lowering them from 2000 or 500 to 10 and while the results worked rather well in queens colony, just a few minor issues left, the number of packets being sent to the client went through the roof. I didn't notice this in queens colony as every thing still ran smoothly however when I went to the ruins it was noticible. I need to find a new solution for combat movement, perhaps getting them to work with the other movement code instead of on there own, and maybe adding the movement timer back in but at about 100mili sec instead of 1 sec.

[John Adams]

Great work as usual, Jab. I did not realize movement was so complex. I thought it was as simple as, start at x,y,z, go to x,y,z at this speed. Be done with it. I hadn't considered internet latency, but it sure explains the warping. At least we know the server updates the client properly - even if it results in a warp

How do all these discoveries line up with client to client visual movements? Assuming this is all on the DoV client now, I am curious about that "predictive movement" thing that keeps coming up.

[Jabantiz]

These were done in DoV, have yet to test other clients. This is also all for NPC movement only and will not effect client movement. I could try to update clients using DoV for thoose that are not but that might be rather tricky, and it is rather low on my priority list due to the fact we have virtually no players.

[John Adams]

I'm a player.

Or so I've been told

[Jabantiz]

I got all the issues worked out an imo it is working great. Patrolling mobs obey the delay at waypoints, so a delay of 0 and the spawn will keep on going, client and server now move the spawn at almost the exact same speed (on longer distances there may be a very very slight port when hailed, nothing major like it was). I modified npc_ai a lot so combat movement and return to spawn point are called with the movement loop code making them a lot smoother then they were. I also put the timer back in but have it set to 50 (20 times a second) instead of 1000 (once a second) and without the timer the update was about 10 (100 times a second). These changes are also identical on a DoV and SF clients.

I put my server (Silent Destiny) up for public login and will leave it up for the rest of the night so others can check the changes. Will work on cleaning up the code and if no issues pop up I will commit it.

[xinux]

Nice work Jab

[alfa]

Well done again Jab, there is a big impact on performance due to you reduce the timer ?

[Jabantiz]

The server runs smoothly on my end no noticible change in performance. The only thing I have noticed that has prevented me from submitting the code is the ruins zone, when that zone first starts up, or a zone wide repop the client seems to be hit hard with packets and all sorts of issues show up (like the client is struggling to process the packets) if you do a /who the command hits the server right away, the lag before the client shows the results is large though.

The best way to see this is zone a client to ruins and wait a min or so until the initial combat clears up then zone another client in, go back to the first and do /depop it will take forever for the zone to start clearing on the first client but on the second client it starts to clear right away, my best guess as to why is the first client has a crap load of packets it is trying to sort through and the packets to clear the zone are now at the end of the list, has to go through all the others first (this is just a theory).

Ruins always had issues like this when it first starts up, it just seems to stand out more now and last longer. As soon as I figure out a solution to this I will commit my code.

[John Adams]

Jab, did you say you left these two rules in the code for speed calcs?

Code: Select all

	RULE_INIT(R_Spawn, SpeedMultiplier, "300"); // note: this value was 1280 until 6/1/2009, then was 600 til Sep 2009, when it became 300...?
	RULE_INIT(R_Spawn, SpeedRatio, "0");		// was 1280/7.5 and 600/7.5 until it became 300.

If so, and these movement fixes stick, we should tweak those two values to see how to get the spawns to not move so fast. They have been "run-walking" for a long time, maybe since SF clients. See by my comments that the values changed dramatically client to client.

Also, the movement speed in the look LUA is supposed to take a Float, but I don't think it ever worked right. That, or the .1-.9 speed changes were so small they weren't noticeable. It'll be great to see Movement finalized.

Great work!

[Jabantiz]

I have not touched or used those values in any of my speed calcs, however those control the speed on the client, changing them will result in the speed on the client and server to desync. I have no idea where those values came from but as of right now both SF and DoV show the same results, I haven't tested any older clients though.

[John Adams]

We're soon to drop SF anyway, so as long as it works on DoV, I'm happy.

Thing is, the speed of our movement loops has pigs and rats running around like they are on crack. Was hoping it was a simple tweak to these values, and not have to touch 1,000 spawn scripts.