For a good bug report you should probably include:
Client (production/canary) and FXServer version
Canary 2372, FxServer 4496
What you expected to happen
Entity ownership to behave correctly with a reduced culling distance
What actually happens
Ownership cannot be taken if the owner is out of culling radius but still in the (424.0m?) zone
Category of bug (eg. client, server, weapons, peds, native)
Onesync
Reproducible steps, preferably with example script(s)
Hello,
When using SetPlayerCullingRadius to create smaller player scopes it will lead to multiple issues with entity ownership.
Some examples include:
Not being able to enter car, player freezing when opening vehicle door.
Not being able to unlock a car using SetVehicleDoorsLocked RPC native.
Repro steps:
Have 2 players with SetPlayerCullingRadius set to 15.0
Player1 create a vehicle.
Player2 come next to Player1.
Player1 move away to a distance between 15.0 and 424.0 from the vehicle.
Player2 will not be able to unlock/enter the vehicle.
Player1 come back to closer than 15.0 and now Player2 is able to unlock/enter the vehicle.
Here is a video:
Player2 is not able to unlock the car because I am out of the 15.0 radius (But somehow I still see the vehicle and other player but he cannot see me).
Then I come back to unlock the vehicle then move away from the 15.0 and Player2 is not able to enter the vehicle (freeze when opening the door).
I then enter the radius once again and Player2 is able to enter the vehicle.
I think this is probably between a bug report and a feature request as I am not sure if SetPlayerCullingRadius was intended to be used to create smaller scopes.
But that would be nice to be able to create smaller scopes.
And as shown in your video a new CNetObjAutomobile is created each time the player comes back into “scope”.
The change in culling radius doesn’t necessarily ‘create’ an ownership issue, but exposes a lingering one. As this seems to correlate heavily with issue(s)/report(s) that servers with many teleport-y things have, i.e., causing a player to instantly be >424.f units away in a single frame.
Would it be possible to re-run this repro but have onesync_logFile enabled? (Preferably with minimal noise, e.g., scenario peds, etc. This is generally useful when dealing with onesync-related reports.)
It was not intended to exist at all, another PR without use cases or tests provided by notorious bad-PR-author Pichot. For ‘smaller scopes’ dynamic filling makes MUCH more sense than any radius changing.
Component control events might be ‘obviously’ a bit weird in this case but if gottfried is right there may be another issue shown here too but I’d hold it at ‘a player who doesn’t exist can’t send a component control event that gets handled, duh’ if not (though it’s weird if a player doesn’t mutually exist for another player, so I’ll stay out of it with the speculation here).
The value you found is unrelated by the way and related to population specifically, the default 424 value is chosen so it matches that value.
When I initially tested this, vehicleComponentControlEvent was indeed being spammed with an empty target list (which completely made sense). The other bits will require further investigation.
…
From the above example, the ‘client’ is out of scope while still having ownership of that world grid: therefore not relinquishing control of the entity. As the client is not in the other clients ‘scope’, it cannot properly deduce a target for vehicleComponentControlEvent.
So it seems ‘radius changing’ (especially w.r.t corner-cases so to speak) is particularly painful in this instance. And after further toying around, these ‘radius’ checks seem quite sensitive when world grid ‘stuff’ comes into play.
world grid: therefore not relinquishing control of the entity
It also seems a little problematic for client A’s player to exist for B, but not the reverse, especially if both are set to the same radius value (but it does seem a little matching the pattern of that attempted migration fix, so could be related?).
In the end I guess this is another reason setting a player’s radius makes no sense, as world grid granularity obviously doesn’t change, this workaround for migration acts up as well, and especially with population left enabled this would be nothing but trouble.
That does however make that world grid scope hack a little questionable - would the same thing break component control still if an entity is at the edge of a real world grid/scope? If so, did this fix only make sense as a workaround for other kinds of migration issues?
