mirror of https://github.com/OpenTTD/OpenTTD.git
(svn r26372) -Doc [FS#5927]: Typos.
This commit is contained in:
parent
a32d18cbb9
commit
440168cfb2
|
@ -20,13 +20,13 @@ Table of contents
|
|||
|
||||
1.1) OpenTTD multiplayer architecture
|
||||
---- --------------------------------
|
||||
OpenTTD has a huge game state, which changes all of the time.
|
||||
The savegame containts the complete game state at a specific point
|
||||
OpenTTD has a huge gamestate, which changes all of the time.
|
||||
The savegame contains the complete gamestate at a specific point
|
||||
in time. But this state changes completely each tick: Vehicles move
|
||||
and trees grow.
|
||||
|
||||
However, most of these changes in the gamestate are deterministic:
|
||||
Without a player interfering a vehicle follows it's orders always
|
||||
Without a player interfering a vehicle follows its orders always
|
||||
in the same way, and trees always grow the same.
|
||||
|
||||
In OpenTTD multiplayer synchronisation works by creating a savegame
|
||||
|
@ -60,7 +60,7 @@ Table of contents
|
|||
check simple preconditions. (Just to give the client an
|
||||
immediate response without bothering the server and waiting for
|
||||
the response.) The test-run may not actually change the
|
||||
game state, all changes must be discarded.
|
||||
gamestate, all changes must be discarded.
|
||||
- If the local test-run succeeds the command is sent to the server.
|
||||
- The server inserts the command into the command queue, which
|
||||
assigns a network frame to the commands, i.e. when it shall be
|
||||
|
@ -106,10 +106,11 @@ Table of contents
|
|||
The important thing here is: The detection of the Desync is
|
||||
only an ultimate failure detection. It does not give any
|
||||
indication on when the Desync happened. The Desync may after
|
||||
all occured long ago, and just did not affect the checksum
|
||||
all have occured long ago, and just did not affect the checksum
|
||||
up to now. The checksum may have matched 10 times or more
|
||||
since the Desync happend, and only now the Desync has spiraled
|
||||
enough to finally affect the checksum.
|
||||
enough to finally affect the checksum. (There was once a desync
|
||||
which was only noticed by the checksum after 20 game years.)
|
||||
|
||||
1.3) Typical causes of Desyncs
|
||||
---- -------------------------
|
||||
|
@ -119,13 +120,18 @@ Table of contents
|
|||
gamestate is not saved in the savegame.
|
||||
- Some information which affects the progression of the
|
||||
gamestate is not loaded from the savegame.
|
||||
This includes the case that something is not completely
|
||||
reset before loading the savegame, so data from the
|
||||
previous game is carried over to the new one.
|
||||
- The gamestate does not behave deterministic.
|
||||
- Cache mismatch: The game logic depends on some cached
|
||||
values, which are not invalidated properly. This is
|
||||
the usual case for NewGRF-specific Desyncs.
|
||||
- Undefined behaviour: The game logic performs multiple
|
||||
things in an undefined order or with an undefined
|
||||
result.
|
||||
result. E.g. when sorting something with a key while
|
||||
some keys are equal. Or some computation that depends
|
||||
on the CPU architecture (32/64 bit, little/big endian).
|
||||
- The gamestate is modified when it shall not be modified.
|
||||
- The test-run of a command alters the gamestate.
|
||||
- The gamestate is altered by a player or script without
|
||||
|
|
Loading…
Reference in New Issue