[Fature Request] onPlayerRejected event when player is rejected from onPlayerAuth

[OfficialLambdax]

Is your feature request related to a problem? Please describe.
When a script listens to the onPlayerAuth event and learns about it eg by adding it to a table

local PLAYERS = {}
function onPlayerAuth(player_name, ...)
  PLAYERS[player_name] = ...
end

and removes it with the onPlayerDisconnected event

function onPlayerDisconnect(player_id)
  PLAYERS[MP.GetPlayerName(player_id)] = nil
end

then this onPlayerDisconnected event will never be called if this or another script of another state rejects the players in onPlayerAuth, because the player was rejected before they have gotten an ID. This leads to the problematic that a script will endup with players in their tables that dont exist anymore.

This was an issue in the official events. The events script was rejecting players in onPlayerAuth but the RaceManager² kept them in their tables because they learned about the players in onPlayerAuth and removed them in onPlayerDisconnected, which ofc wasnt called as another script state rejected them.

Describe the solution you'd like
This problem could be solved by introducing the onPlayerRejected event, which would be called on every state if any state rejected a player in onPlayerAuth

function onPlayerRejected(player_name)
  PLAYERS[player_name] = nil
end

Describe alternatives you've considered
So the only current way to unlearn of players is to routinely check if the players are still present by eg

local players = tableInvert(MP.GetPlayers())
for player_name, _ in pairs(PLAYERS) do
  if players[player_name] == nil then PLAYERS[player_name] = nil end
end

[lionkor]

Have you tried/looked at postPlayerAuth in the latest pre-release? That should do what you want.

It takes the same arguments as the normal event, except there is a new argument before all the others that tells you whether the event went through (true) or was cancelled (false).

[OfficialLambdax]

I did not see this event yet no.
So if i understand #364 right then

1. postPlayerAuth is called after every state had the chance to execute onPlayerAuth no matter if the player was accepted or rejected
2. but the new arg of the event contains a boolean that tells us if the player was rejected or not

If the case, then this can be closed yes. Cause a script can listen to either just postPlayerAuth to learn about a player or remove it at that point if they learned about it before

[lionkor]

Exactly right, I'll close this then :)