Using player-distance culling (OR just not ESX/VRP) I have never seen this issue.
Maybe triggering “creation” on corrupted peds could fix that?
Odd - it does seem to be the case that even the server doesn’t know of the player ped… or there are multiple similar issues with differing underlying causes?
Not using esx or vrp either, even though i’m still having this bug, maybe it has nothing to do but i didn’t updated the cfx-server-data for a while
We experience it on a regular basis, many times a day. So let me know if there’s some we can do to provide information.
We even made this snippet, so we can check as admins if players are bugged ++ players can check it themselfs. (Obviously for vRP)
local player_zero = GetHashKey('player_zero')
local vRP = exports.vrp
local function ChatConsoleOutput(source, message, ...)
local formatedMessage = FormatString(message, {...})
if source <= 0 then
print(formatedMessage)
else
TriggerClientEvent('chatMessage', source, formatedMessage)
end
end
RegisterCommand('player_zero', function(player, args, raw)
-- Check if the command was executed by a player
if player ~= 0 then
-- First we tell the player if they are player_zero or not.
local id = vRP:getUserId(player)
local ped = GetPlayerPed(player)
local exist = DoesEntityExist(ped)
local model = 0
if exist then
model = GetEntityModel(ped)
end
if model == 0 or model == player_zero then
TriggerClientEvent('chatMessage', player, 'Du er desværre ^1usynlig^7 for andre spillere, du bliver nød til at genstarte dit spil for at fixe det. ☹️')
else
TriggerClientEvent('chatMessage', player, 'Wuhu - Du er ^2ikke usynlig^7 for andre spillere 🐌')
end
-- Check if we should show others players too
if not vRP:hasPermission(id, "admin.tickets") then
return
end
end
local foundAny = false
local players = GetNumPlayerIndices()
for i = 0, players - 1, 1 do
local source = GetPlayerFromIndex(i)
local ped = GetPlayerPed(tostring(source))
local exist = DoesEntityExist(ped)
local model = 0
if exist then
model = GetEntityModel(ped)
end
if model == 0 or model == player_zero then
local user_id = vRP:getUserId(source)
local playername = GetPlayerName(source)
local tmpdata = vRP:getUserTmpTable(user_id)
-- Don't let this player show up if they have not spawned yet
if not tmpdata or (tmpdata.spawns and tmpdata.spawns >= 1) then
-- Tell the executer of the command
ChatConsoleOutput(player, "^1ID: {1}^7 - {2} er usynlig for andre spillere (player_zero bug)", user_id, playername)
-- We found aleast one result, so we change the boolean
foundAny = true
end
end
end
-- If no player_zero player was found tell the command executer that good news (Yeah)
if not foundAny then
ChatConsoleOutput(player, "^2Ingen player_zero^7 spiller fundet, jubi 🥳")
end
end)
``
Likely the only way is going to be a repro with 2-3 players. This should still be possible assuming it’s a race condition determined at connection time.
Any updates on the desync problem yet?
still have that problem too
UPDATE : Didn’t experienced it since using Infinity/Bigmode
can you explain? dont know what is infinity/bigmode
Hi,
Lately I’ve been running into this bug 99 out of 100 times I connect to a OneSync server. Currently I see no way to fix this nor from FiveM side. So I would like to help out if I can since I have this happening almost every time. If someone would like to test or need any kind of info please don’t hesitate to contact me. Some things I have noticed myself tho is, it seems impossible when the server has 20+ players connected. In the 0-20 range it will eventually happen after a dozen relogs. My internet speed is 300/300 but I only get 30/90 when I run Speedtests. I have a very decent computer that fulfills the recommended specs for both fivem/gta:o
I have also noticed I seem to have this issue happen less on ESX framework servers vs vRP. I hope I can help out with valueable information regarding this issue so I can enjoy playing fivem again. Cheers
EDIT: To back up my theory of having more succes connecting with lower number of players, the main onesync server i play on was just restarted, within a minute after the restart, i connect as one of the first players and i enter without the player_zero
bug.
What uptime
shows in Task Manger’s CPU tab?
If you’re asking me, then 0:00:05:55 at the time im typing, keeps going up any second obviously. It matches the time i turned my computer on basically.
Yeah we are having the same issue using OneSync 32 slot on Ubuntu 18.04.03, artifact 2001. A few players will just stay desynced as Michael on spawn.
We’ve seen this also happen with one player on the server, we automatically detect this by checking what the server sees the player as model wise and where. I’ll occasionally get the condition when im on one of our test servers by my lonesome loading in.
So not sure if that breaks the theory of a clash when multiple people connect at the sametime.
Also have seen it happen in bigmode
We have this exact same problem quite frequently using onesync. For some players, it’s a 99% probability it’ll happen for others it doesn’t happen at all. We’ve found no fix.
We’ve noticed it happens more regularly when the player count is over 30ish.
my server Alamo also experiencing such problems
This should’ve been fixed anyway in latest server builds:
Still run into this from time to time, players that are bugged seem to not be visible to other players and they show up as Michael.
EDIT: Server Build 2312
The problem was (probably) fixed but it came back, we have it too sometimes again