Hello! As a bit of a backstory, I recently started working on a rewrite to my flight system to update it from deprecated BodyPositions to the new preferred AlignPosition. When porting pre-existing characters over to use my new flight system, I noticed something odd with the two of them refusing to move at all. I’ll be using one example in this post. I’ve been at this issue for a few days now and any help would be appreciated.
At first, I was puzzled as to why my character wasn’t moving in flight despite the same script working for other characters. I started by debugging my AlignPosition, and I discovered that despite the fact that my script was functional and trying to move the character, it just wouldn’t budge, leading me to believe that there was some kind of physics issue for sure. Here’s a visualization of the AlignPosition trying to move, but not being able to.
Searching up a few topics, I found a few articles on network ownership, and I turned on the corresponding visualizations in Studio. I found out that this issue might actually be related to network ownership. Below are two videos, one of them is for a character for whom the flight script works correctly and the other one is the same bee from the previous video where the area turns red and the outlines turn black. I’m not sure what exactly the colors mean, but it doesn’t look good for my bee.
The most puzzling part of all is that all of the flight-related physics are created on the client, AlignPosition included, so by default the network ownership should stay on the client at all times, no? It’s a strange situation…
Things I’ve already tried;
Scoured the entire internet to try and find a solution. There is also basically zero documentation on what the colors mean. A previous post said red could mean some kind of conflict, but I’m not sure what this could be.
Created the necessary constraints, including AlignPosition, on the server for the client to use. This didn’t work. Even when I forcibly set the network ownership to the client.
Turned the entire model massless. This also didn’t work.
Forcibly set the network ownership to the client. It didn’t budge.
Kept constantly printing out the owner of the network ownership. It’s already on the client.
Very confused and in need of assistance. I would appreciate it if anyone well-versed in flight systems for characters could educate me on this a bit further. I could try to provide a repro, but preferably in private and to someone actually trusted since this is for an upcoming update for my game.
Parts created by the server will not be always owned by the client. You will need to call SetNetworkOwner(insert player object here) on every part on the serverside to ensure that the physics is always owned by the client.
Unless I’m misunderstanding something from your reply, I did say in the post that all the flight-related constraints are created on the client and that I have already tried forcibly setting all of the character’s baseparts to the client myself at the beginning of flight, to no avail.
Did a bit more testing and changed the color of the character to better show what’s going on. I also whipped up a quick label to indicate who owns the network and it’s constantly on the client (me) even while in flight, so I’m not sure what exactly it’s turning red and black for.
The switcheroo is always consistently triggered by the enabling and disabling of the AlignPosition property in my character, which is what the flight script also does. Once I disable this constraint, the region goes right back to green like before.
I’ve also made an extremely stripped down version as a repro file of the issue, where I can consistently replicate the problem without exposing too much of my code. Anyone willing to help can hop into Studio, hit playtest with network ownership visualizations enabled, try hitting the space key and pretty much see the issue at hand.
It is currently intentional that the flight does not work and freezes you in place, I stripped down my code to the bare minimum required to reproduce the issue. My goal is to avoid the regions going red and black when I trigger the flight state, because then I know my flight system will work.
Should be in the repro file, under “FlightScript” in StarterCharacterScripts. To my knowledge, it enables and disables the AlignPosition and sets it to the HumanoidRootPart’s position for the sake of testing.
The lack of flight is fine for now, I just need to make sure it doesn’t go red and black like it does in my video.