On first start-up, the game will ask if you want to participate
in our automated survey. You have to opt-in, and can easily opt-out
(via the Options) at any time.
When opt-in, whenever you exit a game, a JSON blob will be send
to the survey server hosted by OpenTTD. This JSON blob contains
information that gives a global picture of the game just played:
- What settings were used
- How many humans vs AIs
- How long the game has been played
- Basic information about the OS / CPU
All this information is kept very generic, so there is no
chance we send private information to our survey server.
Nothing in the JSON blob could identify you as a person; it
mostly tells about the game played. At any time you can see
what the JSON blob includes, by pressing the "Preview Survey
Results" button in-game.
The per-AI "start_date" is a lot of custom code, and was rarely
used in the way it was meant.
While at it, also ported this part over to the new timer system.
And set the minimum maximum loan to the value of loan interval, so there is
always an amount of money to lend. Compared to being allowed to set max loan
to 0 and never be allowed to lend any money.
Soon we will make "join game" join the game as spectator first,
so limiting the amount of spectators makes no sense anymore in
that context. Not sure it ever did make sense.
TURN is a last resort, used only if all other methods failed.
TURN is a relay approach to connect client and server together, where
openttd.org (by default) is the middleman.
It is very unlikely either the client or server cannot connect to
the STUN server, as they are both already connected to the Game
Coordinator. But in the odd case it does fail, estabilishing the
connection fails without any further possibility to recover.
In this mode you do register to the Game Coordinator, but your
server will not show up in the public server listing. You can give
your friends the invite code of the server with which they can
join.
This removes the need to know a server IP to join it. Invite codes
are small (~7 characters) indentifiers for servers, which can be
exchanged with other players to join the servers.
This reduced the load on compilers, as currently for example MacOS
doesn't like the huge settings-tables.
Additionally, nobody can find settings, as the list is massive and
unordered. By splitting it, it becomes a little bit more sensible.
We often ask people for their openttd.cfg, which now includes their
passwords, usernames, etc. It is easy for people to overlook this,
unwillingly sharing information they shouldn't.
By splitting this information over either private.cfg or secrets.cfg,
we make it more obvious they shouldn't be sharing those files, and
hint to what is inside them.
With std::variant all memory can be figured out at compile time, so the compiler needs to keep track of fewer elements. It also saves out a unique_ptr and its memory management, over a slight impact for resolving a setting.
One UpdateServiceInterval has two parameters to update the service interval for a vehicle type, the other for all vehicle types at once. Rename the latter to help with function resolution for the introduction of variants.
This means that during loading we can validate that what is saved
is also that what is expected. Additionally, this makes all list
types similar to how they are stored on disk:
First a gamma to indicate length, followed by the data.
The size still depends on the type.
It was rather confusing which one was for what, especially as some
SaveLoad flags were settings-only. Clean up this mess a bit by
having only Setting flags.
It is a lovely organicly grown enum, where it started off with
GUI-only flags, and after that a few flags got added that can be
considered GUI-only (the GUI disables/enables based on them), to
only have flags added that has nothing to do with the GUI.
So be less confusing, and rename them to what they do.
Additionally, I took this opportunity to rename 0ISDISABLED to
reflect what it really does.
