Really good change! Only nitpick is: Why have it on the player instead of on game / DataModel? If Player1 is Xbox only, that means so is Player2 and Player3, it’s the server that we care about being crossplay.
If I’m running code when the server shuts down on game:BindToClose, I don’t necessarily even have a Player object, or general server code that’s making changes without waiting on PlayerAdded. Workarounds are obvious but a field on Player is slightly more awkward for no apparent gain.
I don’t quite follow – how can a server be considered cross-play disabled? If a player with cross-play disabled joins a server, then leaves, can’t a player who has cross-play enabled join the same server?
My assumption was that a given game.JobId is either crossplay-enabled or crossplay disabled, and that even if all players left an Xbox-only crossplay disabled game.JobId, and we teleported crossplay-enabled players to the server’s access code, they’d join a crossplay-enabled game.JobId of that server access code.
If that were true, I was saying I would prefer a property on game for the type of crossplay of the game.JobId.
Either I’m totally wrong about that, or I was being very unclear that I was referring to a server instance (game.JobId) and not a server (server access code, which multiple server instances can exist for either over time or at the same time for crossplay restrictions).
If I’m wrong, it would be useful to know for sure so I can handle that case.