Since LTCG is enabled now, we don't have to define every function inside
the headers for ~xXx super speed xXx~, which means we can strip the
headers down to their bare minimum and reduce interdependencies and
therefore recompilation times by a lot.
The available gamepads are distributed automatically among players.
This also implements controller hot-plugging: It is possible to start a
game without a controller and plug it in later, and to reconnect a
controller after plugging it out.
We want one gamepad key mapping to work with multiple gamepads, so
including the id there doesn't make sense.
Additionally, the gamepad id may change during the game (controller
hot-plugging).
To keep compatibility with scripts which expect only binary buttons,
this adds a third parameter to the function which enables the new
functionality.
Bonus /script to test the controller stick x axis:
Schedule(GetCursor(), "Message(\"%d / %d\", GetPlayerControlState(0, CON_Left, true), GetPlayerControlState(0, CON_Right, true))", 10, 100000000)
Note that the values will be inconsistent if multiple analog sticks are
bound to the same control, as values from one stick will overwrite those
from the other one. This can happen even if you move only one stick.
In the long term, there is no reason DirectExec should be concerned with
C4AulScript/C4ScriptHost. In the meantime, the lookup code from Fneval can
be moved into the function.
This allows eval in scenario script to access scenario script locals, but
that seems harmless.
Gamepad support is currently not working properly as many menus cannot be
navigated with a gamepad. Simply don't load any control assignment sets that
have gamepad enabled.
The only use of C4RTF in its final moments was parsing out plain text
from RTF files anyway, so why even go to all the trouble instead of just
storing plain text in the beginning?
* Show max one message per second per client
* Do not show ready message locally
* Fix observer flag reset by ready state change
* Reflect ready state change in client list immediately
The C++ standard library comes with perfectly fine implementations of
these functions, so there's no point in reimplementing them just for the
hell of it.
Setting it by player filenames in the beginning is not necessery (and wrong for invalid files). Also copying it through C4S.Head didn't serve any purpose because PlayerInfo is synchronized in network and replays and startup player count can be deduced from that.
Tested in standalone, network, savegames, runtime join and replays from standalone, savegames and runtime join (Some replays of network games were bugged but that's an unrelated error).
The background landscape is a 8-bit landscape which stores the material
that a particular pixel will be replaced with when it is cleared, e.g.
by digging or blasting.
This is just the groundwork for this and does not offer much advantage
over the IFT flag that was used previously for that purpose. However,
additional features such as keeping the background material/texture
fixed when loam bridges are built, PXS are incorporated into the landscape
or the massmover is moving things around can be added.
See http://bugs.openclonk.org/view.php?id=1338 for more details.
While none of the mismatches were having a side-effect, this silences a
number of -Wreorder warnings which were drowning out potentially
important diagnostics.
When moving attached objects, it will now move the attachment target along with the object. This makes moving elevator cases and wind generators a lot easier.
Nicolas Hake