Before continuing, please make sure that your issue/crash has not been filed before on this forum. If it has, please provide additional information in the existing forum topic by filling out the template there.
To provide valuable feedback for OneSync issues or crashes, please fill out the following template as much as possible.
Client
Using canary?
N Windows version:
Windown 10 System specifications:
Multiple report from client
Server
Operating system:
Windows Server 2012 R2 Artifact version:
1354 (Latest) - Onesync+ Enabled 128 Slots IP address:
139.99.114.84:30120
**Resources:**145 System specifications:
(Player is playing normal in servers)
Thanks for providing a full dump. Looks like the game is crashing trying to change owner of a ped in a wandering scenario with a scenario index of -1. As to why the ped is in that state I’m not sure. We may need to add a hook to crash the game when the ped gets put into that state instead of waiting until changeowner is called. 1 thing I’m going to check is to see if the base migration code handles the corrupt ped and doesn’t call changeowner on it.
Citizen.CreateThread(function()
while true do
Citizen.Wait(0)
SetPedDensityMultiplierThisFrame(0.0)
SetVehicleDensityMultiplierThisFrame(0.0)
end
end)
local spawnedPeds = {}
Citizen.CreateThread(function()
if GetPlayerName(PlayerId()) ~= "pichotm" then return end
RequestAndWaitModel(`mp_m_freemode_01`)
local pos = GetEntityCoords(PlayerPedId())
for i=1,128 do
local a, b = i, 0
while a >= 10 do
b = b + 1
a = a - 10
end
local ped = CreatePed(4, `mp_m_freemode_01`, pos.x + a * 1.0, pos.y + 1.0 * b, pos.z - 1.0, 0.0, true, true)
--SetPedHeadBlendData(ped, math.random(4, 20), math.random(4, 20), math.random(4, 20), math.random(4, 20), math.random(4, 20), math.random(4, 20), 1.0, 0.5, 1.0)
--FreezeEntityPosition(ped, true)
TaskUseNearestScenarioToCoord(ped, GetEntityCoords(ped), 200.0, -1)
--SetBlockingOfNonTemporaryEvents(ped, true)
spawnedPeds[#spawnedPeds + 1] = ped
end
end)
AddEventHandler("onResourceStop", function(r)
if r ~= GetCurrentResourceName() then return end
for _,v in pairs(spawnedPeds) do
DeletePed(v)
end
end)
How to use it:
Two players
developer 1 in the server console
Start the “repro” resource
Use force_enet_disconnect on the other player (who is not the host of the peds)
Use immediately force_enet_disconnect on you
1s after your reconnection F8 quit (not sure it works with standard disconnection)
Thanks for the repro . As for an update, I’ll be poking at this myself some more over the weekend. So far what’s been found is that the ped clone messages sometimes have the task tree sync node but not the task data sync node. This leads to uninitialized CTaskInfos being used to create Tasks leading to the crash.
The specific clone that calls CheckMigration (as the server is telling the new client they own the ped) actually contains a few CPedTaskSpecificDataNode instances, but this is not being read as CheckMigration calls ChangeOwner (which crashes) and then rejects the sent state as it pertains to a locally-controlled netobj.
A likely fix would be to call CheckMigration after a successful apply only… assuming this won’t act on any removed CNetGamePlayer.
So I don’t think it is fixed or it just came back
Just add this to the repro and you will crash ~10s later
CreateThread(function()
NetworkOverrideClockTime(14, 0, 0)
while true do
Wait(math.random(400, 400))
for veh in EnumerateVehicles() do
NetworkRequestControlOfEntity(veh)
end
for veh in EnumerateObjects() do
NetworkRequestControlOfEntity(veh)
end
for veh in EnumeratePeds() do
--if not IsPedAPlayer(veh) then
--SetEntityCoords(veh, math.random(-2000, 2000) + 0.0, math.random(-2000, 2000) + 0.0, 70.0)
NetworkRequestControlOfEntity(veh)
--end
end
end
end)
Any news regarding this?
We’ve started seeing this for some players, but only for specific players.
Also, we run a “little-bit” outdated artifacts version, but the reason for that is that the latest recommended ( 2967 ) causes even more problems, like ghost cars etc, which we have under control 100% with the current build we run.
But, 2967 is a problem too as explained, so that would be awesome if they fixed.
As said - we got control over ghost cars 110% on the build were on, but with 2967, they came back.
Can you tell me where i can see it, then i’ll check it up for you straight away, but i actually don’t know where i can spot which version i’m using - and i cannot remember which it was.
. As for an update, I’ll be poking at this myself some more over the weekend. So far what’s been found is that the ped clone messages sometimes have the task tree sync node but not the task data sync node. This leads to uninitialized CTaskInfos being used to create Tasks leading to the crash.