Before I could use Object:WaitForChild( 123456 ), but now as of 7/6/2016 (version 0.251.0.78685) using integers throws an error, breaking most of my games.
Argument 1 missing or nil
I have to use tostring( 123456 ) now, but the WaitForChild() function should automatically convert my integers to strings like it did before. Especially if I’m doing something like
Object:WaitForChild( Player.UserId )
or I have objects that are simply numbers
Yikes… this completely broke my game as well.
This needs to be fixed immediately.
You were searching/waiting for objects using an integer as their name? This sounds like bad scripting. Or am I misunderstanding the issue? @Cindering @alexnewtron (edit: i hate not being able to change who I reply to)
Rolling back, patience.
Should be fixed now.
Revert revert pls. Numbers should not work with WaitForChild. The API clearly states you’re meant to use strings: Instance WaitForChild (string childName, double timeOut)
People are having issues at their own fault for intentionally using the wrong type parameter. ROBLOX should not empower users to ignore the API and use it incorrectly.
Manual occurrences of using WaitForChild with numbers can be fixed by pasting the following code in the command bar:
function recurse(root,callback)
for i,v in pairs(root:GetChildren()) do
callback(i,v)
if #v:GetChildren() > 0 then
recurse(v,callback)
end
end
end
for _,child in next,game:GetChildren() do
pcall(function() --Some children of game throw errors when indexed
recurse(child, function(_,v)
if v:IsA("LuaSourceContainer") then
v.Source = v.Source:gsub("WaitForChild%(%d+%)", function(match)
return "WaitForChild(\""..match:match("%d+").."\")"
end)
end
end)
end)
end
The rest of the occurrences where people are using WaitForChild on things like UserId properties shouldn’t be very much, so those can manually be fixed easily.
No it shouldn’t. The object’s name you’re waiting for is a string (even if it’s only numbers), and WaitForChild is meant to be given strings. Use strings instead of relying on awkward/hacky behavior.
If this is the case, then FindFirstChild( 123 ) should throw an error too. But it doesn’t, because this is obviously a bug especially since the error that is being thrown is telling me that I gave it a nil value.
The platform is built for kids, and putting strict values on API would only make the gap wider for learning the platform. Roblox allows Part.SurfaceTop = "Smooth" because it’s easier to kids to understand rather than being forced to use Enum.SurfaceType.Smooth
Why not just use tostring()? That should be the correct way to go about this.
May we please have a patch list of some sort for the general public whenever we do small/big changes like this?
It’s annoying to have one game working fine one day and then 3 hours later the whole game just breaks and shuts down.
My scripting artist literally had a mental breakdown last night because of this.
Which is why Roblox requires to have a patch notes thread, or patch updates document so we know what broke our games.
Thank you
On another note:
Did the revert update get reverted again? Last night’s update broke the game and we can’t figure out why.
Not to sound rude or anything, but perhaps your scripter should stick to the API specifications? As @EchoReaper pointed out, the API does specify that the parameter should be a string.
Did the revert update get reverted again? Last night’s update broke the game and we can’t figure out why.
No, we’re back to the same version we had for the entire week.
While the API clearly states that you’re meant to use strings, we (apparently) have automatic string coercion for all other APIs. I definitely consider this coercion a mistake, but it’s not something we undo by just releasing an update that breaks it.
To be fair, this behavior is part of Lua. It is a dynamically typed language after all. I won’t disagree that it’s weird and maybe unexpected that this happens, but I wouldn’t say it’s especially wrong.
I see your “people should follow the documentation, don’t cater to them!” and raise you:
pcall is an alias for ypcall in rbxlua
I raise you:
Anyone who excused problems/issues of something they were maintaining with “Shouldn’t bother ever fixing this because there are other issues” would end up in a unproductive circular chain of never getting anything done because there will always be something wrong.
Lua allows you control over variables that you wouldn’t see in any traditional language. The benefit is the control I have over my variables. Taking my code and doing unexpected things with it to try and get it to “automagically work” behind my back means super difficult bugs to debug down the road i.e. “Why is my table missing data after getting sent across a RemoteEvent? Oh wait, I mistakenly thought some indices were strings because I was doing x.Text = t[i] without tostring, but it turns out that assumption was wrong because some were numbers and Lua was trying to fix everything for me but caused an even bigger error.”
As it applies to the thread, I can’t figure out what you are talking about. pcall/ypcall? string coercion? scripter having a breakdown because waitforchild is refusing numbers? I am not finding the connection.
Nice PA oops
I imagined you would given that you were the one that made the connection between pcall/ypcall and programming practices as they relate to string coercion.
I am not affiliated with MisterObvious or his projects in any way 
pcall/ypcall does not relate to string coercion. pcall/ypcall relates to poor programming practices. i.e. expecting yields to work in pcall function, enough so that roblox aliased it. (or maybe it has something to do with the lua environment in roblox?)
Speaking of API nonsense, why has WaitForChild been changed to a Function (it was once a YieldFunction), and why does the timeout argument have no default value? @zeuxcg