It serializes objects using a selective SaveScenarioObjects script callback and then just executes the generated script. This automatically saves important properties, connects switches and doors, etc.
This change also solves the problem that duplicating an elevator plus case would create two elevator cases.
If execution fails (e.g. because of script errors or because a non-saveable object was duplicated), the method falls back to the legacy duplication method of creating objects with the same prototypes at the same position.
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).
Sven Eberhardt