Eints has been written years ago, and it is showing.
Also, in its core, eints is not all that complex.
For a while now, we have been talking how we get our OpenTTD binaries signed, and how we would get published on Steam. There are many aspects to this, and I am trying to put all that in a single place.
None of the current developers really has experience with this. So most of this information is collected from googling, asking on reddit, asking on twitter, etc. Please, if you have any experience with this and read here things that are wrong or could be done cheaper, let us know!
!! 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.
To start with, few things to keep in mind:
With us going to Steam, the request for Steam integration has increased.
| 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.
| """ | |
| Put this file in a master checkout under .github/. | |
| It should be next to backport.py. | |
| """ | |
| import argparse | |
| import glob | |
| import subprocess | |
| import shlex |
| 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); |