## Bug: `luarules playertoteam` leaves moved player unable to resign or be moved to spectator

[steeldesade]

Description

When using /luarules playertoteam to move a player to an existing team, the moved player shares a teamID with the existing player. This creates a situation where the moved player is effectively stuck for the remainder of the game.

Expected Behaviour

Expected behaviour:
A player moved via playertoteam should retain the ability to resign or be moved to spectator independently of the team they were merged into.

Actual Behaviour

Observed behaviour:

• The moved player cannot !resign as they share a teamID and have no independent team to resign
• The moved player cannot move themselves to spectator
• Moderators cannot force the moved player to spectator without affecting the entire team they were merged into

Reproduction steps

Steps to reproduce:

1. In a multiplayer game, run /luarules playertoteam <playerID> <teamID> to move a player onto an existing team
2. Attempt to have the moved player !resign
3. Attempt to move the player to spectator via moderator commands
4. Attempt to have the player move themselves to spectator

Other

Impact:
This is a significant moderation concern. In grief or dispute scenarios where playertoteam is used as an intervention tool, the moved player can become permanently stuck with no clean resolution available to moderators.

[sprunk]

Does this only apply if you "upgrade" a spectator into a playing player, or also if you apply it to somebody who was already a playing player?

[steeldesade]

Scenario: Player left the game, /luarules playertoteam 15 1 (spectator ID 15, left player ID 1) which moves the spectator (15) to team 1. Player that left rejoins and takes 8 minutes to catch up. Spectator player tries to resign but can not. I have not tried moving an active player to another teamID (since they are already playing). I suppose I could try moving a resigned player back into a game and see if the issue persists there if the opportunity arises.

[sprunk]

Resigned player (i.e. started out as a player but is now a spec) is ultimately still a spec. Test on a live/active player, doesn't have to be in a "real" game.

[steeldesade]

Testing Results:
Moving a spectator to an existing team - No Ability to resign
Moving player who has gone to spectator back to the ID he was on, No Ability to resign
Swapping live player to another live player ID No Ability to resign
Two players on the same ID, Resigning primary player resigns both players.

[steeldesade]

Investigation findings:

The playertoteam command in cmd_dev_helpers.lua is a single Lua API call:
luaSpring.AssignPlayerToTeam(playerID, teamID)

The root cause appears to be that Spring.AssignPlayerToTeam merges the player into an existing team slot without giving them an independent player-team relationship. This is why resigning the primary player also resigns the moved player, and why the moved player cannot resign independently.

By contrast, the Spring engine's built-in team X console command creates a proper independent player-team relationship — a player who joins via team X retains full ability to resign or return to spectator independently. This has been verified in a live multiplayer game.
cheats enabled: /team x to join a team where X is the teamID and /spectator to return to spectator

Since Spring.AssignPlayerToTeam is the only Lua API available for moving players to teams, there is no gadget-side workaround available. The fix would need to happen at the engine level, either by fixing Spring.AssignPlayerToTeam to behave consistently with the team X command, or by exposing the team X functionality through the Lua API so gadgets can use it directly.

[sprunk]

The broader issue is that dedi doesn't simulate, so it won't know that the spAssignPlayerToTeam call happened. Most of the things dedi does could be moved to gameside Lua control.

In this particular case I think adding spAssignPlayerToSpectator would largely allow to solve the big pain points without having to rearchitecture the dediserver.

[steeldesade]

Thanks for the context. Spring.AssignPlayerToSpectator would be very valuable for moderation use cases. Being able to reliably move a player back to spectator after using playertoteam is exactly the missing piece. Currently moderators have no reliable way to move a player to spectator mid-game when needed. Looking forward to that addition.