I’d just move the game over to the separate game piece by piece and test to find out what is causing it
So I worked with another developer (the game is group based) and we took apart everything, we literally had 3 animations playing, no state changes, no welding, nothing out of the ordinary and it still ended up breaking. I’m pretty sure there’s nothing left to really try at this point
Odd, is there any way you can reproduce this, because if you can I’d make a bug report you said someone else was having this issue as well and you took apart everything so it’s probably just a bug
Hi.
Just wanted to make sure you are aware of one nasty behaviour of LoadAnimation(). If it is being loaded to a humanoid without “Animator” object, it will create one rather than throwing an error. Since characters (and Animator) are being created on server and you are using LoadAnimation() on client for player characters (if not then you should), you may end up with two Animator objects. That is especially true when server has a huge workload, and spawns characters rather slowly. Two Animator objects could cause replication issues you are having. Therefore you should always use CharacterHumanoid:WaitForChild(“Animator”) before loading any animations. I have solved similar replication problem (but not the same) in my game thanks to this.Sorry if this is not relevant or you already knew this.
Edit: Humanoid, not Character.
Two Animator objects never get generated, or shouldn’t. The creation of an Animator is a regular instanced object from the server following standard replication rules.
1 Like
From the Wiki
The Animator object must be initially created on the server and replicated to clients for animation replication to work at all. If an Animator is created locally, then AnimationTracks loaded with that Animator will not replicate.
Both
Humanoid:LoadAnimationandAnimationController:LoadAnimationwill create an Animator if one does not already exist. When calling LoadAnimation from LocalScripts you need to be careful to wait for the Animator to replicate from the server before calling LoadAnimation if you want character animations to replicate. You can do this with WaitForChild(“Animator”).
I may be wrong on two Animator objects, but if LoadAnimation() on client is called simultaneously as the server creates Animator object during normal spawning, i would not count on them to act nicely.
1 Like
Is this happening all the time? Somehow I also counter this in my game but it happens vary and from time to time. It’s also an idle animation. But I found that this does not happen to me anymore since late August, is this still happening to you?
This issue still persists to this very day. From what I was told by a staff member it has to do with when the weight of all the current animations playing exceed 1. In which case all new animations called to play will no longer do so until every animation that made that weight rise over one completely stop.
Does it happen all the time or only happening from time to time? Also what’s the AnimationPriority of the Animation?
The issue happens pretty much all of the time. The cause is somewhat random, and most animation triggers are done via Action priority animations. Generally our combat type animations with play frequently. Even months later I can simply hop on, and have someone punch and slice a few times, to have their animations broke for what could be a few seconds, or even numerous minutes.
So recently we tried to completely redo the entire system for playing animations. After only a few days of working on the system we encountered the exact same issue. In total the entire system the rework had animation count wise was about 18. Without fail regardless of what we did the bug where all animations stop replicating persists. We wait for the animatior on the client, we ensure it exists for the server, we don’t touch a single thing about the character, we don’t have an insane amount of animations playing at once, and all of our priorities are set to what they should be. Combat animations are action priority, and movement animations are movement priority. At this point I have absolutely no idea what we could be doing wrong. Nobody else really seems to have encountered this issue anywhere.
I’ve encountered this issue before. Still haven’t come up with any fix E.E
Alright, I’ve gone a step even further and created a completely isolated version of our project that contains the animation bug. The place isn’t copy locked, so the code can be reviewed by anyone.
Rudimentary Controls
Left Click: Light Melee
Left Shift: Shift Lock
Right Click: Heavy Melee (Requires shift lock)
Space x1: Jump
Space x2: Double Jump
Double WASD direction: Dash
Left Alt: Crouch
Left Control: Walk
How to replicate the bug
There are two ways you can go about viewing this bug for yourself. One is to hop into studio and use the Test function to test with as many players as you want. Simply run around dashing, jumping, and attacking until you see the animations no longer replicating in the server view.
The other way to replicate this is to get a friend and actually join the game. By following the same process as above one or both of you will end up not viewing the other’s animations.
–NOTE–
Replicating this doesn’t always work every time. The chances of it happening are entirely random. Below is an example of what the results look like from studio
https://gyazo.com/375c356150a1f1cbf17ee59469f4d80c
https://gyazo.com/2e9fe22c97d7e7b55b089117456c29ed
https://gyazo.com/27bd1d9d73ac39579d6e7e97fad43d7b
Check that there is an Animator object in the player’s Humanoid. If not you need to call LoadAnimation on the server to create one. These are required for players to animate from the client (which is documented on the devhub)
Creating an Animator outside of calling LoadAnimation is also acceptable enough from the server’s end. That is, unless LoadAnimation does other replication control work on the backend that instancing the Animator does not resolve.
if not Humanoid:FindFirstChild("Animator") then
Instance.new("Animator", Humanoid)
end
1 Like
So I went ahead and added WaitForChild’s on the Server end, which then informs the client the animator exists for it, and have the client also wait for it in a similar fashion. However, this didn’t change the outcome as with my first test the animations broke right away.
–Edit-----
If you want, I believe the place isn’t copy locked so you can review what code exists there. Both the creator of the base combat system, and myself are not experts at animation handling systems. So I’d feel like it would be quite possible for us to have some sort of user error that’s causing this whole fiasco
I recently made some code that prints out all current tracks playing on the animator using Humanoid:GetPlayingAnimationTracks from the server. Below is that is printed right before all animations stop replicating, as well as a corresponding image for my next discovery.
https://gyazo.com/6e4aa449a9c51c0fffebc0c510618db4
Due to a similar reply I had from a test and post a while back I had assumed the fact that the total weight was over 1 which caused the issue. However in multiple tests I spiked at total weights greater than 4 and didn’t have a single issue with replication.
https://gyazo.com/7673566386863b7cba2c6f7df881b470
The animation issue seems to stem from a custom directional update to the default animation script that I had made. However, I haven’t been able to pull off a single test where I can isolate what exactly my alterations cause that’s so horrible. Below I’ve linked an upload of the altered script.
Another odd behavior to mention is that when this whole fiasco triggers at least once, and fixes itself, it never occurs for the same client again. (Even animations that are loaded can cause this issue, so as far as I can tell it has nothing to do with whether or not they’re loaded) To “fix” the issue you just need to sit still and move after around 4-5 seconds. I’ve tried to simulate this by stopping all playing animations, but for some reason this doesn’t have the same outcome
Animate(Altered).rbxm (6.8 KB)
Alright, so I recently found myself a hot fix. Due to the fact that this issue only occurs once per player, and that I can never predict when it’ll happen (it can happen right when the first animation players, or hours after playing) I created a script that simply looks for when the client is no longer sending any animations. This checks the client ever second or so. (I will need to tweak the rate to account for larger servers)
The hot fix is pretty simple, all animations are stopped on the client, and no new animations are allowed to be played until you wait around 3 seconds, which is some magical number that is just around the exact time to fix everything up. The code is as follows
game.Players.PlayerAdded:Connect(function(player)
local Temp = script.Temp
local character = player.Character or player.CharacterAdded:Wait()
local humanoid = character:WaitForChild("Humanoid")
repeat wait() until character.Parent == game.Workspace
local tempTrack = humanoid:LoadAnimation(Temp)
local Fix_Animations = player:WaitForChild("PlayerStates"):WaitForChild("Fix_Animations")
wait(3)
print("Hot fix ready")
local fixing
while true do
if not fixing then
local tracks = humanoid:GetPlayingAnimationTracks()
if tracks[1] == nil then
fixing = true
Fix_Animations.Value = true
game:GetService("ReplicatedStorage"):WaitForChild("Fix_Animations"):InvokeClient(player)
Fix_Animations.Value = false
player:WaitForChild("PlayerStates"):WaitForChild("Animation_Fix_Prepped").Value = true
fixing = false
end
end
print(player.Name)
wait(1)
end
end)
Once the Fix_Animations instance is set to true, no new animations can load. The remote function is there to tell the client to stop all current playing animations and wait before returning to the server after the initial wait time.
—Issues with this fix—
It requires a constant loop on the server to determine if a player is broken. Even after being “fixed” there’s a chance the player might break right after, as one animation slips through with latency.
As with any “hot fix” this is not a complete solution, this only stops the issue once it happens. It does absolutely nothing to prevent the issue.