Player zero/Michael desync on connection

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. :frowning: This should still be possible assuming it’s a race condition determined at connection time.

Any updates on the desync problem yet?

1 Like

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

can you explain? dont know what is infinity/bigmode @Cookay

This should’ve been fixed anyway in latest server builds:

2 Likes

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

2 Likes

The problem was (probably) fixed but it came back, we have it too sometimes again

2 Likes