Eints has been written years ago, and it is showing.
Also, in its core, eints is not all that complex.
!! 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.
In OpenTTD, we have a few different places that uses the concept of date and time.
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.
| 0000 0000 | |
| 0001 1111 & | |
| --------- | |
| 0000 0000 | |
| 000N NNNN | |
| 0001 1111 & | |
| --------- | |
| 000N NNNN |
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.
We add a dict classification to each versions entry on BaNaNaS.
Depending on the content-type this can have several entries.
For example, NewGRF has set-type, palette, resolution, etc.
An AI has builds-trains, builds-roadveh, etc.
Each entry has an enum value assigned to it.
For set-type this is for example train, air, or landscape.
For builds-trains it is yes or no.
| diff --git a/src/command_func.h b/src/command_func.h | |
| index 861dd480b..7539d6f54 100644 | |
| --- a/src/command_func.h | |
| +++ b/src/command_func.h | |
| @@ -382,8 +382,18 @@ protected: | |
| return MakeResult(CMD_ERROR); | |
| } | |
| - /* Test the command. */ | |
| DoCommandFlag flags = CommandFlagsToDCFlags(cmd_flags); |
| /* | |
| These next variables can be templated in TrueGRF, and are generated (by TrueGRF) different for each industry. | |
| These values are from the FIRS Steeltown Bulk Terminal industry, and are meant as example. | |
| */ | |
| level_requirements = [ | |
| { | |
| level: 0, | |
| percent: 100, | |
| }, |
TrueGRF uses a custom (RPN-based) language.
RPN (See: https://en.wikipedia.org/wiki/Reverse_Polish_notation), also known as postfix language or stack-based language, is used as NewGRFs have a limit subsets of supported operations. RPN best matches NewGRFs while still being a slightly higher language than NFO is.
As NewGRF is integer-based, so is this language. This is not so much a rule of this language, more a consequence of the rule NewGRF created.
| """ | |
| Put this file in a master checkout under .github/. | |
| It should be next to backport.py. | |
| """ | |
| import argparse | |
| import glob | |
| import subprocess | |
| import shlex |