View Issue Details

IDProjectCategoryView StatusLast Update
0005743Multi Theft Auto : San AndreasSynchronizationpublic2011-11-29 05:12
ReporterrydenAssigned Toryden 
Status resolvedResolutionfixed 
Product Version1.0.4 
Target Version1.1.1 R2Fixed in Version1.1 
Summary0005743: Optimize the puresync bandwidth usage for entities out of range

Currently MTA is using an average of around 30bytes / second per player that is not in the fast sync range.

This could seem to be really a few, but imagine a server with 200 concurrent players. In the ideal case of being all out of your stream range, this would be 6000bytes/second ~= 6kb/s. If there are 200 players, the server is supporting a load of 1200kb/s ~= 1.1mb/s ~= 9mbps.

Making a new puresync packet that only sends the position and not much more would save a lot of bandwidth.

TagsNo tags attached.


related to 0005169 resolvedccw Optimize puresync and keysync broadcasting 
child of 0006097 resolvedryden Implement light puresync packets 



2011-01-05 07:19

manager   ~~0012445

This is an example of a server with almost 100 concurrent players, in what I had all the players out of my fast sync range:

Packet ID 27 is player puresync, ID 28 is vehicle puresync.


2011-01-05 12:37

developer   ~~0012448

Also I am not sure that we need to send all data in EntityAdd packet. If player won't always receive puresync packets, the data from EntityAdd packet will be outdated.


2011-01-05 15:36

reporter   ~~0012450

Last edited: 2011-01-05 15:44

There is something that would save some bandwidth, too:
If I get it right the puresync is for ALL players within the 320.0f range. But thats not really necessairy. If none of the two players got a sniper, M4, Rocketlauncher, rifle etc. 150.0f should be enough, and even with the AK or M4 players with a distance of more then 210.0f get faded out. So, in other words: When you compare two players, the "biggest gun" wins.

What I've also been thinking about which might not be that good idea is reducing the coordinates stuff. The idea is like that: Instead of using (0,0,0) as "fix point" each player gets his own "fix point".
Explaining it as an algorithm: Player1 is at 2000,2000,20. Server decides the player1's "fix point" is 2000,2000,20 and tells player 1 about it. Player2 is at 2030,2020,10. So instead sending Player1 the coordinates "2030,2020,10" it just sends "30,20,-10" which is a bit shorter. Player1's client adds the coordinates to the fix point and gets the Player2 coordinates.
This fixpoint only has to be updated if the player moves away from it, like, if he is moving 50 units away, it gets updated.
Since the max draw distance for players is 320.0f, and the max distance from the point is 50 units, and also there may be some trouble with lag etc., lets say the new "send coordinates range" is from -512.0f to +512.0f instead of -MAX to +MAX (I dunno how far away a player can be from the middle of the map, lets say if its 65535.0 or something, that would save about 7 bit).

So, putting it short, each player gets a fixpoint and the coordinates of the other players are shortened to the x,y,z-distance to this fixpoint.
So instead of sending a 32-bit-float it would theoretically be enough to send a 16-20 bit float.

Ok, I guess thats totally missing the point. I forgot what to write about fastsync.

Finally the idea came back: Since its the "far away sync", maybe the distance can be defined via exponential growth: i.e. 1.0 means, player2 is 320 units away, 2.0 means player2 is 640 units away, 3.0 means player2 is 1280 units away, 4.0 means player2 is 2560 units away... This would save some bits, too.


2011-04-23 00:12

administrator   ~~0013215

What you're referring to is delta sync. You make the coordinates relative rather than absolute. In the case where a player is at -3000,3000,0, and a remote player is 3000,3000,0 the bandwidth usage actually becomes higher.


2011-04-25 20:52

reporter   ~~0013230

Not really, since every player got his own reference spot.


2011-04-25 22:55

reporter   ~~0013234

I think it should keep being developed to 1.1

MTA is using so much bandwidth and the ping is really unstable


2011-04-25 23:01

manager   ~~0013235

Sounds like a really big task to me and as long as your scripts are optimized it isn't that bad (turning off admin (or changing from refresh time from 50ms to more like 5000ms) can help a lot) as i've been on servers with 128 players and it was smooth but hopefully we'll have some servers in 1.1 with 200+ so only when would this be important and by then hopefully 1.2 will be on the way. Basically I'm saying that an earlier 1.1 is more important than waiting longer in my opinion.

Issue History

Date Modified Username Field Change