Description

This PR refactors ESX.OneSync.SpawnVehicle to decouple vehicle spawning from the presence or proximity of any specific player, and introduces a new optional routingBucket parameter to ESX.OneSync.GetClosestPlayer.

Previously, we attempted to get the vehicle type from the closest player and then waited for that player to become the network owner (regardless of what dimension they are in). This caused issues when spawning vehicles in other dimensions, specifically when the player was not in dimension 0—blocking vehicle creation indefinitely. Since we spawn vehicles in dimension 0, getting a closest player that is not in that dimension will make it impossible for them to become the net owner of that vehicle and so the spawning will fail.

Now, the logic is much more robust:

• If a vehicleType is not provided, the server falls back to the first available player (if any) to determine it. Regardless of dimension or distance.
• If no players are online and no vehicleType is provided, spawning fails early with a clear error.
• Otherwise, vehicle creation proceeds without awaiting a network owner. If a player is nearby in dimension 0, ownership is handled normally. If not, the vehicle still spawns and the caller can set the vehicle into the correct dimension.
• Vehicle properties will still be applied once a player enters scope.

Motivation

Issue #1646

This change resolves a long-standing issue where /car and similar commands would fail in non-zero dimensions. By removing the requirement for a dimension 0 player and falling back to any player for type detection, vehicle spawning becomes reliable and dimension-agnostic.

Additionally:

• The vehicle spawn logic was far too limiting. To determine a vehicle type, a player doesn't need to be in scope of the vehicle, yet the old logic enforced that constraint without justification.
• The only case where awaiting a network owner makes sense is to apply vehicle properties immediately. Now, if no one is nearby, we skip waiting—properties will be synced automatically as soon as a player enters scope.

Implementation Details

• Refactored SpawnVehicle to no longer rely on a closest player being in a specific dimension.
• Fallback to the first available player only if vehicleType is not explicitly provided.
• Added early rejection with a clear error if no players are online and no vehicleType is provided.
• Skipped awaiting a net owner if none is nearby, improving responsiveness.
• Added optional routingBucket filter to ESX.OneSync.GetClosestPlayer to support scoped searches.
• Ensured that even when no one is in scope, vehicle spawning and eventual property syncing still work reliably.

PR Checklist

• My commit messages and PR title follow the Conventional Commits standard.
• My changes have been tested locally and function as expected.
• My PR does not introduce any breaking changes.
• I have provided a clear explanation of what my PR does, including the reasoning behind the changes and any relevant context.