Proposal:Sync worlds: Difference between revisions

From Multi Theft Auto: Wiki
Jump to navigation Jump to search
(Created page with "Currently we sync pretty much everything to everyone. We do reduce the quality of the sync somewhat for distant players, but often this isn't relevant. Here's a proposed solutio...")
 
m (Added template outdated...)
 
(3 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{Outdated|}}
Currently we sync pretty much everything to everyone. We do reduce the quality of the sync somewhat for distant players, but often this isn't relevant.
Currently we sync pretty much everything to everyone. We do reduce the quality of the sync somewhat for distant players, but often this isn't relevant.


Line 7: Line 9:
* These can work alongside dimensions.  
* These can work alongside dimensions.  
* Each dimension is in exactly one sync world (there's one by default that all dimensions are in).  
* Each dimension is in exactly one sync world (there's one by default that all dimensions are in).  
* Players in a sync world receive updates from all the other players in that sync world.  
* Players in a sync world receive updates from all the elements that change in that sync world.  
* Elements not in the sync world the player is in aren't synced.  
* Elements not in the sync world the player is in aren't synced.  
* When a player switches between two sync worlds, all the elements that have been modified since they were last in that sync world are sent to that client.
* When a player switches between two sync worlds, all the elements that have been modified since they were last in that sync world are sent to that client.
Line 19: Line 21:
* Need to consider the variety of ways that elements are synced - keysync, packets, RPC etc.
* Need to consider the variety of ways that elements are synced - keysync, packets, RPC etc.
* Add a function, e.g. 'setDimensionSyncWorld' to specify the sync world a dimension belongs in.
* Add a function, e.g. 'setDimensionSyncWorld' to specify the sync world a dimension belongs in.
* Need to bear in mind that the relevant client-side events should be triggered
* Need to consider elements that are deleted? Maybe keep a per-sync world list of deleted element ids along with timestamps. Or just delete them on every client? Or something else.
[[Category:Proposal]]

Latest revision as of 17:39, 11 November 2011

Dialog-information.png This article is (partially) outdated and the information may no longer apply.

Currently we sync pretty much everything to everyone. We do reduce the quality of the sync somewhat for distant players, but often this isn't relevant.

Here's a proposed solution someone might like to implement to greatly reduce the bandwidth and CPU usage of servers and clients, when servers are configured to support it.

Solution

  • Add the concept of 'sync worlds' (need a better name).
  • These can work alongside dimensions.
  • Each dimension is in exactly one sync world (there's one by default that all dimensions are in).
  • Players in a sync world receive updates from all the elements that change in that sync world.
  • Elements not in the sync world the player is in aren't synced.
  • When a player switches between two sync worlds, all the elements that have been modified since they were last in that sync world are sent to that client.
  • During the 'resync', a loading screen or indicator is shown.
  • The default behaviour would not use this new feature.

Technically

  • Add a list that stores 'sync world id' and a timestamp to the player class. This stores the last time a player was sent information about an element in that particular sync world.
  • Add a timestamp to each element that stores the last time that element was updated
  • When we modify an element, update the timestamp
  • Need to consider the variety of ways that elements are synced - keysync, packets, RPC etc.
  • Add a function, e.g. 'setDimensionSyncWorld' to specify the sync world a dimension belongs in.
  • Need to bear in mind that the relevant client-side events should be triggered
  • Need to consider elements that are deleted? Maybe keep a per-sync world list of deleted element ids along with timestamps. Or just delete them on every client? Or something else.