| Age | Commit message (Collapse) | Author |
|---|
|
|
|
for every setting
This has the added benefit of not getting mistaken that multiple bases can be used for the same SettingTable
|
|
|
|
|
|
|
|
Not using vectors as those require copying from the initializer list and that
makes unique_ptrs to the actual SettingDesc objects later impossible.
|
|
The original idea was that people could find a server they could
talk in their native language on. This isn't really used in that
way. There are several reasons for removing this:
- the client also sends his "language" to the server, but nothing
is doing anything with this.
- flags are a bad way to represent languages, and over the years
we had several (rightfully) complaints about this.
- most servers have their language set to "All", and prefix the
servername with the language it is about. This is a much more
efficient way to do the same.
All in all, this feature should go back to the drawing board.
Maybe it could work in another form, but this form is not it.
|
|
This is an easy mistake to make, so protect us against making such
mistakes, by validating it doesn't happen.
|
|
So any old game made with this setting was overflowing anyway;
not really a lot we can do about that now.
|
|
|
|
Many of the member variables that are used in save/load are inside types
that are not standard layout types. Using pointer arithmetics to determine
addresses of members inside types that are not standard layout is generally
undefined behaviour. If we'd use C++17, it is conditionally supported, which means
each compiler may or may not support it. And even then using it for individual
array elements is syntactically not supported the the standard offsetof function.
Unfortunately, the trickery employed for saving linkgraph settings causes quite some
clutter in the settings ini files.
|
|
|
|
|
|
|
|
properly
|
|
|
|
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.
|
|
(This was mostly achieved with a few in-place regexes)
|
|
was removed instead of version object last appeared.
|
|
files through str_validate.
|
|
of unit, and move it to the advanced settings
-Feature [FS#5482]: have tractive effort in imperial (lbf) and metric (kgf) units
-Feature: have weights and volumes in imperial units (short tons, gallons)
|
|
defined one
|
|
settings framework. (based on patch by eagle_rainbow)
|
|
|
|
added scripts and random AIs.
|
|
and highscore tables.
|
|
Eagle_rainbow)
|
|
settings GUI. (Eagle_rainbow)
|
|
|
|
wasn't retrieved from the savegame anymore
|
|
when the values are not the same causes some nasty problems... like desyncs
|
|
|
|
|
|
|
|
their more clearly named (longer) constant names
|
|
non-conditional settings; with default from and to savegame versions all can be conditional. They previously were as well; the non-conditional ones were macros of the conditionals with to/from saveload versions hardcoded
|
|
versions as well
|
|
the need to state the "default" value for all items
|
|
|
