First of all: Sorry for the previous topic with the same title, posted on a wrong account.
So today I faced a weird bug, where sometimes I couldn’t do anything with vehicles, such as setting the plate or even deleting it. Natives like DeleteVehicle or SetVehicleNumberPlateText just won’t work, with no error or whatsoever.
So after debugging the issue a bit, we figured out that this happens in the following scenario:
If I spawn a vehicle at coords X Y Z, and someone else but me stands closer to the spawn point than I do, the vehicle will be somehow bugged.
This results in my client being unable to do anything with the vehicle:
Setting the plate, warping into the vehicle, or doing anything else with the vehicle won’t work then.
The player closest to the vehicle tends to take “control” of it. That’s just something about the netcode I had to learn the hard way. It applies to spawned NPCs too (like bodyguards).
There’s a boolean in the vehicle spawn code to make it permanently belong to the player that spawns it, but I forget exactly what it was called, sorry. Set that to true and it might help. I’m sure there’s a better way to do it somewhere.
The callback from qbcore returns the netId of the vehicle that is created.
Just use the natives NetworkGetEntityFromNetworkId() or NetToVeh() to get the entity on the client.
Note that this isn’t a consistent ‘fix’, it just may happen to work in the scenario you tested.
Generally, one should execute commands on the client that has control of an entity - there’s various ways to do this, lately the preferred way would be using state bags and state bag change handlers.
I’ve done a test completely outside of a QB resource. Just CreateVehicle with coords, where another player stands closer than I do.
Then tried to set a plate - nop. Then did the same with me being the closest player. Worked like it should.
Changing it to client-side, and it’s no longer an issue. Hm.
