Fix/Restricted Restart

[Arkmind]

Fix/Restricted Restart

Players in restricted areas or in combat being kicked by the server (restart, crash, admin) should not be handled by the SwarmObserver

Copilot

(technical)

This pull request introduces a new mechanism to filter which players should be observed by the SwarmObserver system in the MissionServer class. The changes ensure that only relevant players are processed, improving efficiency and reducing unnecessary logging.

Player observation filtering:

• Added the shouldClientBeObserved method to determine if a player should be observed based on their status and kick-off reason, skipping players who are not alive or were disconnected for specific reasons. (src/SwarmObserver/scripts/5_Mission/MissionServer.c)
• Updated the PlayerDisconnected logic to use the new filtering method, skipping observation and logging when a player does not meet the criteria. (src/SwarmObserver/scripts/5_Mission/MissionServer.c)

[Copilot]

Pull request overview

This PR aims to prevent SwarmObserver from processing restricted-area/combat-logout handling when players disconnect due to server/admin mass-kicks or shutdown/restart scenarios.

Changes:

• Adds a new shouldClientBeObserved helper to decide whether SwarmObserver should process a disconnect.
• Updates MissionServer.PlayerDisconnected to skip SwarmObserver handling when the helper returns false.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

In the early-return path, the method calls super.PlayerDisconnected(...) and returns without cleaning up SwarmObserverLogoutManager data (and without the combat state cleanup below). This leaves per-uid logout entries around after a restart/kick-all event and can cause memory growth / stale data on later disconnects. Consider removing stored logout data (and any combat state) before returning, or moving cleanup into a finally-style block that runs for both observed and skipped disconnects.

Suggested change

	Print("[SwarmObserver] Player " + (data ? data.PlayerName : "unknown") + " is not subject to observation, skipping");
	Print("[SwarmObserver] Player " + (data ? data.PlayerName : "unknown") + " is not subject to observation, skipping");
	// Even if the player is not observed, ensure we clean up any stored logout data and combat state
	if (data)
	SwarmObserverLogoutManager.RemoveLogoutData(uid);
	if (player)
	GetCombatStateManager().RemoveCombatState(player);

[Copilot]

shouldClientBeObserved returns false when player is null, but this file’s existing disconnect flow explicitly accounts for PlayerDisconnected often being invoked without a valid player/identity (hence storing logout data in OnClientDisconnectedEvent). With the new check, a null player will cause SwarmObserver processing to be skipped even for normal voluntary disconnects, preventing restricted-area grace periods/combat notifications from ever running. To keep the intended behavior, base the decision on stored logout data (e.g., store the kickoff reason/flag in SwarmObserverLogoutData during OnClientDisconnectedEvent) or treat player == null as observable when data exists.

Suggested change

	if (!shouldClientBeObserved(player))
	// Determine whether this client should be observed.
	// If the player entity is missing but we have stored logout data, we still want to process it.
	bool observeClient;
	if (!player && data)
	observeClient = true;
	else
	observeClient = shouldClientBeObserved(player);
	if (!observeClient)