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

Help and Feedback Scripting Support
#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?

#38

GetPlayers() assures type safety as it returns {Player}. Sure, you could assert the type but it only applies once and it’s annoying to do it multiple times.

#39

It doesn’t mean you shouldn’t use it either. What is your point here?

The entire point of that is you don’t need to assert at all. You don’t need to double check things that are already guaranteed.

1 Like
#40

When using strict type mode the script will yell at you, and exploiters could insert objects into players service leading to unexpected scenarios. We could have just left it at that, so let’s not veer too far off topic.

1 Like
#41

Exploiters can’t insert things on the server. There is no reason to try to prevent senseless hypothetical situations. If they break their own client that’s on them.

This is a good reason to use GetPlayers if you’re using strict mode.

Left it at what? Your stuff about exploiters is incorrect. I agree though, we are being off topic.

Edit:

They can’t. We’re being off topic, we can talk about this in DMs.

Again, we can talk about this in DMs. While I wouldn’t be surprised if this was possible in an assembly the client has network ownership over, inserting an object into a service would be very suprising and probably patched very quickly. There would also be a bug report for it.

Edit: Reply to @ketrab2004

It’s literally in the documentation:

The Players game service contains only Player objects

(Source)

According to the docs, the Players service should only have players in it. If there is a non player instance in it, that is a bug in the developers code.

Again, I’m not saying GetChildren is better at all, I’m saying that there are no substantial reasons to use one over the other.

Literally anything in Roblox’s docs can change. Roblox engineers might just wake up one day and decide to rename game to experience. The chances of Roblox changing this behavior are so insanely low it’s not worth a millisecond of anyone’s time.

Advising people to make useless changes is just a way to artificially feel superior.

For example, there is no reason to make this change:

When the last reference to the animation track is gone it will just be garbage collected anyways. There is virtually no difference between these two in this case.

Some actual changes might be:

  • The Hold variable name should be hold to follow the naming convention used in the rest of the code
  • Roblox recommends using GetService instead of . for future proofing.
#42

They can, Hacks / Exploits can do that.

And yes, they can.

Its not Impossible

#43 
for _, v in pairs(game.Players:GetChildren()) do
	local char = v.Character
if char ~= nil then
	local hum = char:WaitForChild("Humanoid")

	local Hold = hum:FindFirstChild(“Animator”):LoadAnimation(script.BruceHold)
	Hold:Play()
      end
end

Perhaps this?