This prevents situations where a player that requested red has a
different color when rejoining because red is the default color of a
PlayerInfo object. This is most noticeable if the host is late with
rejoining, and a lot of players are alreading in WaitingForHost limbo.
When the host finally rejoins, they will not assign Red immediately to
players that requested Red as it is "in use", and instead assign the
next color.
By recording and restoring this is avoided, and players tend to get
their own colors back in most cases.
This is not something that officials do at the moment, but I don't think
this has an impact on mods, as a normal checkcolor/setcolor cycle will
take place as usual.
using System.Threading.Tasks;
using Impostor.Api;
using Impostor.Api.Innersloth;
+using Impostor.Api.Innersloth.Customization;
using Impostor.Api.Net;
using Impostor.Server.Net.State;
public ClientPlayer? Player { get; set; }
+ public ColorType? PreviousColor { get; set; } = null;
+
IClientPlayer? IClient.Player => Player;
public virtual ValueTask<bool> ReportCheatAsync(CheatContext context, CheatCategory category, string message)
PlayerInfo.CurrentOutfit.Color = color;
+ // Record the color so it can be restored on the next game
+ if (!Game.IsHostAuthoritive && Game.TryGetPlayer(OwnerId, out var clientPlayer))
+ {
+ clientPlayer.Client.PreviousColor = color;
+ }
+ else
+ {
+ _logger.LogWarning("Tried to record color, but couldn't get player with id {PlayerId}", OwnerId);
+ }
+
return true;
}
playerInfo.ClientId = sender.Client.Id;
playerInfo.PlayerId = GameNet.GameData.GetNextAvailablePlayerId();
+ // If player played a previous game, restore their color
+ var prevColor = sender.Client.PreviousColor;
+ if (prevColor.HasValue)
+ {
+ _logger.LogTrace("Color restored to {Color}", prevColor.Value);
+ playerInfo.CurrentOutfit.Color = prevColor.Value;
+ }
+
if (!AddNetObject(playerInfo))
{
_logger.LogError("Couldn't spawn PlayerInfo for {Name} ({ClientId})", sender.Client.Name, sender.Client.Id);