Hey, I’ve just seen this new feature sv_filterRequestControl, which filters the request control a client asks to get ownership over an entity.
I want to use this new var, but I have a very important question I would like to ask:
Is it possible (server-sided, reliably) to transfer the ownership to a specific client?
I’m using Entity Lock-down mode feature as well, which means I can only spawn networked peds server-side, which selects the owner by who’s closest to the entity I’m about to spawn, which in my case is not the one I actually want them to be the owner. Is there possibility I don’t know to transfer/choose owner of an entity
No, as any logic that depends on a specific owner is likely to be broken or unreliable in some way, and even assigning a specific owner in itself is a difficult-to-solve problem.
A more specific use case could help, however, to find a better solution for that use case that does not expect a specific owner to be pre-assigned.
I wanted to create a job that you are a lifeguard and try to save people (networked npc), but they need to do some animations, and I wanted the player that doing the job to make the npc play the anims, because if not, I need to check who’s the npc’s owner and tell them do that, and it’s kinda stupid because they need to request the anim dict to perform it (also it may be impossible with networked animations), and sync it with the player(whom doing the job) animation, so it really makes it easier to just let the player who’s doing the job be the owner and sync it.
I don’t want cheaters to request control over entities so it is really good feature but lacking of features and because of that I don’t see how I can make it worth using…
So your best reason to want that feature is that any alternative would be ‘kinda stupid’? Again, I’m not sure what ‘a lifeguard job’ would entail so my assumptions below may be a little incorrect, but eh:
First off, no, you don’t ‘have to check who the npc’s owner’, that is just as much a recipe for unreliable behavior as manually assigning an owner would be. As per usual (and to match what Rockstar does!) assigning state to the entity and polling - or using the event, though that has its own gotchas - is the best way to get clients to have specific behavior for something especially with reassignment and all, but of course it rather should be the case RPC-style task natives would be a built in feature that would basically do all this without having to write manual management code.
Even more so, the usual proximity handling would mean the local (initiating) client will usually own entities that, say, need a ‘get back’ animation in the context of ‘a lifeguard job’ so your code could get a fast path for this case and only need to send state for the other case where they somehow haven’t received the entity.
Finally, again, it could be trivial to implement a call for manual assignment anyway, but this would have inherent reliability issues as said (what if the intended owner is out of range, doesn’t have the entity created, disconnects, should get migrated away from for other reasons, etc.?) and that wouldn’t meet your requirement for ‘reliably’ at all, unless this kind of feature would be implemented and tested by someone who actually has a server and makes use of it… which is how a lot of ‘illogical missing APIs’ happen, actually, them being made by usually-me based on partial guesses.
Similarly, the ‘request control filter’ thing was a lingering PR for ages and I tried getting people to test it and request missing bits but nobody even tried so it is obviously going to lack stuff that people feel the need to use, but it’s been a month+ now and I again don’t really care about it anymore. Hell, I don’t even know if it’ll work on a real server with players at all as there hasn’t been any feedback on it whatsoever and I of course can’t test such as I don’t have a real server, nor am I in regular contact with anyone who does…