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
isnât task.spawn deprecated? [ char limit]
No?
The Regular spawn() is deprecated, task.spawn() is the newer variant of the deprecated spawn()
isnât there coroutines now though?
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.
coroutine.resume(coroutine.create(function()
end)
works too
Yes, but there is really only one difference:
In this case, it would be better to use task.spawn()
Maybe try using game.Players:GetPlayers()) ?
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
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).
why you use GetChildren to get players instance, i suggest to use :GetPlayers() instead. because GetPlayers only get a player inside players childrens
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.
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.
Just because GetChildren() exists here doesnât mean you should use it.
And?
Im just saying it does the same thing?
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.
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.
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.
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:
Hold variable name should be hold to follow the naming convention used in the rest of the codeGetService instead of . for future proofing.They can, Hacks / Exploits can do that.
And yes, they can.
Its not Impossible