Send/Receive

[Richardo]

Would it be simple to request more/send more packets of player positions to and from the server in order to make players move around more smoothly?

When a player enters a zone and you're looking at him, they pretty much warp all over the place whenever they're moving. If they strafe, they don't move left and right but simple disappear slightly to the left and right. Perhaps it could be introduced as a variable in the database (send/request) limits?

Sorry I don't know how to properly explain this in 'l33t c0d3 sp3@k'.

[EvoZak]

Yeah, it's not just the PCs, it's pretty much everything that paths. Very odd and annoying. If I come across a setting I'll post it up.

[paaco]

Forgive me if I'm wrong. I suck at C++ but this looks like the piece of code you are looking for.
Client_process.cpp
Line 475

SendPosUpdate(2);

                        // Send a position packet every 8 seconds - if not done, other clients
                        // see this char disappear after 10-12 seconds of inactivity
                        if (position_timer_counter >= 36) { // Approx. 4 ticks per second
                                entity_list.SendPositionUpdates(this, pLastUpdateWZ, 500, target, true);
                        /* if (position_timer_counter >= 3) { // Send every 750ms?
                                //Image (2k5): The trick of stopping MQ map without screwing up client updates, shorter distances, faster updates, however if its an admin we can send further updates
                                if(Admin() > 80)
                                        entity_list.SendPositionUpdates(this, pLastUpdateWZ, 450, 0, true);
                                else
                                        entity_list.SendPositionUpdates(this, pLastUpdateWZ, 150, 0, true);
                                }

[trevius]

It is pretty easy to adjust how often the updates are sent, but I would be very careful if you are trying to tune it at all. Position updates make up a large percentage of the total traffic being uploaded to clients from the server, so it can use up your bandwidth extremely fast. There is a rule for adjusting the zone wide updates, but you definitely don't want those coming in too fast as it would lag out the server quickly. Currently, anyone within a certain distance of you should get very frequent updates if they are close. If they are within a range of 50 from you, you get quite a few updates every second already.

[Richardo]

Well, bandwidth really isn't an issue on my part. Neither is hardware. I am aware of the impact of performance it can cause. I'd love to have smooth running characters rather that jagged warpy player movement you see so frequently.

[paaco]

What I am wondering is just how low you can you go without a noticeable performance hit? How long ago was this piece of code written? When the project first started servers were much slower than they are now. What we are currently running on is dual Opteron 250's and a 100mbit connection with 3TB's of monthly bandwidth. Unless we get a huge playerbase I can't see us using 3TB in a month even if we half the update ratio. I guess what I am asking is, on current available hardware, or something close to my servers stats. Will halving the update ratio have a noticeable impact on the server with say...100 players online.

Server stats Exactly are:
Dual Opteron 250's
Windows 2003 Server Enterprise Edition
4 Gigs of Ram
10k RPM SCSI HD
100 Mbit Connection. ( Speed Tests I have run are roughly about 40000 kbit Down and 50k-60k kbit up on average )

[EvoZak]

Originally Posted by trevius

Currently, anyone within a certain distance of you should get very frequent updates if they are close. If they are within a range of 50 from you, you get quite a few updates every second already.

I find that interesting. If an NPC walks right by me it is still jumpy as all hell. Not saying you're wrong, just that it still seems "not enough".

[trevius]

Maybe I am not understanding what you are saying. I see no jumpiness or lag on my server at all. Your server may be having another issue. Have you tried playing on other servers? Also, could you describe the jumpiness? It sounds like you might have a z-axis issue or something from what you guys are describing.

As for the code to do position updates, yes it is old, but it is also much bulkier than it should be. If anything, position updates need to be tuned down (less often) in some situations. I have looked into optimizing position updates, but I haven't had time lately to really work on it at all. It would probably take someone above my code level to really optimize them properly.

I know that one of the revision of code releases included something that basically broke spawn updates, so if you guys are running that revision, you need to update your revision to stop it from happening. I don't recall exactly what release it was, but it was a little before revision 150.

[trevius]

If update manager is being used on your server, you should be able to edit this code:

updatemgr.cpp

//squared distances for each level
//these values are pulled out of my ass, should be tuned some day
const float UpdateManager::level_distances2[UPDATE_LEVELS]
	= { 50*50, 250*250, 500*500, 800*800 };
	
//delay between sending packets in each level, in ms
//its best if they are all multiples of UPDATE_RESOLUTION
//these values are pulled out of my ass, should be tuned some day
const int32 UpdateManager::level_timers[UPDATE_LEVELS+1]
	= { UPDATE_RESOLUTION,		//.3s
		2*UPDATE_RESOLUTION, 	//.6s
		3*UPDATE_RESOLUTION,	//.9s
		9*UPDATE_RESOLUTION,	//~2s
		34*UPDATE_RESOLUTION	//~10s
	  };

Try something like this for highly increased updates:

//squared distances for each level
//these values are pulled out of my ass, should be tuned some day
const float UpdateManager::level_distances2[UPDATE_LEVELS]
	= { 250*250, 450*450, 800*800, 1200*1200 };
	
//delay between sending packets in each level, in ms
//its best if they are all multiples of UPDATE_RESOLUTION
//these values are pulled out of my ass, should be tuned some day
const int32 UpdateManager::level_timers[UPDATE_LEVELS+1]
	= { UPDATE_RESOLUTION,		//.3s
		2*UPDATE_RESOLUTION, 	//.6s
		3*UPDATE_RESOLUTION,	//.9s
		4*UPDATE_RESOLUTION,	//~2s
		12*UPDATE_RESOLUTION	//~10s
	  };

I really don't know why you would possibly need more than 3 position updates per second. I have to guess that your issue is related to something completely different than position updates, unless you are running that bad revision version. If you try this, don't complain when your server performance sucks :P

[MNWatchdog]

You would probably get much better performance running on a Linux system too.