Hi
After quite long search, and a bit desperate, I’m coming to you with a lot of hope.
As said on this doc : http://docs.fivem.net/scripting-reference/events/list/playerConnecting/
There is only a temporary ID when playerConnecting event is triggered.
I have to admit I wish the events list is unfinished and that somebody here have a magic answer.
Is there any other event triggered by server during connection process progress (connection, load, spawn) which could permit to know the real source ID ?
Or is there any event triggered server side to say something like “it was this temporary ID, now it’s this one” ?
Thanks for your time.
You can use “playerSpawned” event and trigger the server to get the source ID
Hi,
That’s the point, I would a server triggered event
(Sorry for the delay, I wasn’t home)
“playerSpawned” is client side, but you can trigger a server event in the cb. This is what I use:
AddEventHandler('playerSpawned', function(spawn)
TriggerServerEvent("serverPlayerSpawned", spawn)
end)
On server side event, source id will be the good one
Hi,
This is the point : I won’t get it from client, only from server. I worked on a server which had cheaters issues and I won’t wait for client triggered event to have a correct source.
I was using the spawned and delaying things until spawn event (which is a quite late event on loading process). I found something that could be a cool workaround to do what I wanted : GetPlayerGuid(source) (or some FiveM native like that, I’m on phone, can’t check the exact name).
Thanks for your time.
Ok, I understand. The event “playerConnecting” is a temporary source id because is triggered before the loading screen.
If you want to get directly the player id without waiting a trigger from the client, you’ll need a thread to handle that. By example, a table with all checked players and with a loop you get all players (GetPlayers()
), if you have a player not in the table it’s a new player.
Yep it’s more or less what I did (even if it’s really ugly)
The GUID is a good way to do it in a less ugly way, but it’s still not optimal, code and resources quality speaking.
Let’s hope for new native events for that kind of thing !