I recently made a custom character using the Physics Controller manager. Everything’s been working perfectly so far, however there’s one issue I’ve encountered when attempting to create linear character scaling via the ScaleTo() model method. Ignore the misaligned GroundOffset.
Whenever a char:ScaleTo(size) on the server is called, the Controller seems to stop working for a moment before returning to its original state. This leaves the character to be influenced by physics as seen in the video where it sinks into terrain and tips over on its back. Any context made by the player in this state just doesn’t work. I have yet to find a related devforum post on this specific issue btw.
Tried to scale and reposition every part individually in the model, but this doesn’t replicate what I want out of the system. Changing CFrame position after an increment also fails to fix this. I attempted client handling, which I will briefly discuss below.
It’s odd - using the ScaleTo() method on the client works perfectly and doesn’t impact the controller which allows for seamless increments. Only downside is it doesn’t replicate on other clients, making it such a time sink and overly complex to manage (given other aspects of the game). A similar thing happens when I normally scale the model through the scale tool during runtime.
So yeah. I’m unsure if this is an issue regarding the engine or just the way I’ve handled the controller. I assume it’s an engine bug, as everything works fine on the client which is where I handle controller logic. If you guys have any fix suggestions it’d be a greatly appreciated.
ScaleTo() under the hood seems to force a model rebuild or physics refresh — and when that happens on the server, the controller (especially if it’s client-based) probably de-syncs or resets for a moment. That’s why the character flops over or becomes physics-influenced — the controller briefly lets go
It makes sense that it works fine on the client: the controller doesn’t lose track of anything because it’s all local. But yeah…not replicating to other clients is the killer.
try to scale from the client, then sync
use ScaleTo() on the client, and send a scale value to the server via RemoteEvent. Then let the server replicate the state change — not the full ScaleTo itself.
or reset the Controller after scaling
on the server, try temporarily disabling and reinitializing the Physics Controller after ScaleTo(). that way, you might re-bind it post-scaling and avoid the sinking effect.
Not a guarantee, but worth testing — especially if the controller logic is modular.
at last try gradual Scaling with custom tween logic
If ScaleTo() is too aggressive, you could manually lerp the size of each part, then re-apply welds/joints. More control, but definitely more boilerplate.
but tbh this feels like engine edge case. controllers are super sensitive to real-time physics changes (scaling being a big one), and the fact that it works fine client-side tells me the controller doesn’t re-bind correctly server-side post-scale.
might be worth posting to the Engine Bugs category if it’s reproducible in a minimal file…could help get visibility and confirmation.
Tried the first two options and some extras - got nothing.
Models are pretty complicated. I tried lerp scaling, but previous systems I’ve integrated handling mesh bones and constraints for skinned mesh ragdolls end up colliding and becoming a mess. That option may work for others - just not me. I think the best action for me right now is to scrap the use of Physics Controllers and integrate the desired behavior into a typical humanoid. Shouldn’t take too long, but a shame it is indeed. D:
I’ll leave this topic open for anyone with extra suggestions or facing similar issues. Definitely filing this as an engine bug when I have the time to replicate this on a smaller scale.