I currently have a game mechanic where an assembly is supposed to give network ownership strictly to a certain client, and then I intend, after another ingame event, to remove this restriction on the assemblies network owner so that PhysicsService can once again automatically regulate the network owner of the assembly.
My issue lies in the current way simply using “Part:SetNetworkOwnershipAuto()” seems to affect the assembly;
I have regions enabled (aswell as owners) and can see that even when the part should continue to stay under the players ownership within their region, executing SetNetworkOwnershipAuto seems to always run SetNetworkOwner() first, and then after 3 seconds finally lends ownership back to the original player as expected? This obviously ends up creating a horrible effect where even though the player was still eligible to continue as the assemblies owner, it forces ownership to the server first, and then back to the player.
Is there a correct method that would mean I could still allow PhysicsService to continue automatically regulating the assemblies owner without causing the forced server ownership first?
Unless you are specifically calling SetNetworkOwner() when you run setnetworkownershipauto, the game engine itself is dynamically controlling it. The game engine isn’t calling setnetworkowner. What it sounds like is a condition was met for the server to say that networkownership. If this part is anchored or has some property like it hasn’t “touched” the zone yet then I can see how the server at first takes ownership. But it is impossible to tell. Too many variables we don’t know anything about really. Is it always 3 seconds? What is the timeline for real? Is the part spawned, then do you pivot it to the region? Lots of questions.
sorry I didn’t respond to your reply but you were right; I isolated my issue onto a baseplate with a single part, realised it was working as expected, went back and revised my original script until I found out that it was seemingly setting the parts AssemblyLinearVelocity on the server that was supposedly causing this behaviour, removing that line meant that the original script is now working as intended
