ForceFinaleStart doesn't actually force a finale start

[alexiscoutinho]

Description

The VDC description in trigger_finale says this:

Start the finale now. Only works when all survivors have entered the finale area marked in the navigation mesh.

This doesn't make sense because everyone would expect an input with "Force" to not have external checks. This gets even more inconsistent and unintuitive considering that the Use input is less strict/"more powerful" given that it allows the finale to start with survivors incapacitated outside the finale area.

The Passing finale may fail to start if someone idles in the elevator because of this. In fact, it's very easy to break elevator finales if someone is defibed outside the elevator soon after the button is pressed. There will usually be plenty of time for the player to run back and leave the finale area, thus failing the ForceFinaleStart check.

[Treescrub]

I don't see how this is a bug, it seems more like a misleading name/behavior.

[alexiscoutinho]

Perhaps an enhancement. But I wonder if it's unintentional.

[Treescrub]

I don't believe it's unintentional, there seems to be an explicit check for the survivors being in the finale area.

IMO renaming it is out of the question because of official and custom maps using it. So the only other option would be to remove the check for all survivors in the finale area and I'm not sure if that would cause issues.

On a somewhat related note, the check for all survivors being in the finale area might be what causes (or caused? unsure if this still exists) the Passing finale to fail to start if players idle on the elevator.

[alexiscoutinho]

I think the current implementation is much more issue prone than the inverse (widespread usage of the input without the external check). Depending on the configuration of the map, trigger_finale placement or what not, it might even be possible to soft lock. There have always been tricks and exploits to leave the finale area during the finale in official maps so I don't think potentially allowing standing or incapped players to be outside the finale in rare circumstances would be that big of a deal. Besides, even if an invisible wall is raised, incapped players wouldn't be able to move anyways.

Regarding c6m3, it is indeed the cause and it still happens. When a player dies or spectates a bot (goes idle) he may lose the last known nav area, so running GetLastKnownArea() would return null and fail the check.

On the other hand, I know that when players connect (before spawn event) their entities originate in the safe room, presumably near info_player_start (related to #187). Maybe if someone idles in the exact tick the input is fired, the finale check might fail with a checkpoint area (instead of null).

BTW: c1m4, c5m5, c6m3, c7m3 (via script), c9m2, c13m4 (and c4m5, but here, afaik the point_template always kills the entity that would fire this input [the trigger_finale is normally activated by Use anyways]) use the "problematic" ForceFinaleStart input. c1m4, c6m3 and c9m2 have a button as fallback; c5m5 has UseDelay as fallback (effectively 0.7 s after ForceFinaleStart); c7m3 has no fallback!; and c13m4 uses ForceFinaleStart after Use, therefore it's a useless input which can be safely removed.

[alexiscoutinho]

Do you think I should separate these bugs (Force not forcing vs player losing last area in some circumstances) in different issues?