When the person viewing SCP-3114 is not an SCP, Scp3114Identity::WriteNickname() ignores almost all ShownPlayerInfo flags set on the role's owner. The only exception to this are UnitName and PowerStatus flags, since these are respected if the Identity's StolenRole uses naming rules.
While this doesn't cause issue in vanilla gameplay, servers using the info area extensively suffer due to the surprise element of SCP-3114 not being there, since SCP-3114 stands out like a sore thumb.
I wasn't sure if it is a "BUG" in a traditional sense, since the SCP functions as intended, but "IDEA" didn't fit for me here.
This occurs due to implementation of stealing another player's identity.
Decompiled code for reference:
public void WriteNickname(ReferenceHub owner, StringBuilder sb, out Color texColor)
{
ReferenceHub victim;
if (ReferenceHub.TryGetLocalHub(out victim) && !HitboxIdentity.IsEnemy(base.Owner, victim))
{
NicknameSync.WriteDefaultInfo(owner, sb, out texColor, null); // If LocalPlayer is in the same team as SCP-3114, ShownPlayerInfo is fully respected!
return;
}
// From now on, flags are ignored.
HumanRole humanRole;
if (this.CurIdentity.Status != Scp3114Identity.DisguiseStatus.Active || !PlayerRoleLoader.TryGetRoleTemplate<HumanRole>(this.CurIdentity.StolenRole, out humanRole))
{
texColor = base.CastRole.RoleColor;
sb.Append(base.CastRole.RoleName);
return;
}
texColor = humanRole.RoleColor;
RagdollData info = this.CurIdentity.Ragdoll.Info;
sb.AppendLine(info.Nickname);
sb.Append(humanRole.RoleName);
Team team = humanRole.Team;
UnitNamingRule unitNamingRule;
if (!NamingRulesManager.TryGetNamingRule(team, out unitNamingRule))
{
return;
}
string unitName = NamingRulesManager.ClientFetchReceived(team, (int)this.CurIdentity.UnitNameId);
// UnitName and PowerStatus respected here.
unitNamingRule.AppendName(sb, unitName, info.RoleType, owner.nicknameSync.ShownPlayerInfo);
}
When the person viewing SCP-3114 is not an SCP,
Scp3114Identity::WriteNickname()ignores almost allShownPlayerInfoflags set on the role's owner. The only exception to this areUnitNameandPowerStatusflags, since these are respected if the Identity'sStolenRoleuses naming rules.While this doesn't cause issue in vanilla gameplay, servers using the info area extensively suffer due to the surprise element of SCP-3114 not being there, since SCP-3114 stands out like a sore thumb.
I wasn't sure if it is a "BUG" in a traditional sense, since the SCP functions as intended, but "IDEA" didn't fit for me here.
This occurs due to implementation of stealing another player's identity.
Decompiled code for reference: