I’m also noticing that after this update weird black “shadows” appear randomly and flicker in the corners of the map. Some lighting bug apparently.
Hey, thanks for the report. We are looking into this issue.
Using Animator:LoadAnimation() does not help. I am currently working on something using it and the bug still happens.
It’s just a bug with Roblox, we just have to wait for them to fix it. Shouldn’t be that long. The main issues are just animations not loading or loading stiff and broken, as well as some small lighting issues I noticed with shadows.
Thought I’d mention that there is currently an issue with the default animations, you can see a slight flick at the end of each jump in all games. Not only this, the game I’m currently working on has been broken by this update and I’m currently trying to work out why, it involves a custom character and was working perfectly fine before the update.
Mhm its happening to everyone. My idle animation on my custom character flickers as well, and my walk animation dosent even load. They’re working on fixing it hopefully.
I am looking into this right now, with hopes of having the problem resolved shortly. This is not related to the API changes to LoadAnimation, but rather an animation optimization flag that is enabled prematurely.
Having this issue as well. Some animations just don’t stop playing ever for some reason, and other very weird behaviors
It appears to run at a halfway level, and then the “flicker” is where it cuts into the actual animation. Very strange.
Issue has been fixed.
Appreciate the roblox staff fixing it.
yep it seems to be working now
Can confirm this issue is no longer happening in my games. Thanks guys!
Thank you for the quick confirmation. The problematic flag is now off. I would be interested in getting some examples of affected animations, if anyone has available some easy repro places. The change seems to be impacting developer-made animations the most, and I’d like to see if there is a particular pattern in these animations that I need to account for.
How the animations are being blended is probably also significant. One of the changes introduced by the flag in question is a fix to how AnimationTrack blend weights are normalized when tracks weights do not sum to 1.0. I’d like to see if any of the affected games are possibly relying on the old blending behavior in this particular case.
I couldn’t take a video as it was fixed before I could get to it, but I have a game started in 2017 still relying on keyframe names (not markers). I have keyframes that are at the end of the animation which basically lets it know when it has ended so it could play some other effects. Keyframe names at the end of the animation (or near the end) are never fired by KeyframeReached, and for some reason using
AnimationTrack.Stopped:Wait()
no longer worked either (guess it thought it was still playing?). After the revert, both methods work as expected again.
Thank you for this feedback! If you have a particular animation assetId you could share, this would be most helpful, as there are now a large number of event cases to consider. There are special cases in our code already that are meant to cover some existing games’ backwards compatibility issues with how AnimationTrack KeyframeReached, DidLoop, and Stopped interact. I’ve seen a pattern across a number of games where two, or all 3 of these events are being listened to as a sort of “catch all” solution to detecting animation stopping. It’s made still a little more complex by the addition of the new KeyframeMarker system, which offers yet another event, GetMarkerReachedSignal, which developers may use to detect reaching of a certain frame in their animation. Having actual repro cases can really help narrow down which developer use patterns are not being correctly handled or account for.
I’d just like to note that the deprecation of LoadAnimation is completely unrelated to the visual glitching of animations seen today, and something that is being looked into separately.
Animations are still broken on scaled characters because position offset no longer scales with hipheight.
Here’s a temporary solution that I had to write. Since there are multiple client versions running at once, I’m only targetting version 455 with specific build number: edit: since there is a fix submitted for this, fix is only gonna run on version 455 and 456.
local verstrtbl = string.split(version(),".")
local vernum = tonumber(verstrtbl[2])
if vernum then if not (vernum >= 455 and vernum <= 456) then script.Disabled = true; return end else script.Disabled = true; return end
local rs = game:GetService("RunService")
local plrtable = {}
game.Players.PlayerAdded:Connect(function(player)
table.insert(plrtable,player)
end)
game.Players.PlayerRemoving:Connect(function(player)
for i,v in pairs(plrtable) do
if v == player then
table.remove(plrtable,i)
break
end
end
end)
for _,v in pairs(game.Players:GetPlayers()) do
table.insert(plrtable,v)
end
rs.Stepped:Connect(function()
for _,v in pairs(plrtable) do
pcall(function()
local char = v.Character
local hum = char.Humanoid
local rootmotor = char.LowerTorso.Root
local position = rootmotor.Transform.p
local orientation = rootmotor.Transform - position
rootmotor.Transform = CFrame.new(position * (hum.HipHeight / 2) ) * orientation
end)
end
end)
Issue seems to still be present
Before Updating to latest version:
https://i.gyazo.com/be01baf9110daee670905000053d98d8.mp4
After Updating to latest version:
https://i.gyazo.com/7ef58acc2ec20fc50fc92c72efb6d0d8.mp4
Even bigger character in latest version:
https://i.gyazo.com/f2ef6a119ee1f567dd91ab0cda284b35.mp4
I’ve found the source of the floating-off-the-ground issue, and there is a fix submitted for this.
Anyone have issues where it looks like animations that involve moving the HumanoidRootPart now move too far or too short? It’s almost as if my animations were corrupted
Before
After (the video is laggier cause it was recorded on a different computer but notice how now the characters clip through the floor and walls and objects)