The default animation for holding a tool is arm straight out. I wanted to change this so I have a LocalScript inside my tool. I put an animation under the LocalScript with the ID set in. Here’s my code:
local Player = game.Players.LocalPlayer
local Character = Player.Character
local Humanoid = Character:FindFirstChild(“Humanoid”)
local Animation = Humanoid:LoadAnimation(script.Animation)
local Player = game.Players.LocalPlayer
repeat wait() until Player.Character
local Character = Player.Character
local Humanoid = Character:FindFirstChild(“Humanoid”)
local Animation = Humanoid:LoadAnimation(script.Animation)
script.Parent.Equipped:Connect(function()
Animation:Play()
end)
script.Parent.Unequipped:Connect(function()
Animation:Stop()
end)
A LocalScript in a tool (which will start under a Backpack) will often run faster than the character can be added. If you wish to retain this strategy, make sure to use what the engine provides and have the script wait for the character. This is a better solution than any loop can provide.
local Player = game:GetService("Players").LocalPlayer
local Character = Player.Character or Player.CharacterAdded:Wait()
The above line of code will evaluate both sides of the or. First, it will look for a character. If it’s falsy (false or nil), then it’ll look to the CharacterAdded signal and wait for it to fire, then send the parameters back as variables.
Due to the way character loading events and the backpack work respectively, it’s not particularly advised to do player variable assignments up at the top. You may want to look into some kind of initialisation function of sorts. That’s to say: LoadAnimation is also capable of failing if the character isn’t parented to the workspace.
The RbxCharacterSound script has some insight as to what you should do before initialising functions on characters. Involves waiting for a lot of signals, avoiding memory leaks and whatnot.