How Do You Handle Client-Side Entity Spawning to Prevent Routing Issues?

How do you handle client-side entity spawning to prevent routing issues? RAX Development defaults to server-side spawning for anything that must exist in a specific routing bucket or for other players to see reliably. Client-side creates (vehicles, objects, peds) are limited to cosmetic or local-only cases. When a client spawns an entity in bucket 0 but the player is in bucket 1042, you get ghosts, duplicates, wrong targets, and exploit surfaces — so we align player bucket, entity bucket, and network ownership on every instanced script.

Quick answer: Spawn on server → set SetEntityRoutingBucket(entity, playerBucket) → validate distance/job on server → delete on exit. Audit scripts that use CreateVehicle / CreateObject on client. Request audit

Why client-side spawning causes routing problems

• Client spawns often land in the wrong routing bucket relative to the player
• Other players in the same apartment bucket may not see the entity, or players in bucket 0 see it floating in the world
• OneSync Infinity expects consistent ownership; mixed client/server spawns desync under load (OneSync guide)
• Mod menus abuse client spawn natives to flood entities (secure triggers)
• Housing/garage scripts fight each other when both sides spawn props

Server-side vs client-side (when to use each)

Our spawn + routing pattern

1. Player requests action (target, item, zone) — server event only
2. Server checks job, distance, bucket, cooldown, inventory
3. Server creates entity with server native / export (framework-specific)
4. local bucket = GetPlayerRoutingBucket(source) then SetEntityRoutingBucket(entity, bucket)
5. Store netId / entity handle server-side; tie to property or session id
6. On leave apartment / disconnect: server deletes entities in that session (no orphan props)
7. Client only plays animations, NUI, and local FX — not authoritative spawns

Pairs with multi-character and routing buckets and instanced housing flows.

APIs we use correctly

• GetPlayerRoutingBucket(playerId)
• SetPlayerRoutingBucket(playerId, bucketId) — server only
• SetEntityRoutingBucket(entity, bucketId) — immediately after server spawn
• DeleteEntity / framework delete on cleanup
• State bags for property id → bucket mapping (optional, documented)

Never trust the client to report its bucket for sensitive spawns; read bucket on the server from the player handle.

Scripts we audit and fix

• Garage spawn on client while player is in housing bucket
• Job duty vehicles created before bucket switch completes
• Prop furniture packs that network objects from client
• Heist / scene scripts spawning guards client-side
• Leaked Tebex resources with hardcoded client CreateObject
• qb-apartments / ox_property / custom shells with mismatched cleanup

Symptoms of bad spawn/routing (what owners report)

• Car appears in garage for one player but not another in same apartment
• Props visible through walls to the street (wrong bucket)
• Entity spam crashes server after update
• Target / ox_target hits wrong invisible object
• Items duplicating when re-entering instance (streaming issues can compound this)

Security and performance

• Rate-limit server spawn events per player
• Cap max entities per property bucket
• Log abnormal spawn rates to staff Discord
• Remove client events that accept model hashes without server whitelist
• Test under OneSync Infinity with 20+ players in mixed buckets

How RAX Development helps

• Audit resources for client spawns; refactor to server authority
• Standard bucket + cleanup module for housing and jobs
• Custom Lua with correct routing from day one
• Staging tests on staging VPS before live deploy
• Part of performance work (optimize performance) and dev standby

US Navy Veteran, 13 years IT. Reviews · Shop · Contact

Related: Routing buckets · Secure triggers · Target systems

Conclusion

How do you handle client-side entity spawning to prevent routing issues? By spawning on the server, setting entity routing buckets to match the player, and deleting on exit — not by trusting client CreateVehicle / CreateObject in instanced spaces. RAX Development audits and refactors scripts so your OneSync Infinity server stays stable.