Ownership issue with reproduction steps

FiveM Discussion OneSync reports
1

Hello,

I’ve seen people reporting issue with culling radius so I found a repro to reproduce the issue with ownership.
The issue is basically being unable to take the control of an entity and for a vehicle being actually stuck and unable to enter in it.

Here are the reproduction steps + a script:
sv_os_ownership_repro.lua (998 Bytes)
cl_os_ownership_repro.lua (2.2 KB)

  • Spawn the vehicle using create_test_vehicle
  • Get two players close to the vehicle
  • Identify which player owns the world grid
  • Take control of the entity with the player controlling the grid (press R)
  • Move 50m away from the vehicle with the entity’s owner
  • Press F5 on the other player (not owning the vehicle) to set a small culling radius, the vehicle should still be visible but the other player must be removed / out of scope
  • The other player (owner of the grid) must still see both the vehicle/other player
  • If the player with the small culling radius try to control the entity (pressing R or entering the car) eh wont be able to take control of it.

TLDR: If two players have a different culling radius and the player owner of an entity within a player’s scope is out of its scope the player will not be able to take control of it.

2

Culling radius overrides are broken by design and while this can theoretically be fixed by forcibly associating network player lifetimes with entities it is still likely to lead to a lot of potential regressions as a result, so both that (or a more complex fix with less side effects, such as - fully or partially - handling proximity migration and vehicle component control request events on the server) would need actual testing in a real-world scenario with real players engaging in real activities, which is something we actually do not have access to.

In addition, this override native was a community pull request proposed by a community member without too much forethought about the consequences, that was accepted without too much review likely because there was a lot of community badgering in response, i.e. to prevent a long ‘why isn’t this merged?’ discussion from starting as a result.

Now that it is added, however, removing it would break backwards compatibility and only raise even more questions, so that isn’t a likely outcome either.

(see also past discussions like various posts linking to Client unable to enter vehicle when distance culling radius has been increased - #2 by d-bubble and beyond, this is a duplicate to some extent)

3

I know you blame me for that but the initial thought about this native were for synced/networked events that required the owner/entity to be far from each other. The use case at the time I’ve made the PR was the vehicle used for an airdrop, thus the reason why the native was for “entity” and not players like the newer native that was made.

and right now the player-culling native can prove its usefulness in areas where a lot of players/vehicles are interacting which for most people is very fps costly, but yeah i get your concern and sorry for the issue this idea may have caused

4

You can find more explanation here I think

5

This should ideally be done with another idea (‘priority-based culling’ to target a budget, or perhaps figuring out what the ‘fps costly’ thing exactly is and optimizing that) and not abusing a ‘fixed’ culling radius.

Also, I’m kind of past blaming by now, but I found it a bit ironic to see even you report this issue yourself. :stuck_out_tongue:

3 Likes