| Age | Commit message (Collapse) | Author |
|---|
|
Vsync should be off by default, as for most players it will be
better to play without vsync. Exception exist, mainly people who
play in fullscreen mode.
|
|
|
|
|
|
this value
Before this commit, it scaled to map-height-limit. Recently this
could also be set to "auto", meaning players don't really know
or care about this value.
This also means that if a player exported a heightmap and wanted
to import it again, looking like the exact same map, he did not
know what value for "highest peak" to use.
|
|
At least, TGP will try to reach it. It heavily depends on the map
if it is reachable at all. But for sure it will do its atmost to
get there!
|
|
It will add some slack to the map height limit if that was set
to auto.
|
|
This opens up the true power of the TGP terrain generator, as it
is no longer constrainted by an arbitrary low map height limit,
especially for extreme terrain types.
In other words: on a 1kx1k map with "Alpinist" terrain type, the
map is now really hilly with default settings.
People can still manually limit the map height if they so wish,
and after the terrain generation the limit is stored in the
savegame as if the user set it.
Cheats still allow you to change this value.
|
|
This better reflects what it is, and hopefully removes a bit of
the confusion people are having what this setting actually does.
Additionally, update the text on the setting to better inform
users what it is doing exactly, so they can make an educated
decision on how to change it.
Next commit will introduce an "auto" value, which should be the
new default. The rename has as added benefit that everyone will
start out on the "auto" value.
|
|
This setting influence the max heightlevel, and not as the name
suggests: the height of the generated map.
How ever you slice it, it is a very weird place to add this
setting, and it is better off being only in the settings menu.
Commits following this commit also make it more useful, so users
no longer have to care about it.
|
|
This is an indication value; the game tries to get as close as it
can, but due to the complex tropic rules, that is unlikely to be
exact.
In the end, it picks a height-level to base the desert/tropic
line on. This is strictly seen not needed, as we can convert any
tile to either. But it is the simplest way to get started with
this without redoing all related functions.
|
|
line height)
Setting the snow coverage (in % of the map) makes a lot more sense
to the human, while still allowing the niche player to set (by
finding the correct %) a snow line height they like. This makes for
easier defaults, as it decoupled terrain height from amount of snow.
Maps can never be 100% snow, as we do not have sprites for coastal
tiles.
Internally, this calculates the best snow line height to approach
this coverage as close as possible.
|
|
There are various of ways bootstrap can fail:
- Failing network connection
- Incomplete download
- No write permissions
- Disk full
- (others I forgot)
They all result in a screen with no windows. To ensure we at least
always show something when anything bad happens, if the bootstrap
is not successful, show a screen what the next step for the human
should be.
|
|
|
|
As OpenTTD grew, we found other ways to do this, and we are no
longer in need for a hack like this.
|
|
|
|
|
|
|
|
|
|
The video drivers using the OpenGL backend are currently our only
accelerated drivers. The options defaults to off for macOS builds and
to on everywhere else.
Co-authored-by: Michael Lutz <michi@icosahedron.de>
|
|
|
|
Cause why not
*Update the formating
|
|
By default this setting is set to 2500% normal game speed.
|
|
|
|
The exchange rate is actually more like 19,000, but OpenTTD
doesn't handle such high exchange rates kindly.
|
|
|
|
|
|
the same 'basic' visibilty as 'signal side'.
|
|
window, and give it the same 'basic' visibility as 'in-game tree placement'.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Although meant as a funny joke towards the player, our social
standards have changed since 2004, and such "jokes" are no
longer acceptable by the community as a whole.
The only value of the message is that people are informed the
information is stored in the savegame. This is mostly useful for
us, developers, as some of those cheats can have side-effects
which people report.
While at it, styled the GUI a bit better, as the way the text
was presented was odd.
|
|
|
|
|
|
(#8516)
Before it was shown as a normal order, but the vehicle was skipping
it. This was rather unclear to the user. Now it is red and contains
text with some hints what is going on.
The text is prefixed rather than post-fixed, as we have many
post-fixes already.
|
|
construction (#8274)
|
|
This is a much better location for this button, as you send
money from one company to another company, not from player
to player.
This is based on work done by JGRPP in:
https://github.com/JGRennison/OpenTTD-patches/commit/f82054339124cc6b89c5f4f9dac2d9da62f0108b
and surrounding commits, which took the work from estys:
https://www.tt-forums.net/viewtopic.php?p=1183311#p1183311
We did modify it to fix several bugs and clean up the code while
here anyway.
The callback was removed, as it meant a modified client could
prevent anyone from seeing money was transfered. The message
is now generated in the command itself, making that impossible.
|
|
|
|
|
|
|
|
adding two separate search buttons.
|
|
|
|
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.
|
|
This applies to all kinds of vehicle lists, as well as the "vehicle groups" window.
|
|
|
