Reproduction Steps
It happens consistently. Here’s a place file to reproduce the bug: weld_animation_bug_report.rbxl (37.7 KB)
Instructions (follow these in order):
Open the Spinner model in the Animation Editor, load the Spin animation, and export it to Roblox. Then copy the asset ID and put it in the Spin Animation instance that is parented to the Spinner model.
Start a local server with 2 clients and wait for them to spawn
On the first client, press the ‘Take weld’ button and the ‘Load and play animation’ button. The former will weld the client’s character to model, the second will play an animation on the model locally. The animation should play correctly here.
On the second client, look at the spinner and press the ‘Load and play animation’ button. The button text should change to ‘Stop animation’, which means the animation has been loaded and is playing, but there should be no movement in the Spinner model as per this bug report.
On the first client, press the weld button again (should be labelled ‘Remove weld’).
Go back to the in the second client. The animation should now be moving joints correctly, and should continue working regardless of subsequent welding (until the animation is unloaded).
In the Spin animation I also included some motion that if played on a player character model will have noticeable affect. I used this to test the hypothesis that the animation was being “redirected” to the welded character model from the Spinner model - e.g. maybe the animation is playing correctly, but the Roblox engine has decided the character model is the target for the animation (instead of the Spinner) since it is a player character with assembly priority or something. In my testing however it appears this hypothesis is incorrect, as no visual movement happens to the welded character.
System info:
Roblox Studio Version 0.488.0.427318 (64bit)
Latest version available 0.488.0.427318
Expected Behavior
I expect the animation to play correctly on any client regardless of what the model being animated is welded to.
Actual Behavior
If you call _____:LoadAnimation() client-side for a model that is welded to another character, the animation will not be loaded correctly such that when it the animation is played it does not move any of the model’s joints. The animation still plays - animation events fire - but there is no effect on the model’s joints. This only happens on clients that aren’t the client controlling the character the model is welded to. Also note in my cases I have been animating non-humanoid rigs e.g. vehicles / mechanical objects. Anyway this doesn’t seem like intended behaviour, and it has been a pain to figure out and avoid for my use case.
Workaround
Always calling LoadAnimation before the model is welded to the character. For my use cases this may necessitate moving all welding client-side as well, so I can control the order welding and animation loading happens in. However, this may not be possible in all cases. And with my current solution, controlling welding client-side breaks the game in other ways, which I still haven’t figured out how to remedy.
Issue Area: Engine Issue Type: Other Impact: Moderate Frequency: Constantly Date First Experienced: 2021-08-02 11:08:00 (+12:00)
Sigh. Looks like another quirk of the physic’s engines old network ownership filter. It’s just not adding the joint to the physics engine’s set of stepping animated joints so the transforms just aren’t being applied.
As soon as the assembly enters simulation in any way (including non-authoritative broadphase island simulation) it recognizes this, and stays in animating phases from there out.
These shouldn’t be affected by network ownership at all. The network ownership filter should not affect the Transform stepping functionality of animated joints, only classic Motor CurrentAngle stepping functionality. This is a bug.
This is probably an old bug, but still a really annoying bug.
I created a ticket for it. We’ll try to fix it this year, we’re a little backlogged. We will fix this though.
Just ran into this bug and detailed it here. Thankfully my creation and welding is already being done on each client so the workaround you suggested should be easy to implement, however if I’d been unable to find this it’d of been hours of headaches. Would definitely like to see this fixed ASAP so others dont gotta suffer through that.
Edit: No variation of the workaround I attempt seems to fix this. How’d you get around it? I’ve tried parenting it to the character, then loading and playing the animation and then welding as well as a few variants but nothing seems to get around it. Would like to see it fixed even more now that there doesnt seem to be a functioning workaround for my case.
I got around it on the client by doing the following in order and asynchronously:
Calling LoadAnimation on the model I wanted to animate
Welding the character to the model
That’s all the help I can give since there wasn’t really anything else to it in my case. Make sure things are happening in that exact order, if you haven’t already.
It could also be a different issue - replication. From your bug report it looks like you are you only playing the animation from a single client (the one that created the wings). If this is the case, I’d guess that the actual problem is that the animation is not being replicated to other clients (to prevent exploits).
The way my system works is I am playing the animation for each model individually on each client, so the default replication system doesn’t come in to play at all.
It could certainly be something peculiar related to the character trying to replicate their version of their model and its animations to the server with the character physics authority while your client has its own version thats conflicting with what the server passes on to it from there, but as far as I understand it shouldnt even be trying to replicate to the server in this instance. Do you parent your model to the character model, or is it kept somewhere else and only welded to it? Could be due to me parenting it to the character which may even for locally created objects try to replicate to the server (although it fails as no wing model is shown server side).
Here’s how my specific case works (in case it helps the engineers)
A player toggles flying. This updates a server side attribute on their player object via a remote event
An object instantiated for each player on each client detects this change and calls its function to create the wings. Done through an OOP approach creating a LocalPlayerCharacter object for each player in a local script
When the attributechanged event is called, every client creates their own model of the wings for that player, loads the animation onto it, parents it to their character, and then welds.
So in this case I’m not relying on each client replicating their version of the wings to the server to update others, but rather each client runs their own version of the wings and animations as its non synch crucial.
Ok that makes sense. In my case the model was parented elsewhere. Specifically, I had a folder in Workspace for vehicles and one for characters, and each model in those categories always stayed within their respective folders. In the workaround solution, vehicles are created by the server and then clients locally weld all characters and play animations.
