mirror of
https://github.com/JGRennison/OpenTTD-patches.git
synced 2024-10-31 15:20:10 +00:00
31 lines
1.6 KiB
Markdown
31 lines
1.6 KiB
Markdown
# Some clarifications about the link graph
|
|
|
|
`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`.
|
|
|
|
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
|
|
threads. However, as those are usually the ones with less CPU power I
|
|
assume the contention for the CPU would make the game hard to play even
|
|
with threads or even without cargodist (autosave ...). I might be wrong,
|
|
but I won't put any work into this before someone shows me some problem.
|
|
|
|
You can configure the link graph recalculation time. A link graph
|
|
recalculation time of X days means that each link graph job has X days
|
|
to run before it is joined. The downside is that the flow stats won't be
|
|
updated before the job is finished and thus a high value means less
|
|
updates and longer times until changes in capacities are accounted for.
|
|
If you play a very large map with a complicated link graph you may want to
|
|
raise the time setting to avoid lags. The same holds for systems with slow
|
|
CPUs.
|
|
|
|
Another option to avoid excessive lags is to reduce the accuracy of link
|
|
graph calculations. Generally the accuracy is inversely correlated to the
|
|
CPU requirements of the MCF algorithm.
|