feat(net): Add NetworkSetEntityOwner server native

[ivanzaida]

Goal of this PR

This pull request introduces the NETWORK_SET_ENTITY_OWNER native to the server side of the application, facilitating the manual migration of the owning player for entities.
This may be extremely useful alongside the sv_filterRequestControl being set to 4.

How is this PR achieving the goal

The created native uses FiveM's inner method that migrates entities owners, I believe the ServerGameState->ReassignEntity handles all the edge cases regarding entity owner migration.

This PR applies to the following area(s)

Server

Successfully tested on

Game builds: 2944
Platforms: Windows, Linux

Checklist

• Code compiles and has been tested successfully.
• Code explains itself well and/or is documented.
• My commit message explains what the changes do and what they are for.
• No extra compilation warnings are added by these changes.

Fixes issues

[blattersturm]

FWIW @AvarianKnight had tagged some concerns about this being a somewhat undesirable command here due to the risk of side effects (such as ownership being reassigned) that users of the API would have to manually take into account. Might need more specific use cases beyond 'useful with filtercontrol enabled' be mentioned so a solution can be thought of for those use cases.

[ivanzaida]

Thanks for your reply.
The ownership reassignment is indeed a side-effect, but from what I've tested it only happens to population entities.
It seems like the population ownership system is designed in some way that a player owns some kind of a territory around him and the game does not let to reasign an entity to a different player (it actually allows, but after a few seconds the ownership gets reset).
From what I've tested, server-created entities do not get automatically reasigned to the territory-owner, and the assigned user can manipulate the entity's state in more efficient way than doing RPC requests.
Also, I got tired defining custom events for managing an entity state / running some client-specific natives on the owning client's side, who is not the actual target of the script, e.g. :

// client
onNet('PlayPedAmbientSpeechNative', (pedNetId: number, speechName: string, speechParam: string) => {
  const entity = NetworkGetEntityFromNetworkId(pedNetId);
  if (!entity) {
    return;
  }
  PlayPedAmbientSpeechNative(entity, speechName, speechParam);
})

I believe, I'm not the only one who is tired of doing this kind of boilerplate job, and the changes present in this PR would save lots of developer time

[AvarianKnight]

I don't think this is a proper solution to the problem.

This PR would expect everyone using to have a general understanding on how everything should work and also expect them to not break "rules" (i.e. don't set the owner to someone that it can't be relevant to), and we also shouldn't be spilling internals to the end user.

A proper solution would be to either have server-side setters (which seems like a pipe dream if we're being honest), or fixing the RPC system so instead of sending a RPC once and hoping it gets executed, add RPC calls to a vector/map and send the RPC execution to the client until it gets acked.

Something similar to this could be added internally and not exposed to the end user, so if there are RPCs pending for an entity, the server should refuse to mitigate the entity unless it is no longer relevant to the currently locked owner (to hopefully not have the owner ping-pong around players while trying to sync) , after which it should find another relevant player and try to execute the RPC calls again.

[ivanzaida]

would be nice if you guys could take care of the proper solution, but it seems like a pipe dream as well

[FabianTerhorst]

In my opinion there is a missing a way to prevent network owner change after using this setter for this specific entity. Having that possibility would make this setter more useful.