For _, v in pairs(game.Players:GetChildren()) do only executing on one user

Help and Feedback Scripting Support
#16

Doesn’t change anything,

Both of them return the Player Instance, it doesnt check if there is anything inside

2 Likes
#18

I think I’ve found the cause of my issue.

I had a wait attached to one of the other scripts I was using to control animation.

for _, v in pairs(game.Players:GetChildren()) do
	local char = v.Character
	local hum = char:WaitForChild("Humanoid")

	local Hold = hum:LoadAnimation(script.BruceHold)
	Hold:Play()


	wait(41)
	Hold:Stop()

this then stops the animation after a period, is the script waiting 41 seconds before applying the animation to the next player?

#19

Yep.

The Loop is waiting 41 seconds before moving on, after that, it will skip to the next iteration (next Player if you will), i recommend using task.spawn() or task.defer()

task.spawn(function()
	local char = v.Character
	local hum = char:WaitForChild("Humanoid")

	local Hold = hum:LoadAnimation(script.BruceHold)
	Hold:Play()


	wait(41)
	Hold:Stop()
end)

you may also use task.delay() for the waiting:

task.delay(41, function()
    Hold:Stop()
end)
#20

change

local char = v.Character

to

local char = v.Character or v.CharacterAdded:Wait()

(I assume this is being ran on the server)

#21 
task.spawn(function()
for _, v in pairs(game.Players:GetChildren()) do
	local char = v.Character
	local hum = char:WaitForChild("Humanoid")

	local Hold = hum:LoadAnimation(script.BruceHold)
	Hold:Play()


	wait(41)
	Hold:Stop()
end
end)

I’ve tried this, and the issue persists.

#22

Thats not what I meant, i meant this:

for _, v in pairs(game.Players:GetChildren()) do
    task.spawn(function()
	    local char = v.Character
	    local hum = char:WaitForChild("Humanoid")

	    local Hold = hum:LoadAnimation(script.BruceHold)
	    Hold:Play()


	    wait(41)
	    Hold:Stop()
    end)
end
#23

isn’t task.spawn deprecated? [ char limit]

#24

No?

The Regular spawn() is deprecated, task.spawn() is the newer variant of the deprecated spawn()

task.spawn

#25

isn’t there coroutines now though?

#26

yes, but task does the exact same thing, run along side the current thread, it is also faster as it runs immediately.

task.spawn(function()

end)

local co = coroutine.create(function()

end)

coroutine.resume(co)

Read Documentation tho

but for more advanced cases it’s recommended you familiarize yourself with the coroutine library.

#27 
coroutine.resume(coroutine.create(function()

end)

works too

#28

Yes, but there is really only one difference:

In this case, it would be better to use task.spawn()

#29

Maybe try using game.Players:GetPlayers()) ?

#30

Try this:

for i, player in ipairs(game.Players:GetPlayers()) do
	task.spawn(function()
		local character = player.Character
		local humanoid = character and character:FindFirstChildWhichIsA("Humanoid")

		if humanoid then
			local Hold = humanoid.Animator:LoadAnimation(script.BruceHold)
			Hold:Play()
			
			task.wait(41)
			Hold:Stop()
		end
	end)
end
#31

Players:GetChildren() or Players:GetPlayers() do the same thing and are equally good. As far as future proofing, it’s virtually guaranteed the behavior of either is never going to change.

Coroutines have always been a thing.

This is the same thing as game.Players:GetChildren().

Katrist’s code is very likely the solution (the OP’s and other user’s code should check if the character exists before trying to get the humanoid in addition to running some stuff in parallel with task library functions).

1 Like
#32

why you use GetChildren to get players instance, i suggest to use :GetPlayers() instead. because GetPlayers only get a player inside players childrens

2 Likes
#33

While this is true, you should still use Players:GetPlayers() as that ensures what you’re checking is an actual player, unlike Players:GetChildren() which gets anything.

1 Like
#34

While that is true, it doesn’t matter. You should already assume all the children of Players are of type Player, so GetChildren is also guaranteed to have an array of Player instances.

Even if somehow there was a non-player in Players, it would be good for your code to error and let you know that so it can be fixed.

The two methods are interchangeable and there isn’t a significant reason to use either one. GetPlayers has a guarantee that is already guaranteed, and GetChildren is more consistent with other code. Both of those reasons to prefer either method are insignificant.

tl;dr:
There is no reason to guarantee something that is already guaranteed. There are no significant reasons to prefer or recommend one method over the other.

#35

Just because GetChildren() exists here doesn’t mean you should use it.

#37

And?

Im just saying it does the same thing?