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.
Technically unlikely to happen, though uint16 * uint16 get promoted to int and
then stored as uint64; similarly uint * uint16 remains uint and gets stored as
uint64. In both cases the value can get truncated before the change to uint64.
We are planning to allow things like freezing the calendar, which
makes this variable a bit problemetic. So instead, suggest to the
user how many ticks there are in a calendar day, and let them figure
out how many ticks they want.
Additionally, use a TimeoutTimer for this, instead of an end-date
variable which is checked in an IntervalTimer.
Add NEW_STATION to the nearby station list to indicate that a new
station should be built. This removes special-casing for a non-existant
list item and keeps the list count and scrollbar count the same.
This meant you could have the following situation:
- You start a profile on a GRF with no events, for N days.
- The days pass, the profile should stop. It doesn't.
- The profile will never stop, even if the GRF start generating events.
- There is no real way to discover this, so .. byebye memory? :)
PeterN
Jonathan G Rennison
Patric Stout
Rubidium
translators