How can I fix my seat script to stop this animation whenever the player leaves it?

Help and Feedback Scripting Support
#1

I’m trying to make these seats have specific animation connected to each of them, which the animations are stored as a child of the seat script, and the animation correctly applies, but I can’t figure out how to make the animation stop whenever the player leaves the seat

I’ve looked around and tried different solutions I found online but either none of them worked or the way they did their animation was different.

image
This is the script in the seat, but the seat.Occupant.Jumping function doesn’t stop the track. Any help is appreciated.

1 Like
#2 
local seat = script.Parent
local animation = script:WaitForChild("Animation")

seat.Changed:Connect(function()
	if seat.Occupant ~= nil then
		local track = seat.Occupant:LoadAnimation(animation)
		track:Play()
		repeat wait()
		until seat.Occupant == nil
		track:Stop()
	end
end)
#3

local track
script.Parent.Changed:Connect(function(p)
if p == “Occupant” then
if script.Parent.Occupant ~= nil then
track = script.Parent.Occupant:LoadAnimation(script.Animation)
track:Play()
print(track.IsPlaying)
else
track:Stop()
print(track.IsPlaying)
end
end
end)

Also the other guy’s script is a bit problematic and not good practice and not good for optimization and whatever. Also, use the animator:LoadAnimation() instead of humanoid:Loadanimation because its deprecated. By the way this is a server script, I’m pretty sure you were using a server script too but you should parent the server script in serverscriptservice/serverstorage because exploiters could read these scripts since they’re in the workspace.

1 Like
#4

You need to keep track of who is sitting in the seat, and also keep a reference to the animation that is playing.

Once the seat is empty, look at the reference of who was sitting there, and the animation reference and tell it to stop

Always check to make sure the player is in the game still, because an empty seat could mean they disconnected.

This should be done in a local script.

#5 
local seat = script.Parent
local anim = seat.SitAnim
local occupant = nil
local animation = nil

function StopAnimation()
	if occupant and animation then	
		local player = game.Players:GetPlayerFromCharacter(occupant.Parent)
		if player then
			animation:Stop()
		end
		animation:Destroy()
	end
	animation = nil
	occupant = nil
end

function PlayAnimation()
	if seat.Occupant then
		occupant = seat.Occupant
		animation = occupant.Animator:LoadAnimation(anim)
		while animation.Length == 0  do task.wait() end
		print(animation.Length)
		animation.Priority = Enum.AnimationPriority.Action2
		animation:Play()
	end
end

seat:GetPropertyChangedSignal("Occupant"):Connect(function()
	if seat.Occupant then
		if not occupant then
			PlayAnimation()
		else
			StopAnimation()
		end
	else
		StopAnimation()
	end
end)
1 Like
#6

Why on the client? For optimization? I don’t think it’s a massive issue.

#7

How is it problematic? It’s functional without problems and stuff gets deprecated every week. At the end the result counts and i don’t think your messy code will help anyone.

#8

since it’s visual feedback you’d tend to want it to react as fast as possible. Hence it’s more suitable to be run on a localscript.

  • this is a cosmetic thing and doesn’t affect the game overall.

(it’s why bullet tracers in most games are rendered client side via a localscript)

#9

If it was on a local script, wouldn’t that mean the animations won’t show to other players? Or does the animated rig just automatically go to the server even if its changed locally?

#10

Because you should always use things like repeat, while loops, etc as less as you possibly can. Obviously use it when you gotta, but luau is an event-based language. Repeating unneccessarily will put strain.

#11

That’s not a good mindset to have, as a programmer you should always be trying to make the best code you possibly can with the least problems. If you have an easy option to choose between deprecated and new, would you really choose deprecated? One day you’ll have to fix your game and go back through it to fix all the deprecated stuff you didn’t bother to change.

#12

Speaking of deprecated methods don’t use wait(). task.wait() is what you should be using.

#13

It will show on a local script, don’t worry about that. Test it out! Good luck to you.

#14

Oh yeah that makes sense. I can see why you’d want it on the client.

#15

But, wouldn’t this not run if the seat is a descendant of workspace? If this is a local script.*

1 Like
#16

Deprecated doesn’t mean it’s not working anymore. It means it doesn’t get updated anymore, but i understand your point. Sometimes it is necessary to make compromises in order for something to work properly. If i know what I’m doing with something that is deprecated it’s better than doing bad work with something I don’t know just because someone recommended it.

1 Like
#17

I understand your point too, I used to be like you. Using deprecated methods and what not but I grew out of it.

While it may be easier it certainly isn’t the better option, you’re thinking short-term rather than long-term.
Also, don’t just take my word for it. Research yourself, i’m not pulling things out of thin air. There are reasons why you shouldn’t use deprecated stuff you were using. For example, hum:LoadAnimation()
and wait(), Why they deprecated hum:LoadAnimation()
wait() is worse than task.wait()

1 Like
#18

Why wouldn’t it? if you’re thinking that it will be nil you can just do workspace:WaitForChild(“Seat”). That’s if you parent your local script to the starterplayerscripts, if you parent it to the startercharacterscripts it would be easier as the seat wouldn’t be nil since your character would’ve loaded already but i’d recommend putting the waitforchild in there anyway just in case.

#19

Well, don’t local scripts just not run if they’re under workspace? This code would imply the script was under the seat part in workspace.

#20

Oh yeah I did that because I did it in a server script but I just wanted to save time since I wasn’t actually gonna add this into studio or whatever I just pretended that I parented the script under the seat, but what you should do is make a server script and parent it under serverscriptservice/serverstorage and reference the seat by doing workspace.Seat, then do what I did. Or you could take @SelDraken’s approach of doing this on the client. Either one is fine, but I would do it on the server because I wouldn’t want exploiters reading that. Your choice though. If you wanna do it on the client obviously parent the local script under the starterplayerscripts/startercharacterscripts and then do workspace:WaitForChild(“Seat”)