I have a problem with spawning networked vehicle. The problem is that all clients except client who spawned the vehicle not able to get entity from networkid of this vehicle. It just says GetNetworkObject: no object by id
The way how I spawn vehicle on client:
local vehicle = CreateVehicle(model, coords.x, coords.y, coords.z, heading, true, true)
local id = NetworkGetNetworkIdFromEntity(vehicle)
SetNetworkIdCanMigrate(id, true)
SetEntityAsMissionEntity(vehicle, true, true)
SetVehicleHasBeenOwnedByPlayer(vehicle, true)
SetEntitySomething(vehicle, true)
SetNetworkIdExistsOnAllMachines(id, true)
After this I am sending network id to server and server send it to all other clients to let clients understand what exactly vehicle they need to get.
On other clients I use NetworkGetEntityFromNetworkId(id)
Resource manifest USES NETWORK VERSION.
P.s. When client who creates the vehicle join for the first time everything works. But after reconnect it starts to happen.
One more clarification.
If any client get’s closer than 300m to this vehicle it becomes available but it becomes unavailable for the client who created it if his distance to vehicle >300m
FWIW, even though I took a different route in my resource (using decor), I have seen something similar, in some cases, where entities fall off the radar and cease to exist, when they are out of collision/streaming range, no matter what I did. When coming back within collision/streaming range, they reappear. This was on a public server (more users/peers, more networking, more latency?), whereas I have not seen this same problem on a local server with far less users and less latency.
I ended up having to re-design in a way to not assume that the entity will always be available all the time.
This makes sense to me now in hindsight since the underlying engine is built on streaming, and it would be impossible to keep everything spawned, relevant all the time, for all peers on the server. From what I have seen, the engine will make optimizations/prioritizations on the fly, which what it seems to be doing for the difference between the public server with more things being spawned, and the local server in my case.
Even on my local (local meaning private as well) server, when I spawn a lot of mission peds, eventually I will see the underlying engine remove ambient peds to accommodate, with vehicles driving around with no drivers etc…
On my server I have tested it without any customs spawned things except the ‘test vehicle’. The result was same. In GTAO players has a lot of spawned things too but, for example, you are still able to see your target vehicle (like car theft task for diamond casino heist) even if it is very far. (and your organisation teammates too). So I think that something is broken inside fivem or docs really missing some info about networking.
(I never tested it with OneSync, just with normal network mode)
I see. I am still on an older manifest for my resource, since when I updated to a newer one, I was not able to place objects correctly in my script. It might of been something I was doing wrong, but did not seem like it, so I stuck to the older manifest to be safe. It sounds like you have tried other manifests though. Odd, I have not seen that problem on my test/private server (i.e I will see a mission vehicle blip moving around all across the map)
I’m not too familiar with Networking vehicles, however, I have had success in the past networking objects, so I’ll throw my 2 cents in.
Instead of using NetworkGetNetworkIdFromEntity(), try VehToNet(). Keep the SetNetworkIdCanMigrate(), then on the other clients, use NetToVeh() instead of NetworkGetEntityFromNetworkId(), followed by NetworkRequestControlOfEntity(), passing the actual entity as the argument, and then NetworkRequestControlOfNetworkId(), passing the Network ID; then call SetNetworkIdCanMigrate() when you’re done.
I’m not saying this is the best, or even correct way to go about doing this, but who knows, might work for you; worth a shot right? Without advertising per se, if you’d like to see my application of the code, you can find it here.
You should not only get the entity handle once ‘on creation’, you should save the network ID and use that instead of the entity handle (both on local and remote clients, calling NETWORK_GET_ENTITY_FROM_NETWORK_ID/NET_TO_* every frame before using the entity). It’s exactly what R* scripts do.
also that’s nonsense. the *_TO_NET natives are a literal alias, control requesting and disabling migration is also something you shouldn’t have to do at all for normal usage.
Presumably creating a fake blip and replacing with a real vehicle if close, or using the ‘sync to player’ native to force creation even if far, but knowing R* it’s more likely the former and the placeholder position is synced using an array handler.
It’s game functionality, we don’t touch it at all. Look at R* scripts.