DeleteObject() & DeletePed()

FiveM Discussion Bug reports
1

1. Client (production/canary) and FXServer version
Canary, FXServer Build 3336 (Linux)

2. What you expected to happen
DeletePed() to remove peds (local peds made for login script that are deleted once the player logs in)
DeleteObject() to remove the weapon on the players back, given by the script made here:
https://github.com/minipunch/weapons-on-back/blob/master/weapons-on-back/cl_weapons-on-back.lua

3. What actually happens
DeletePed(): Creates an error, which has worked for several months until now.
SCRIPT ERROR: Execution of native 9614299dcb53e54b in script host failed: Error executing native 0x9614299dcb53e54b at address 0x14079c668

DeleteObject(): Never deletes the object. Using the weapons on back script linked above is a reproduction. Essentially, the object never deletes and the script continues creating new objects, causing a PoolSize crash.

4. Category of bug (eg. client, server, weapons, peds, native)
Objects & Peds - Switching to DeleteEntity() completely resolved the issue.

5. Reproducible steps, preferably with example script(s)
Create client-sided peds, then use DeletePed() on it.
Create an object, then try to delete it using DeleteObject().

Essentially, what my script does, is create four peds at the airport locally for the player to view at the login screen. Once they select the character they’re going to play, the script loops through all four (which is a simple for i = 1, #localPeds do loop, running if DoesEntityExist(localPeds[i]) and DeletePed() loop. Upon the very first localPeds[i] (i being 1, and yes the peds are showing up properly), the above exception is thrown. The peds are not deleted and the script hangs (because of an error being thrown). Changing it to DeleteEntity() solved this issue.

As for the DeleteObject() issue, the object on the back is never actually deleted. This can be reproduced simply by using the script linked above. When you select the weapon, or remove them, the weapon remains on the back. This creates a nasty loop where when the weapon is selected, it is continuously created on the back, not deleted (since it’s equipped), and creates a PoolSize exception. Again, changing this to DeleteEntity() resolves the problem altogether and the weapon appears/disappears appropriately.

I expect it’s a simple correction, trying to do my part in catching bugs. I appreciate the near daily updates, you guys are working hard and it’s noticable.

2

Any actual repro script? A few days ago someone reported ‘DeletePed is broken on b2189’ but then I tried a simple CreatePed/Wait/DeletePed cycle and it worked fine for me, so I again doubt it’s as simple as creating a ped and then trying to delete them.

(and if it’s b2189, why don’t you mention that in your report?)

3 

RegisterCommand('makeped', function()
  local mdl = GetHashKey("mp_m_freemode_01")
  RequestModel(mdl)
  while not HasModelLoaded(mdl) do Wait(100) end
  local ped = CreatePed(0, mdl, GetEntityCoords(PlayerPedId()), 0.0, false, false)
  if DoesEntityExist(ped) then
    Citizen.Wait(1000)
    DeletePed(ped)
    if DoesEntityExist(ped) then
      print("Ped still exists after DeletePed(). Using DeleteEntity().")
      DeleteEntity(ped)
      if DoesEntityExist(ped) then 
        print("Unable to delete Ped.")
      else print("Ped successfully deleted after using DeleteEntity().")
      end
    else print("Ped deleted successfully.")
    end
  else print("Ped does not exist.")
  end
end)

As stated in the top of the post, I"m on Canary (client) and my server is using build 3336. I’m also using the force build command line argument for the Cayo Perico DLC.

4

Right. I’m suspecting a pattern change in workarounds for script handle ownership requirements.

Should be easy to fix.

1 Like
5

I’m in the process of changing most of my scripts to server side, but this problem came to light since my login script uses client-sided peds to represent their character builds.

Hope it’s easy to fix, and that I gave some insight. Thanks again to you and your team.

6

Working again as of 3348