Age | Commit message (Collapse) | Author |
|
|
|
Check if the job is still running two date fract ticks before it is due
to join, and if so pause the game until its done.
When loading a game, check if the game would block immediately due to
a job which is scheduled to be joined within two date fract ticks,
and if so pause the game until its done.
This avoids the main thread being blocked on a thread join, which appears
to the user as if the game is unresponsive, as the UI does not repaint
and cannot be interacted with.
Show if pause is due to link graph job in status bar, update network
messages.
This does not apply for network clients.
|
|
|
|
|
|
|
|
|
|
|
|
This switch has been a pain for years. Often disabling broke
compilation, as no developer compiles OpenTTD without, neither do
any of our official binaries.
Additionaly, it has grown so hugely in our codebase, that it
clearly shows that the current solution was a poor one. 350+
instances of "#ifdef ENABLE_NETWORK" were in the code, of which
only ~30 in the networking code itself. The rest were all around
the code to do the right thing, from GUI to NewGRF.
A more proper solution would be to stub all the functions, and
make sure the rest of the code can simply assume network is
available. This was also partially done, and most variables were
correct if networking was disabled. Despite that, often the #ifdefs
were still used.
With the recent removal of DOS, there is also no platform anymore
which we support where networking isn't working out-of-the-box.
All in all, it is time to remove the ENABLE_NETWORK switch. No
replacement is planned, but if you feel we really need this option,
we welcome any Pull Request which implements this in a way that
doesn't crawl through the code like this diff shows we used to.
|
|
"unsafe" functions to prevent them from being used, and thus having to care about certain aspects of their return values
|
|
money to companies
|
|
|
|
Eagle_rainbow)
|
|
|
|
ScriptGame::GetLandscape (GameScript only)
|
|
there is no need to execute a command if 'no' is choosed. This also prevents crashing when clicking unpause while the confirm window is shown.
|
|
disabled a long time ago
|
|
it doesn't recompile everything that needs to be recompiled...
|
|
|
|
DEBUG() output. It was triggered on exceptions, especially when aborting world generation.
|
|
|
|
of _current_company to ensure proper restoration.
|
|
another client an amount of 0 money
|
|
|
|
where you can input a break string (patch by Zuu)
|
|
|
|
to company_cmd.cpp
|
|
|
|
executing the pause command. This to prevent showing paused and especially unpaused to be shown when the state doesn't change. Output now mentions whether pause changes keep the game paused and what reasons for pausing there 'currently' are.
|
|
in the pause mode
|
|
network game
|
|
|
|
|
|
for more consistency and distinguishability.
|
|
|
|
relatives
|
|
vehicles in more places. Esp. they were only invalidated for trains.
|
|
struct so (some vehicle related) NewGRF cache 'desyncs' can be tested easier.
|
|
PoolItem::IsValidID(index)
|
|
|
|
-Fix [FS#2864]: autopause and manual pausing conflict with eachother
-Fix: new game + pause on new game + autopause make the game not unpause on the first join
|
|
this ID' from 'some' strings and replace the string name with something more sensible.
|
|
|
|
(though spec stated they are). Caching these variables can yield a 10+% speed increase when those vehicle variables are queried often.
|
|
|
|
color and colour.
|
|
add a bit of type strictness.
|
|
|
|
see.
NoAI is an API (a framework) to build your own AIs in. See:
http://wiki.openttd.org/wiki/index.php/AI:Main_Page
With many thanks to:
- glx and Rubidium for their syncing, feedback and hard work
- Yexo for his feedback, patches, and AIs which tested the system very deep
- Morloth for his feedback and patches
- TJIP for hosting a challenge which kept NoAI on track
- All AI authors for testing our AI API, and all other people who helped in one way or another
-Remove: all old AIs and their cheats/hacks
|
|
only with manually set names
There are situations that aren't solvable (because of different language files), so if the user really wants to have duplicated name, allow him to do so. It solves desyncs between server and clients using different languages. It behaves the same in SP and MP, so users won't see the different behaviour as a bug (and even checking in SP could be worked around by the user).
|
|
(optional) parameter.
|