They never worked properly in network mode because all users would see the changes.
EditorProps, EditorActions and shape delegates now provide the functionality to have custom object editing widgets.
This also fixes a bug with the selection callback causing the object list to act up.
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.
Sven Eberhardt