yep it seems to be working now
1 Like
Can confirm this issue is no longer happening in my games. Thanks guys!
2 Likes
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.
7 Likes
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.
3 Likes
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.
4 Likes
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)
3 Likes
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
1 Like
Iāve found the source of the floating-off-the-ground issue, and there is a fix submitted for this.
4 Likes
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)