New Player object is referenced when player rejoins

[econoraptor]

What's the recommended way of dealing with player reconnects?

It seems that when a player leaves and rejoins the game, a new object is created rather than linking the player to the old object through their SteamID or some other persistent identifier. This, coupled with the fact that there's no event raised when a player connects, makes dealing with player reconnects tricky.

I poked around a bit to see if I could easily make a persistent object, but because of where SteamIDs are added to the player object and the fact that the RawPlayers entry is deleted when the player disconnects, this turns out to be fairly involved.

[moritzuehling]

Hey,

you seem to have seen why we can't really just give back the player-objects. The thing is, in Valves internal code there is a new object created when a player connects, so I don't feel like it makes sense if I try to let it survive.

This, coupled with the fact that there's no event raised when a player connects

There is event the possibility that a player leaves the PVS an re-enters it that could lead to a new object - without any game-event.

But this is actually a bug - I currently really don't have the time, but if anyone opens a pull-request to add these events I'd be very willing to accept those. See 44413d8 on how to implement it.

What's the recommended way of dealing with player reconnects?

Aggregate everything by the SteamID. You got, for example, a Dictionary<Player, List<Kill>>? Make it a Dictionary<long, List<Kill>>, and let the key be the SteamID.

You want to check if two Players are equal? Check for their SteamID. If you really want you can override GetHashCode and Equals (and maybe the == operator) to only check if the SteamID equals, then you can check for Player-Equality the way you do now.

[econoraptor]

There is event the possibility that a player leaves the PVS an re-enters it that could lead to a new object - without any game-event.

Are you saying that the connect/disconnect events sometimes aren't raised in the demo or that the parser sometimes doesn't catch them? Also, what does PVS stand for?

I just assumed that it was a conscious decision not to include player connects/disconnects, but it sounds like that's not the case so I'll add them in and make a pull request later tonight.

Aggregate everything by the SteamID. You got, for example, a Dictionary<Player, List>? Make it a Dictionary<long, List>, and let the key be the SteamID.

This was my initial thought, but there would still be a problem in my program of tying to SteamIDs to their Player objects. That's where the connect/disconnect events come in -- I can just modify the dictionary whenever a player connects. An alternative I suppose would be to make a PlayerDict class that wraps the dictionary accessor with a KeyNotFoundException exception handler.

[moritzuehling]

PVS

The potentially visibile set. It's the players you can possibly see. If they leave and rejoin, it might give a new reference without the player having actually reconnected.

I just assumed that it was a conscious decision not to include player connects/disconnects

Yes, it was. But I see that it was the wrong one.

tying to SteamIDs to their Player objects

Simply try not to do that, even if it's the harder way. If you want to find the player just do a Parser.Players.FirstOrDefault(a => a.SteamID == needle) - at least that's how I handle things.

Sure it's a bit slower, but actually not that slow.