| Age | Commit message (Collapse) | Author |
|---|
|
korean: 18 changes by telk5093
|
|
During conversion it was overlooked that the for-loop used to do
this. Oops.
|
|
We use CMakeListsTxtAdvanced, and as such, we have to do this our
self via "-DCMAKE_BUILD_TYPE=RelWithDebInfo". Otherwise we are
producing Debug builds instead of Release builds. Oops.
|
|
Stop throwing a warning about this, as it is not likely we will
ever implement it.
|
|
Also parts of the saveload code does, and some other places. This
does slow down builds, but for most computers this will not be
measurable. At least, the ones I had access to I could not find
a difference in FPS, mainly as that is heavily limited by the Hz
of the screens of the computer.
Either way, it is better to have a full functional game than a
fast one in my opinion
|
|
year. (#7589)
|
|
i++ in the 3rd part of a for() is post, not pre. Oops.
|
|
|
|
finnish: 10 changes by hpiirai
|
|
You can do: "startai myai.3", which starts version 3 of "myai".
This is very useful for testing save/load code between different
versions of your AI.
However, when using this syntax, the AI got saved as "myai.3" as
name of the AI, instead of "myai". This caused several problems,
like indicating to the user the AI could not be found, but still
load the AI. But in all cases, the AI never got the chance to
load the saved data, making the whole reason this exists pointless.
By splitting the name and version already in the console command,
the code becomes simpler and AIs started this way now follow the
normal flow after initialization.
|
|
It was rather confusing that "library_name" was calculated, and
then not used to do the FindLibrary() call. Flipping those two
blocks around makes it a bit more sane to read.
|
|
See commit fae34ee7 for details. The documentation simply never
got updated.
|
|
|
|
|
|
adding two separate search buttons.
|
|
|
|
|
|
|
|
schedule (#8416)
When link graph jobs are cleared due to abandoning the game or exiting,
flag the job as aborted.
The link graph job running in a separate thread checks the aborted flag
periodically and terminates processing early if set.
This reduces the delay at game abandon or exit if a long-running job
would otherwise still be running.
|
|
finnish: 1 change by hpiirai
|
|
arabic (egypt): 15 changes by AviationGamerX
korean: 15 changes by telk5093
finnish: 12 changes by hpiirai
|
|
|
|
korean: 2 changes by telk5093
catalan: 13 changes by perezdidac
|
|
network clients
Network servers and single player clients do not block on thread joins
due to instead pausing shortly before the join is due.
|
|
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.
|
|
|
|
|
|
|
|
Various of PatchPacks (Spring 2013, Joker, ChillPP) used versions
slightly higher than ours. Of course, as time went by, this
caught up with us, and we are now almost pushing a new version
that would conflict with them. To avoid users creating unneeded
issues about "why can I not load my savegame", lets be ahead of
the curve and flat-out refuse to load them.
Version-wise, this is totally fine. We have ~32k versions to go
before we run out (0x8000 is masked by JGRPP; we should avoid
using that). At the rate we bump savegames, this is not going to
happen in any sane reality.
|
|
stops. (#8400)
|
|
|
|
|
|
|
|
|
|
This applies to all kinds of vehicle lists, as well as the "vehicle groups" window.
|
|
This is in preparation for the new UI feature that allows grouping by shared orders.
|
|
|
|
|
|
Co-authored-by: Niels Martin Hansen <nielsm@indvikleren.dk>
|
|
This now generates a warning, as we would still like people to
make a Pull Request to support the target. But it does continue
with packing to a txz.
|
|
vietnamese: 3 changes by KhoiCanDev
russian: 4 changes by Ln-Wolf
polish: 11 changes by yazalo
|
|
No active target is that limited in concurrent file descriptors.
|
|
korean: 1 change by telk5093
slovak: 6 changes by FuryPapaya
latvian: 9 changes by lexuslatvia
|
|
|
|
|
|
(#8399)
|
|
Azure Pipelines has build our releases for two years now, but we
are finally switching to GitHub Actions. This to bring the full
workflow to a single place, making it easier for people to see
what is going on and how to influence the process.
|
|
This has several ways of being triggered:
- When creating a new release via the GitHub interface. Fully
automated that will produce new binaries, upload them, and it
will even update the website to tell about the new version.
- When triggered in an automated way from OpenTTD/workflows to
start a nightly.
- Manually via the Release workflow, which accepts branches,
Pull Requests and tags to build.
Rerunning a job is safe and should be without issues. Everything
retriggers and updates what-ever might have been broken. In fact,
except for dates, it should produce identical results.
Co-authored-by: Charles Pigott <charlespigott@googlemail.com>
|
|
|
|
|
