1
0
Fork 0

(svn r26372) -Doc [FS#5927]: Typos.

release/1.4
frosch 2014-02-24 18:14:53 +00:00
parent a32d18cbb9
commit 440168cfb2
1 changed files with 13 additions and 7 deletions

View File

@ -21,12 +21,12 @@ Table of contents
1.1) OpenTTD multiplayer architecture 1.1) OpenTTD multiplayer architecture
---- -------------------------------- ---- --------------------------------
OpenTTD has a huge gamestate, which changes all of the time. OpenTTD has a huge gamestate, which changes all of the time.
The savegame containts the complete game state at a specific point The savegame contains the complete gamestate at a specific point
in time. But this state changes completely each tick: Vehicles move in time. But this state changes completely each tick: Vehicles move
and trees grow. and trees grow.
However, most of these changes in the gamestate are deterministic: 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 the same way, and trees always grow the same.
In OpenTTD multiplayer synchronisation works by creating a savegame In OpenTTD multiplayer synchronisation works by creating a savegame
@ -106,10 +106,11 @@ Table of contents
The important thing here is: The detection of the Desync is The important thing here is: The detection of the Desync is
only an ultimate failure detection. It does not give any only an ultimate failure detection. It does not give any
indication on when the Desync happened. The Desync may after 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 up to now. The checksum may have matched 10 times or more
since the Desync happend, and only now the Desync has spiraled 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 1.3) Typical causes of Desyncs
---- ------------------------- ---- -------------------------
@ -119,13 +120,18 @@ Table of contents
gamestate is not saved in the savegame. gamestate is not saved in the savegame.
- Some information which affects the progression of the - Some information which affects the progression of the
gamestate is not loaded from the savegame. 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. - The gamestate does not behave deterministic.
- Cache mismatch: The game logic depends on some cached - Cache mismatch: The game logic depends on some cached
values, which are not invalidated properly. This is values, which are not invalidated properly. This is
the usual case for NewGRF-specific Desyncs. the usual case for NewGRF-specific Desyncs.
- Undefined behaviour: The game logic performs multiple - Undefined behaviour: The game logic performs multiple
things in an undefined order or with an undefined 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 gamestate is modified when it shall not be modified.
- The test-run of a command alters the gamestate. - The test-run of a command alters the gamestate.
- The gamestate is altered by a player or script without - The gamestate is altered by a player or script without