Fix the waypoints-done-delay sexp to work for both ships and wings.
Also, fix the set-object-speed sexp (which is deprecated anyhow) to work for all ships in a wing, not just the wing leader.
As noticed in issue #2458, intercom sounds did not stop when pausing the game or loading a mission. I fixed this by augmenting `main_hall_stop_ambient()` to also stop the intercom.
Additionally, it turns out that the intercom delays were not being calculated correctly due to a very bizarre random number formula. I overloaded `rand32()` to add a min/max variant and used this instead.
When special arguments are used, the current node cannot be cached because it always contains "<argument>". So this feature adds the ability to forward the caching to the SEXP node that contains the value being referenced. To enable this, the internal argument list now contains both the argument text and the node being referenced. (If there is no node to reference, such as with `for-counter`, the reference will be -1.)
This is a follow-up to PR #2373. Tomimaki noticed that the first character was truncated in the cutscene description, and it turned out that the algorithm was slightly wrong.
Retail has a hud_find_target_distance function that returns the distance between the player position and a bounding box. This is useful for the HUD because it shows the distance to the perimeter of an object like a jump node or a large ship. However, this function was re-used for the `distance` SEXP, resulting in the awkward situation where the distance is measured from one ship's center to another ship's bounding box. This can lead to unexpected results and it also means that the SEXP returns a different distance when the arguments are swapped.
This PR deprecates the original SEXP and introduces the new SEXPs `center-distance` and `bbox-distance` which use consistent methods for both ships. It also renames the `distance-ship-subystem` SEXP to `center-distance-subsystem` and adds a new `bbox-distance-subsystem` SEXP.
Another - hopefully bite-size - sexp upgrade stage. This takes the objective SEXPs (those which are primarily concerned with the mission log) and upgrades them to use the ship registry.
This adds a mechanism for running generic operations at specific points
of the frame execution. This can be used by any part of the code an not
just Lua since it simply executes std::functions. It also adds an
"execution context" concept that specifies in which situation an
operation should be executed.
This is then used by the Lua Coroutines code for resuming coroutines at
specific points instead of always when the awaited promise resolves.
This PR upgrades the function, and the sexps that use it, to take advantage of the new sexp caching. It also makes `script_eval_multi` more robust in the face of players who might be respawning.
This will ensure that Lua functions will always be executed in the
correct Lua state. Since we now have multiple threads (which are
different lua_State objects) it is possible that the current code could
execute a Lua function in the main state instead of the thread that is
currently executing. This can lead to weird behavior and probably also
to issues inside Lua.
This PR uses `eval_ship` and `eval_wing` to optimize `object_ship_wing_point_team` and `sexp_deal_with_ship_flags`. The API changed a bit, but to ensure compatibility, there are fields and functions to support the old behavior. These are temporary and will be removed when all changes have been merged via PRs.
Fabian Woltermann