TrueBrain

The GSBatchMode starts a mode, much like GSTestMode and GSExecMode. All commands executed in the scope of a batch are queued to be executed as soon as the batch closes.

If wanted, one can request a promise from the last command queued, so at a later moment the actual value can be retrieved. This is mostly useful for things like building of new stuff, but in many other cases users don't care about the result.

When the batch closes, OpenTTD sends all the commands to the command-queue, in order of creation. It is important to note that our current queue-system is limited, so possibly we need to allow those queues to either be a bit bigger, or to receive batches. The latter can be useful, as that means all multiplayer clients get a single packet with everything in there for the batch.

TrueBrain

0000 0000
0001 1111 &
---------
0000 0000


000N NNNN
0001 1111 &
---------
000N NNNN

TrueBrain

In OpenTTD, we have a few different places that uses the concept of date and time.

• Windows has several counters. The Window timing is one of the first that was changed to work based on real-time, instead of game-time, but with a twist. The solution for this is created locally in the Window code, by tracking the delta_ms between calls to UpdateWindows. But instead of having the rest of the code change to show things in "real-time" values, the rest of the code still uses "ticks". Just the Window code makes sure that a tick is always MILLISECONDS_PER_TICK, no matter if you fast-forward or not. There are six counter-like things in total:
  • scroller-click: rate-limits how fast you can scroll; not influenced by fast-forward.
• OnHundredthTick callback: meant to be called every 3 seconds for various of jobs in a Window (like refreshing the list); not influenced by fast-forward.

TrueBrain

OpenTTD Opt-In Automated Survey

!! THIS DOCUMENT IS IN PROPOSAL STATE !!

There are many ways to play OpenTTD. There are tons of settings, you can load extensions, from AIs to NewGRFs. They all modify how the game plays.

From a developer perspective, we don't actually know what settings are heavily used, and which are never used. As such, we often find ourself in a discussion about whether something is actually useful.

TrueBrain

Motivation

Eints has been written years ago, and it is showing.

• The interface feels dated, and there are several feature-requests related to it.
• The codebase is very hard to deal with. It was written in a Python style that is unusual (really too much OO, not much use of Pythonic, more a C++-style of writing, etc).
• The backend of eints is consuming a lot (500+ MiB) of memory, which costs a lot monthly.

Also, in its core, eints is not all that complex.

TrueBrain

../src/openttd.h should add these lines:
#include <bits/chrono.h>       // for steady_clock
#include <stddef.h>            // for size_t
#include <stdint.h>            // for uint8_t
#include <optional>            // for optional
#include <span>                // for span
#include <string>              // for string

../src/openttd.h should remove these lines:
- #include <chrono>  // lines 14-14