Wouldn’t making a new instance be a great way to satisfy both parties? Older games can keep their functionality and newer games can take advantage to the new behavior.
It fundamentally ends up with the developers working on it.
Maintaining two things simultaneously is difficult, but I am slightly in for your idea.
Yes but that comes with a really high maintenance and ecosystem cost. Now both code we write internally and code developers write externally has to care about the fact that both exist.
The amount of breakage here was quite low which is why we were willing to just make the change. Only ~300 experiences with non-zero player count were impacted in any way and of those the core gameplay in most of them wasn’t affected, only some rare supplemental tool interaction. Furthermore we reached out to the few larger experiences and got them to update ahead of time to avoid any significant player impact.
4 Likes
Wouldn’t it be possible to only apply this behavior to games that have been opened after this update in studio?
This might break old games which don’t have active developers.
I didn’t read that only 300 games with players seem to be affected which seems very low.
But this approach could be used in the future, old games don’t care about new features.
2 Likes
I think it’s amazing that you’re able to detect potential breakage and reach out to individual developers ahead of time. In the future I hope this idea of breakage detection and direct contact is expanded upon so more drastic changes are easier to justify.
1 Like
Are there any other unmentioned side effects of this recent update? My game’s tools no longer work due to the server not seeing children inside equipped tools anymore. I’ve posted further information about my issue here. This started occurring approximately near the same time that the update was announced.
Nice feature! I’ve always needed to transport all the parts of a tool to a specific location in the workspace and doing that was always a hassle. I had a condition set up a few days before it would take effect:
if tool:IsA("Model") then
Now, I can just use PivotTo.
I do not think tool:IsA("Model") → true is a good idea. Alot of my games ultilize this, as getting characters from the tool. Not only this is not backwards compatible, It does not make sense generally.
Other than that, the extra functions in the tool that are like models is pretty good.
This also broke any code that expects Tools and Models to be mutually exclusive as they have been until this point. I’m not saying it’s bad to modernize things, but the :FindFirstAncestorWhichIsA("Model") use case certainly isn’t the only way something will have broken with this change.
if <thing>:IsA("Model") then
-- Do thing
elseif <thing>:IsA("Tool") then
-- Do other thing
end
Yes, unfortunately there are other ways out there you could write code but they aren’t common patterns. So far I’m only aware of 3 cases of breakage.
We analyzed the top 10,000 marketplace models and of the handful of instances of :IsA("Tool") none of them were broken by the change. That among other other sources of info were used to build confidence that we could limit the number of place breakages to a very low number.
It’s probably better to use class name checks anyways due to other unwanted inheritance issues.
Seems like this change is causing weird jank with Humanoid.EquipTool and tools created on the client 
The tool weld isn’t created unless EquipTool is called 1 heartbeat after the tool is created. This is probably a weird edge case, but this only started happening after Tool:IsA(“Model”) returned true.
1 Like
Do you have a test case file demonstrating what used to work but doesn’t? I can look into it.
Here is a test file demonstrating the bug. For some reason the fix I mentioned earlier isn’t working anymore. Make sure you click the button on the right a few times.
toolbug.rbxl (51.6 KB)
I have been having problems with my tools ever since this update - didn’t know what it was till someone sent me this way. Sometimes players get the tool - however when manually forced to give the tool and once they die it disappears for good. The scripts use IsA(“Model”) and tried IsA(“Tool”) and it made no difference.
Could you try to make a minimal place that reproduces the issue? It’s not clear exactly what circumstances you’re talking about and it would probably be easiest to just show me an example that doesn’t work.
For some reason a roblox update that occured a few weeks ago (I think this one) broke the cooking system of a game that I worked on, now the tool falls out of the hand of the player and falls through the map
More background Information, I’m doing lots of manipulation of the Tools on ServerSide and ClientSide
It has worked perfectly fine a few weeks ago, I didn’t touch anything for a year.
But now a bug occurs, and it is not always occuring but sometimes.
I’m using Manipulations
Such as:
Tool.GripForward = Vector3.new(-0, 1, -0.002)
Tool.GripPos = Vector3.new(0, -0.09, -0.057)
Tool.GripRight = Vector3.new(1,0,0)
Tool.GripUp = Vector3.new(-0,0.002,1)
and:
local GripForward = Tool:GetAttribute("GripForward")
local GripPos = Tool:GetAttribute("GripPos")
local GripRight = Tool:GetAttribute("GripRight")
local GripUp = Tool:GetAttribute("GripUp")
Tool:SetAttribute("Done",true)
if GripForward then
SimpleTween(Tool,0.5,"Quad","InOut",{GripForward = GripForward})
end
if GripPos then
SimpleTween(Tool,0.5,"Quad","InOut",{GripPos = GripPos})
end
if GripRight then
SimpleTween(Tool,0.5,"Quad","InOut",{GripRight = GripRight})
end
if GripUp then
SimpleTween(Tool,0.5,"Quad","InOut",{GripUp = GripUp})
end
The tool simply falls out of the map while Tweening (not always)
or when unequipping and equipping the tool or when handing it to someone by parenting it so someone elses Backpack and the person equipping it. (not always)
It is happening fairly often.
1 Like
Here is footage of the bug occuring (Also in one case without attachment manipulation):
I’ve also attached one of the food tools where the bug occurs
One Dish.rbxm (32.0 KB)
I’ll look into it, thanks for the detailed info.