mirror of
https://github.com/OpenTTD/OpenTTD.git
synced 2025-01-31 03:12:41 +00:00
Doc: convert some docs to markdown (without rename)
This commit is contained in:
Andy
Charles Pigott
parent
f159d91572
commit
a70b6fcece
@ -1,72 +1,69 @@
|
||||
OpenTTD and strgen
|
||||
# How to compile lang files (OpenTTD and strgen)
|
||||
|
||||
Last updated: 2009-06-30
|
||||
------------------------------------------------------------------------
|
||||
|
||||
## strgen usage
|
||||
|
||||
Table of contents
|
||||
-----------------
|
||||
1.0) strgen usage
|
||||
* 1.1) Examples
|
||||
* 1.2) strgen command switches
|
||||
|
||||
|
||||
1.0) strgen usage
|
||||
---- ------------
|
||||
This guide is only interesting for people who want to alter something
|
||||
themselves without access to translator.openttd.org. Please note that
|
||||
your compiled language file will only be compatible with the OpenTTD version
|
||||
you have downloaded english.txt, the master language file, for. While this is
|
||||
themselves without access to [translator.openttd.org](https://translator.openttd.org/).
|
||||
|
||||
Please note that your compiled language file will only be compatible with the OpenTTD version
|
||||
you have downloaded `english.txt`, the master language file, for. While this is
|
||||
not always true, namely when changes in the code have not touched language
|
||||
files, your safest bet is to assume this 'limitation'.
|
||||
|
||||
As a first step you need to compile strgen. This is as easy as typing
|
||||
'make strgen'. You can download the precompile strgen from:
|
||||
http://www.openttd.org/download-strgen
|
||||
`'make strgen'`. You can download the precompile strgen from:
|
||||
[http://www.openttd.org/download-strgen](http://www.openttd.org/download-strgen)
|
||||
|
||||
strgen takes as argument a txt file and translates it to a lng file, allowing
|
||||
it to be used inside OpenTTD. strgen needs the master language file
|
||||
english.txt to work. Below are some examples of strgen usage.
|
||||
`english.txt` to work. Below are some examples of strgen usage.
|
||||
|
||||
1.1) Examples
|
||||
---- --------
|
||||
Example 1:
|
||||
if you are in the root of your working copy (git repository), you should type
|
||||
strgen/strgen -s lang lang/english.txt
|
||||
to compile englist.txt into english.lng. It will be placed in the lang dir
|
||||
## Examples
|
||||
|
||||
Example 2:
|
||||
you only have the strgen executable (no working copy) and you want to compile
|
||||
### Example 1
|
||||
|
||||
If you are in the root of your working copy (git repository), you should type
|
||||
`./strgen/strgen -s lang lang/english.txt`
|
||||
to compile `english.txt` into `english.lng`. It will be placed in the lang dir.
|
||||
|
||||
### Example 2
|
||||
|
||||
You only have the strgen executable (no working copy) and you want to compile
|
||||
a txt file in the same directory. You should type
|
||||
./strgen english.txt
|
||||
and you will get and english.lng in the same dir
|
||||
`./strgen english.txt`
|
||||
and you will get and `english.lng` in the same dir.
|
||||
|
||||
Example 3:
|
||||
you have strgen somewhere, english.txt in /usr/openttd/lang and you want the
|
||||
### Example 3
|
||||
|
||||
You have strgen somewhere, `english.txt` in `/usr/openttd/lang` and you want the
|
||||
resulting language file to go to /tmp. Use
|
||||
./strgen -s /usr/openttd/lang -d /tmp english.txt
|
||||
`./strgen -s /usr/openttd/lang -d /tmp english.txt`
|
||||
|
||||
You can interchange english.txt to whichever language you want to generate a
|
||||
You can interchange `english.txt` to whichever language you want to generate a
|
||||
.lng file for.
|
||||
|
||||
1.2) strgen command switches
|
||||
---- -----------------------
|
||||
-v | --version
|
||||
## strgen command switches
|
||||
|
||||
`-v | --version`
|
||||
strgen will tell what git revision it was last modified
|
||||
|
||||
-t | --todo
|
||||
`-t | --todo`
|
||||
strgen will add <TODO> to any untranslated/missing strings and use the english
|
||||
strings while compiling the language file
|
||||
|
||||
-w | --warning
|
||||
`-w | --warning`
|
||||
strgen will print any missing strings or wrongly translated (bad format)
|
||||
to standard error output(stderr)
|
||||
|
||||
-h | --help | -?
|
||||
`-h | --help | -?`
|
||||
Print out a summarized help message explaining these switches
|
||||
|
||||
-s | --source_dir
|
||||
`-s | --source_dir`
|
||||
strgen will search for the master file english.txt in the directory specified
|
||||
by this switch instead of the current directory
|
||||
|
||||
-d | --dest_dir
|
||||
`-d | --dest_dir`
|
||||
strgen will put <language>.lng in the directory specified by this switch; if
|
||||
no dest_dir is given, output is the same as source_dir
|
||||
|
||||
@ -1,23 +1,23 @@
|
||||
OpenTTD's admin network
|
||||
# OpenTTD's admin network
|
||||
|
||||
Last updated: 2011-01-20
|
||||
------------------------------------------------------------------------
|
||||
|
||||
|
||||
Table of contents
|
||||
-----------------
|
||||
1.0) Preface
|
||||
2.0) Joining the network
|
||||
3.0) Asking for updates
|
||||
* 3.1) Polling manually
|
||||
4.0) Sending rcon commands
|
||||
5.0) Sending chat
|
||||
* 5.1) Receiving chat
|
||||
6.0) Disconnecting
|
||||
7.0) Certain packet information
|
||||
## Table of contents
|
||||
|
||||
- 1.0) [Preface](#10-preface)
|
||||
- 2.0) [Joining the network](#20-joining-the-network)
|
||||
- 3.0) [Asking for updates](#30-asking-for-updates)
|
||||
- 3.1) [Polling manually](#31-polling-manually)
|
||||
- 4.0) [Sending rcon commands](#40-sending-rcon-commands)
|
||||
- 5.0) [Sending chat](#50-sending-chat)
|
||||
- 5.1) [Receiving chat](#51-receiving-chat)
|
||||
- 6.0) [Disconnecting](#60-disconnecting)
|
||||
- 7.0) [Certain packet information](#70-certain-packet-information)
|
||||
|
||||
|
||||
1.0) Preface
|
||||
---- -------
|
||||
## 1.0) Preface
|
||||
|
||||
The admin network provides a dedicated network protocol designed for other
|
||||
applications to communicate with OpenTTD. Connected applications can execute
|
||||
console commands remotely (rcon commands) with no further authentication.
|
||||
@ -28,7 +28,7 @@ Table of contents
|
||||
|
||||
This document describes the admin network and its protocol.
|
||||
|
||||
Please refer to the mentioned enums in src/network/core/tcp_admin.h
|
||||
Please refer to the mentioned enums in `src/network/core/tcp_admin.h`
|
||||
|
||||
Please also note that further improvements to the admin protocol can mean that
|
||||
more packet types will be sent by the server. For forward compatibility it is
|
||||
@ -36,94 +36,106 @@ Table of contents
|
||||
additional data to packets. This data should be ignored. Data will never be
|
||||
removed from packets in later versions, except the possibility that complete
|
||||
packets are dropped in favour of a new packet.
|
||||
|
||||
This though will be reflected in the protocol version as announced in the
|
||||
ADMIN_PACKET_SERVER_PROTOCOL in section 2.0).
|
||||
`ADMIN_PACKET_SERVER_PROTOCOL` in section 2.0).
|
||||
|
||||
A reference implementation in Java for a client connecting to the admin interface
|
||||
can be found at: http://dev.openttdcoop.org/projects/joan
|
||||
can be found at: [http://dev.openttdcoop.org/projects/joan](http://dev.openttdcoop.org/projects/joan)
|
||||
|
||||
|
||||
2.0) Joining the network
|
||||
---- -------------------
|
||||
## 2.0) Joining the network
|
||||
|
||||
Create a TCP connection to the server on port 3977. The application is
|
||||
expected to authenticate within 10 seconds.
|
||||
|
||||
To authenticate send a ADMIN_PACKET_ADMIN_JOIN packet.
|
||||
To authenticate send a `ADMIN_PACKET_ADMIN_JOIN` packet.
|
||||
|
||||
The server will reply with ADMIN_PACKET_SERVER_PROTOCOL followed directly by
|
||||
ADMIN_PACKET_SERVER_WELCOME.
|
||||
The server will reply with `ADMIN_PACKET_SERVER_PROTOCOL` followed directly by
|
||||
`ADMIN_PACKET_SERVER_WELCOME`.
|
||||
|
||||
ADMIN_PACKET_SERVER_PROTOCOL contains details about the protocol version.
|
||||
`ADMIN_PACKET_SERVER_PROTOCOL` contains details about the protocol version.
|
||||
It is the job of your application to check this number and decide whether
|
||||
it will remain connected or not.
|
||||
Furthermore, this packet holds details on every AdminUpdateType and the
|
||||
supported AdminFrequencyTypes (bitwise representation).
|
||||
Furthermore, this packet holds details on every `AdminUpdateType` and the
|
||||
supported `AdminFrequencyTypes` (bitwise representation).
|
||||
|
||||
ADMIN_PACKET_SERVER_WELCOME contains details on the server and the map,
|
||||
`ADMIN_PACKET_SERVER_WELCOME` contains details on the server and the map,
|
||||
e.g. if the server is dedicated, its NetworkLanguage, size of the Map, etc.
|
||||
|
||||
Once you have received ADMIN_PACKET_SERVER_WELCOME you are connected and
|
||||
Once you have received `ADMIN_PACKET_SERVER_WELCOME` you are connected and
|
||||
authorized to do your thing.
|
||||
|
||||
The server will not provide any game related updates unless you ask for them.
|
||||
There are four packets the server will none the less send, if applicable:
|
||||
|
||||
- ADMIN_PACKET_SERVER_ERROR
|
||||
- ADMIN_PACKET_SERVER_WELCOME
|
||||
- ADMIN_PACKET_SERVER_NEWGAME
|
||||
- ADMIN_PACKET_SERVER_SHUTDOWN
|
||||
|
||||
However, ADMIN_PACKET_SERVER_WELCOME only after a ADMIN_PACKET_SERVER_NEWGAME
|
||||
However, `ADMIN_PACKET_SERVER_WELCOME` only after a `ADMIN_PACKET_SERVER_NEWGAME`
|
||||
|
||||
|
||||
3.0) Asking for updates
|
||||
---- ------------------
|
||||
Asking for updates is done with ADMIN_PACKET_ADMIN_UPDATE_FREQUENCY.
|
||||
## 3.0) Asking for updates
|
||||
|
||||
Asking for updates is done with `ADMIN_PACKET_ADMIN_UPDATE_FREQUENCY`.
|
||||
With this packet you define which update you wish to receive at which
|
||||
frequency.
|
||||
|
||||
Note: not every update type supports every frequency. If in doubt, you can
|
||||
verify against the data received in ADMIN_PACKET_SERVER_PROTOCOL.
|
||||
verify against the data received in `ADMIN_PACKET_SERVER_PROTOCOL`.
|
||||
|
||||
The server will not confirm your registered update. However, asking for an
|
||||
invalid AdminUpdateType or a not supported AdminUpdateFrequency you will be
|
||||
disconnected from the server with NETWORK_ERROR_ILLEGAL_PACKET.
|
||||
invalid `AdminUpdateType` or a not supported `AdminUpdateFrequency` you will be
|
||||
disconnected from the server with `NETWORK_ERROR_ILLEGAL_PACKET`.
|
||||
|
||||
Additional debug information can be found with a debug level of net=3.
|
||||
Additional debug information can be found with a debug level of `net=3`.
|
||||
|
||||
`ADMIN_UPDATE_DATE` results in the server sending:
|
||||
|
||||
ADMIN_UPDATE_DATE results in the server sending:
|
||||
- ADMIN_PACKET_SERVER_DATE
|
||||
|
||||
ADMIN_UPDATE_CLIENT_INFO results in the server sending:
|
||||
`ADMIN_UPDATE_CLIENT_INFO` results in the server sending:
|
||||
|
||||
- ADMIN_PACKET_SERVER_CLIENT_JOIN
|
||||
- ADMIN_PACKET_SERVER_CLIENT_INFO
|
||||
- ADMIN_PACKET_SERVER_CLIENT_UPDATE
|
||||
- ADMIN_PACKET_SERVER_CLIENT_QUIT
|
||||
- ADMIN_PACKET_SERVER_CLIENT_ERROR
|
||||
|
||||
ADMIN_UPDATE_COMPANY_INFO results in the server sending:
|
||||
`ADMIN_UPDATE_COMPANY_INFO` results in the server sending:
|
||||
|
||||
- ADMIN_PACKET_SERVER_COMPANY_NEW
|
||||
- ADMIN_PACKET_SERVER_COMPANY_INFO
|
||||
- ADMIN_PACKET_SERVER_COMPANY_UPDATE
|
||||
- ADMIN_PACKET_SERVER_COMPANY_REMOVE
|
||||
|
||||
ADMIN_UPDATE_COMPANY_ECONOMY results in the server sending:
|
||||
`ADMIN_UPDATE_COMPANY_ECONOMY` results in the server sending:
|
||||
|
||||
- ADMIN_PACKET_SERVER_COMPANY_ECONOMY
|
||||
|
||||
ADMIN_UPDATE_COMPANY_STATS results in the server sending:
|
||||
`ADMIN_UPDATE_COMPANY_STATS` results in the server sending:
|
||||
|
||||
- ADMIN_PACKET_SERVER_COMPANY_STATS
|
||||
|
||||
ADMIN_UPDATE_CHAT results in the server sending:
|
||||
`ADMIN_UPDATE_CHAT` results in the server sending:
|
||||
|
||||
- ADMIN_PACKET_SERVER_CHAT
|
||||
|
||||
ADMIN_UPDATE_CONSOLE results in the server sending:
|
||||
`ADMIN_UPDATE_CONSOLE` results in the server sending:
|
||||
|
||||
- ADMIN_PACKET_SERVER_CONSOLE
|
||||
|
||||
|
||||
ADMIN_UPDATE_CMD_LOGGING results in the server sending:
|
||||
`ADMIN_UPDATE_CMD_LOGGING` results in the server sending:
|
||||
|
||||
- ADMIN_PACKET_SERVER_CMD_LOGGING
|
||||
|
||||
3.1) Polling manually
|
||||
---- ----------------
|
||||
Certain AdminUpdateTypes can also be polled:
|
||||
## 3.1) Polling manually
|
||||
|
||||
Certain `AdminUpdateTypes` can also be polled:
|
||||
|
||||
- ADMIN_UPDATE_DATE
|
||||
- ADMIN_UPDATE_CLIENT_INFO
|
||||
- ADMIN_UPDATE_COMPANY_INFO
|
||||
@ -131,88 +143,92 @@ Table of contents
|
||||
- ADMIN_UPDATE_COMPANY_STATS
|
||||
- ADMIN_UPDATE_CMD_NAMES
|
||||
|
||||
ADMIN_UPDATE_CLIENT_INFO and ADMIN_UPDATE_COMPANY_INFO accept an additional
|
||||
`ADMIN_UPDATE_CLIENT_INFO` and `ADMIN_UPDATE_COMPANY_INFO` accept an additional
|
||||
parameter. This parameter is used to specify a certain client or company.
|
||||
Setting this parameter to UINT32_MAX (0xFFFFFFFF) will tell the server you
|
||||
Setting this parameter to `UINT32_MAX (0xFFFFFFFF)` will tell the server you
|
||||
want to receive updates for all clients or companies.
|
||||
|
||||
Not supported AdminUpdateType in the poll will result in the server
|
||||
disconnecting the application with NETWORK_ERROR_ILLEGAL_PACKET.
|
||||
Not supported `AdminUpdateType` in the poll will result in the server
|
||||
disconnecting the application with `NETWORK_ERROR_ILLEGAL_PACKET`.
|
||||
|
||||
Additional debug information can be found with a debug level of net=3.
|
||||
Additional debug information can be found with a debug level of `net=3`.
|
||||
|
||||
|
||||
4.0) Sending rcon commands
|
||||
---- ---------------------
|
||||
Rcon runs separate from the ADMIN_UPDATE_CONSOLE AdminUpdateType. Requesting
|
||||
## 4.0) Sending rcon commands
|
||||
|
||||
Rcon runs separate from the `ADMIN_UPDATE_CONSOLE` `AdminUpdateType`. Requesting
|
||||
the execution of a remote console command is done with the packet
|
||||
ADMIN_PACKET_ADMIN_RCON.
|
||||
`ADMIN_PACKET_ADMIN_RCON`.
|
||||
|
||||
Note: No additional authentication is required for rcon commands.
|
||||
|
||||
The server will reply with one or more ADMIN_PACKET_SERVER_RCON packets.
|
||||
Finally an ADMIN_PACKET_ADMIN_RCON_END packet will be sent. Applications
|
||||
will not receive the answer twice if they have asked for the AdminUpdateType
|
||||
ADMIN_UPDATE_CONSOLE, as the result is not printed on the servers console
|
||||
The server will reply with one or more `ADMIN_PACKET_SERVER_RCON` packets.
|
||||
Finally an `ADMIN_PACKET_ADMIN_RCON_END` packet will be sent. Applications
|
||||
will not receive the answer twice if they have asked for the `AdminUpdateType`
|
||||
`ADMIN_UPDATE_CONSOLE`, as the result is not printed on the servers console
|
||||
(just like clients rcon commands).
|
||||
|
||||
Furthermore, sending a 'say' command (or any similar command) will not
|
||||
Furthermore, sending a `say` command (or any similar command) will not
|
||||
be sent back into the admin network.
|
||||
Chat from the server itself will only be sent to the admin network when it
|
||||
was not sent from the admin network.
|
||||
|
||||
Note that when content is queried or updated via rcon, the processing
|
||||
happens asynchronously. But the ADMIN_PACKET_ADMIN_RCON_END packet is sent
|
||||
happens asynchronously. But the `ADMIN_PACKET_ADMIN_RCON_END` packet is sent
|
||||
already right after the content is requested as there's no immediate output.
|
||||
Thus other packages and the output of content rcon command may be sent at
|
||||
an arbitrary later time, mixing into the output of other console activity,
|
||||
e.g. also of possible subsequent other rcon commands sent.
|
||||
|
||||
|
||||
5.0) Sending chat
|
||||
---- ------------
|
||||
Sending a ADMIN_PACKET_ADMIN_CHAT results in chat originating from the server.
|
||||
## 5.0) Sending chat
|
||||
|
||||
Sending a `ADMIN_PACKET_ADMIN_CHAT` results in chat originating from the server.
|
||||
|
||||
Currently four types of chat are supported:
|
||||
|
||||
- NETWORK_ACTION_CHAT
|
||||
- NETWORK_ACTION_CHAT_CLIENT
|
||||
- NETWORK_ACTION_CHAT_COMPANY
|
||||
- NETWORK_ACTION_SERVER_MESSAGE
|
||||
|
||||
NETWORK_ACTION_SERVER_MESSAGE can be sent to a single client or company
|
||||
using the respective DestType and ID.
|
||||
This is a message prefixed with the 3 stars, e.g. *** foo has joined the game
|
||||
`NETWORK_ACTION_SERVER_MESSAGE` can be sent to a single client or company
|
||||
using the respective `DestType` and ID.
|
||||
This is a message prefixed with the 3 stars, e.g. `*** foo has joined the game`
|
||||
|
||||
5.1) Receiving chat
|
||||
---- -------------
|
||||
Register ADMIN_UPDATE_CHAT at ADMIN_FREQUENCY_AUTOMATIC to receive chat.
|
||||
## 5.1) Receiving chat
|
||||
|
||||
Register `ADMIN_UPDATE_CHAT` at `ADMIN_FREQUENCY_AUTOMATIC` to receive chat.
|
||||
The application will be able to receive all chat the server can see.
|
||||
|
||||
The configuration option network.server_admin_chat specifies whether
|
||||
The configuration option `network.server_admin_chat` specifies whether
|
||||
private chat for to the server is distributed into the admin network.
|
||||
|
||||
|
||||
6.0) Disconnecting
|
||||
---- -------------
|
||||
## 6.0) Disconnecting
|
||||
|
||||
It is a kind thing to say good bye before leaving. Do this by sending the
|
||||
ADMIN_PACKET_ADMIN_QUIT packet.
|
||||
`ADMIN_PACKET_ADMIN_QUIT` packet.
|
||||
|
||||
|
||||
7.0) Certain packet information
|
||||
---- --------------------------
|
||||
All ADMIN_PACKET_SERVER_* packets have an enum value greater 100.
|
||||
## 7.0) Certain packet information
|
||||
|
||||
ADMIN_PACKET_SERVER_WELCOME
|
||||
Either directly follows ADMIN_PACKET_SERVER_PROTOCOL or is sent
|
||||
All `ADMIN_PACKET_SERVER_*` packets have an enum value greater 100.
|
||||
|
||||
`ADMIN_PACKET_SERVER_WELCOME`
|
||||
|
||||
Either directly follows `ADMIN_PACKET_SERVER_PROTOCOL` or is sent
|
||||
after a new game has been started or a map loaded, i.e. also
|
||||
after ADMIN_PACKET_SERVER_NEWGAME.
|
||||
|
||||
ADMIN_PACKET_SERVER_CLIENT_JOIN and ADMIN_PACKET_SERVER_COMPANY_NEW
|
||||
`ADMIN_PACKET_SERVER_CLIENT_JOIN` and `ADMIN_PACKET_SERVER_COMPANY_NEW`
|
||||
|
||||
These packets directly follow their respective INFO packets. If you receive
|
||||
a CLIENT_JOIN / COMPANY_NEW packet without having received the INFO packet
|
||||
it may be a good idea to POLL for the specific ID.
|
||||
|
||||
ADMIN_PACKET_SERVER_CMD_NAMES and ADMIN_PACKET_SERVER_CMD_LOGGING
|
||||
`ADMIN_PACKET_SERVER_CMD_NAMES` and `ADMIN_PACKET_SERVER_CMD_LOGGING`
|
||||
|
||||
Data provided with these packets is not stable and will not be
|
||||
treated as such. Do not rely on IDs or names to be constant
|
||||
across different versions / revisions of OpenTTD.
|
||||
|
||||
@ -1,25 +1,24 @@
|
||||
Some explanations about Desyncs
|
||||
# Some explanations about Desyncs
|
||||
|
||||
Last updated: 2014-02-23
|
||||
------------------------------------------------------------------------
|
||||
|
||||
## Table of contents
|
||||
|
||||
- 1.0) Desync theory
|
||||
- 1.1) [OpenTTD multiplayer architecture](#11-openttd-multiplayer-architecture)
|
||||
- 1.2) [What is a Desync and how is it detected](#12-what-is-a-desync-and-how-is-it-detected)
|
||||
- 1.3) [Typical causes of Desyncs](#13-typical-causes-of-desyncs)
|
||||
- 2.0) What to do in case of a Desync
|
||||
- 2.1) [Cache debugging](#21-cache-debugging)
|
||||
- 2.2) [Desync recording](#22-desync-recording)
|
||||
- 3.0) Evaluating the Desync records
|
||||
- 3.1) [Replaying](#31-replaying)
|
||||
- 3.2) [Evaluation of the replay](#32-evaluation-of-the-replay)
|
||||
- 3.3) [Comparing savegames](#33-comparing-savegames)
|
||||
|
||||
|
||||
Table of contents
|
||||
-----------------
|
||||
1.0) Desync theory
|
||||
* 1.1) OpenTTD multiplayer architecture
|
||||
* 1.2) What is a Desync and how is it detected
|
||||
* 1.3) Typical causes of Desyncs
|
||||
2.0) What to do in case of a Desync
|
||||
* 2.1) Cache debugging
|
||||
* 2.2) Desync recording
|
||||
3.0) Evaluating the Desync records
|
||||
* 3.1) Replaying
|
||||
* 3.2) Evaluation the replay
|
||||
* 3.3) Comparing savegames
|
||||
## 1.1) OpenTTD multiplayer architecture
|
||||
|
||||
|
||||
1.1) OpenTTD multiplayer architecture
|
||||
---- --------------------------------
|
||||
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
|
||||
@ -69,8 +68,8 @@ Table of contents
|
||||
clients, which execute the command simultaneously in the same
|
||||
network frame in the same order.
|
||||
|
||||
1.2) What is a Desync and how is it detected
|
||||
---- ---------------------------------------
|
||||
## 1.2) What is a Desync and how is it detected
|
||||
|
||||
In the ideal case all clients have the same gamestate as the server
|
||||
and run in sync. That is, vehicle movement is the same on all
|
||||
clients, and commands are executed the same everywhere and
|
||||
@ -112,8 +111,8 @@ Table of contents
|
||||
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
|
||||
|
||||
Desyncs can be caused by the following scenarios:
|
||||
- The savegame does not describe the complete gamestate.
|
||||
- Some information which affects the progression of the
|
||||
@ -138,8 +137,8 @@ Table of contents
|
||||
using commands.
|
||||
|
||||
|
||||
2.1) Cache debugging
|
||||
---- ---------------
|
||||
## 2.1) Cache debugging
|
||||
|
||||
Desyncs which are caused by improper cache validation can
|
||||
often be found by enabling cache validation:
|
||||
- Start OpenTTD with '-d desync=2'.
|
||||
@ -151,8 +150,8 @@ Table of contents
|
||||
|
||||
Mind that this type of debugging can also be done in singleplayer.
|
||||
|
||||
2.2) Desync recording
|
||||
---- ----------------
|
||||
## 2.2) Desync recording
|
||||
|
||||
If you have a server, which happens to encounter Desyncs often,
|
||||
you can enable recording of the gamestate alterations. This
|
||||
will later allow the replay the gamestate and locate the Desync
|
||||
@ -180,8 +179,8 @@ Table of contents
|
||||
However, they also take a lot of disk space.
|
||||
|
||||
|
||||
3.1) Replaying
|
||||
---- ---------
|
||||
## 3.1) Replaying
|
||||
|
||||
To replay a Desync recording, you need these files:
|
||||
- The savegame from when the server was started, resp.
|
||||
the automatically created savegame from when the map
|
||||
@ -201,8 +200,8 @@ Table of contents
|
||||
This replays the server log and creates new 'commands-out.log'
|
||||
and 'dmp_cmds_*.sav' in your autosave folder.
|
||||
|
||||
3.2) Evaluation the replay
|
||||
---- ---------------------
|
||||
## 3.2) Evaluation of the replay
|
||||
|
||||
The replaying will also compare the checksums which are part of
|
||||
the 'commands-out.log' with the replayed gamestate.
|
||||
If they differ, it will trigger a 'NOT_REACHED'.
|
||||
@ -242,8 +241,8 @@ Table of contents
|
||||
dates, and the original log will contain the chat, but otherwise they
|
||||
should match.
|
||||
|
||||
3.2) Comparing savegames
|
||||
---- -------------------
|
||||
## 3.3) Comparing savegames
|
||||
|
||||
The binary form of the savegames from the original server and from
|
||||
your replay will always differ:
|
||||
- The savegame contains paths to used NewGRF files.
|
||||
|
||||
@ -1,13 +1,13 @@
|
||||
Some clarifications about the link graph
|
||||
----------------------------------------
|
||||
# Some clarifications about the link graph
|
||||
|
||||
InitializeLinkGraphs joins all threads, so if the game is abandoned
|
||||
`InitializeLinkGraphs` joins all threads, so if the game is abandoned
|
||||
with some threads still running, they're joined as soon as the next game
|
||||
(possibly the title game) is started. See also InitializeGame.
|
||||
(possibly the title game) is started. See also `InitializeGame`.
|
||||
|
||||
The MCF (multi-commodity flow) algorithm can be quite CPU-hungry as it's
|
||||
NP-hard and takes exponential time (though with a very small constant
|
||||
factor) in the number of nodes.
|
||||
|
||||
This is why it is run in a separate thread where possible. However after
|
||||
some time the thread is joined and if it hasn't finished by then the game
|
||||
will hang. This problem gets worse if we are running on a platform without
|
||||
|
||||
@ -1,28 +1,28 @@
|
||||
Multiplayer manual for OpenTTD
|
||||
# Multiplayer manual for OpenTTD
|
||||
|
||||
Last updated: 2011-02-16
|
||||
------------------------------------------------------------------------
|
||||
|
||||
|
||||
Table of contents
|
||||
-----------------
|
||||
1.0) Starting a server
|
||||
2.0) Connecting to a server
|
||||
* 2.1) Connecting to a server over the console
|
||||
3.0) Playing internet games
|
||||
4.0) Tips for servers
|
||||
* 4.1) Imposing landscaping limits
|
||||
5.0) Some useful things
|
||||
6.0) Troubleshooting
|
||||
## Table of contents
|
||||
|
||||
- 1.0) [Starting a server](#10-starting-a-server)
|
||||
- 2.0) [Connecting to a server](#20-connecting-to-a-server)
|
||||
- 2.1) [Connecting to a server over the console](#21-connecting-to-a-server-over-the-console)
|
||||
- 3.0) [Playing internet games](#30-playing-internet-games)
|
||||
- 4.0) [Tips for servers](#40-tips-for-servers)
|
||||
- 4.1)[Imposing landscaping limits](#41-imposing-landscaping-limits)
|
||||
- 5.0) [Some useful things](#50-some-useful-things)
|
||||
- 6.0) [Troubleshooting](#60-troubleshooting)
|
||||
|
||||
|
||||
1.0) Starting a server
|
||||
---- -----------------
|
||||
## 1.0) Starting a server
|
||||
|
||||
- Make sure that you have your firewall of the computer as well as possible
|
||||
routers or modems of the server configured such that:
|
||||
* port 3979 is free for both UDP and TCP connections in- and outgoing
|
||||
* port 3978 is free outbound for UDP in order to advertise with the master
|
||||
- port 3979 is free for both UDP and TCP connections in- and outgoing
|
||||
- port 3978 is free outbound for UDP in order to advertise with the master
|
||||
server (if desired). Otherwise you'll have to tell players your IP.
|
||||
* port 3977 if use of the admin interface is desired (see admin_network.txt)
|
||||
- port 3977 if use of the admin interface is desired (see admin_network.txt)
|
||||
- Click "multiplayer" on the startup screen
|
||||
- Click "start server"
|
||||
- Type in a game name
|
||||
@ -33,42 +33,36 @@ Table of contents
|
||||
- Start playing
|
||||
|
||||
|
||||
2.0) Connecting to a server
|
||||
---- ----------------------
|
||||
- Click "multiplayer" on the startup screen
|
||||
## 2.0) Connecting to a server
|
||||
|
||||
- Click "multiplayer" on the startup screen
|
||||
- If you want to connect to any network game in your LAN click on 'LAN', then
|
||||
on 'Find Server'
|
||||
- If you want to see which servers all online on the Internet, click on
|
||||
'Internet' and 'Find Server'
|
||||
|
||||
- If there were more than one server
|
||||
- select one in the list below the buttons
|
||||
- click on 'join game'
|
||||
|
||||
- select one in the list below the buttons
|
||||
- click on 'join game'
|
||||
- If you want to play and you have the ip or hostname of the game server you
|
||||
want connect to.
|
||||
- click add server
|
||||
- type in the ip address or hostname
|
||||
- if you want to add a port use :<port>
|
||||
|
||||
- click add server
|
||||
- type in the ip address or hostname
|
||||
- if you want to add a port use :<port>
|
||||
- Now you can select a company and press: "Join company", to help that company
|
||||
- Or you can press "Spectate game", to spectate the game
|
||||
- Or you can press "New company", and start your own company (if there are
|
||||
- Or you can press "Spectate game", to spectate the game
|
||||
- Or you can press "New company", and start your own company (if there are
|
||||
slots free)
|
||||
|
||||
- You see a progressbar how far you are with joining the server.
|
||||
|
||||
- Happy playing
|
||||
|
||||
2.1) Connecting to a server over the console
|
||||
---- ---------------------------------------
|
||||
## 2.1) Connecting to a server over the console
|
||||
|
||||
- Open the console and type in the following command:
|
||||
connect <ip/host>:<port>#<company-no>
|
||||
connect `<ip/host>:<port>#<company-no>`
|
||||
|
||||
|
||||
3.0) Playing internet games
|
||||
---- ----------------------
|
||||
## 3.0) Playing internet games
|
||||
|
||||
- Servers with a red dot behind it have a different version then you have. You
|
||||
will not be able to join those servers.
|
||||
|
||||
@ -98,8 +92,8 @@ Table of contents
|
||||
NB: changing frame_freq has more effect on the bandwidth then sync_freq.
|
||||
|
||||
|
||||
4.0) Tips for servers
|
||||
---- ----------------
|
||||
## 4.0) Tips for servers
|
||||
|
||||
- You can launch a dedicated server by adding -D as parameter.
|
||||
- In UNIX like systems, you can fork your dedicated server by adding -f as
|
||||
parameter.
|
||||
@ -155,8 +149,8 @@ Table of contents
|
||||
maximum memory usage for packets is:
|
||||
#max_clients * #max_clients * bytes_per_frame * 10 KiB.
|
||||
|
||||
4.1) Imposing landscaping limits
|
||||
---- ---------------------------
|
||||
### 4.1) Imposing landscaping limits
|
||||
|
||||
- You can impose limits on companies by the following 4 settings:
|
||||
- terraform_per_64k_frames
|
||||
- terraform_frame_burst
|
||||
@ -196,8 +190,8 @@ Table of contents
|
||||
affected by the above settings.
|
||||
|
||||
|
||||
5.0) Some useful things
|
||||
---- ------------------
|
||||
## 5.0) Some useful things
|
||||
|
||||
- You can protect your company so nobody else can join uninvited. To do this,
|
||||
set a password in your Company Screen
|
||||
|
||||
@ -209,8 +203,8 @@ Table of contents
|
||||
- Servers can now kick players, so don't make them use it!
|
||||
|
||||
|
||||
6.0) Troubleshooting
|
||||
---- ---------------
|
||||
## 6.0) Troubleshooting
|
||||
|
||||
- My advertising server does not show up in list at servers.openttd.org
|
||||
Run openttd with the '-d net=2' parameter. That will show which incoming
|
||||
communication is received, whether the replies from the master server or
|
||||
|
||||
Loading…
Reference in New Issue
Block a user