13:00 < bridge_> [teeworlds] <ChillerDragon> What is a good way of counting ingame players? I usually check for character but that does not track players that are in deathscreen which should be counted as ingame.
13:00 < bridge_> [teeworlds] <ChillerDragon> https://cdn.discordapp.com/attachments/490150878934990850/651392396999000086/unknown.png
13:13 < bridge_> [teeworlds] <ChillerDragon> well i ended up checking for team spec guess thats fine
15:07 < bridge_> [teeworlds] <fokkonaut> you could also check whether the chr exists or the player is in dead spec mode
15:08 < bridge_> [teeworlds] <fokkonaut> but yea, i guess `!TEAM_SPECTATOR` works
16:02 < bridge_> [teeworlds] <Assa> depends on your view of "not ingame"
16:02 < bridge_> [teeworlds] <Assa> but usually player must exist and not be in team speactators
16:03 < bridge_> [teeworlds] <Assa> instead of iterating you could count the ingame players by tracking joins and leaves
16:04 < bridge_> [teeworlds] <ChillerDragon> performance boost huh?
17:13 < bridge_> [teeworlds] <Assa> yes, performance boost by `memorizing`
17:13 < bridge_> [teeworlds] <Assa> a c++ vector doesn't count it's length when calling `size()`, instead it has an internal counter
17:14 < rand> looking stl for any array with bounded size in tw
17:28 < bridge_> [teeworlds] <Assa> ?
18:00 < rand> for now, client are identified by their network slot index, I wonder if adding some abstraction could be nice
18:02 < rand> like uid on join, dyn array everywhere, and associative tables for translation
18:03 < rand> then, the client does not care about maxclients and trust the server (until some point)
18:04 < rand> uid could match with network slot index or could not
18:06 < rand> the server would be able to spawn any resonable amount of characters whitout taking account of real client
22:00 < bridge_> [teeworlds] <ChillerDragon> is there  a rcon command to mute players? I dont think so. Would be nice as an alternative for banning if the person just uses intensive chat spam.
22:01 < bridge_> [teeworlds] <Dune> I was thinking that as well
22:47 < bridge_> [teeworlds] <jxsl13> I'd propose votebans + mutes + range bans(if they don't already exist) to be part of vanilla
22:47 < bridge_> [teeworlds] <Dune> agree mute should also mute votes
22:49 < bridge_> [teeworlds] <jxsl13> nah, that's kinda two different things, flaming doesn't necessarily mean funvoting and, at least I, would want to prevent each of these two types separately.
22:51 < bridge_> [teeworlds] <Dune> you would be able to say things abusing the vote reason
23:05 < bridge_> [teeworlds] <ChillerDragon> oh removing permission to vote is best ❤️ but i was afraight to wish that for vanilla xd
23:06 < bridge_> [teeworlds] <ChillerDragon> @Dune same as you were able to bypass mute by name changing and you can still reconnect name change to annoy but sometimes muting helps even if there might be channels of bypassing it
23:06 < bridge_> [teeworlds] <Dune> you can already bypass spec locking