Ah wait nevermind, you were mentioning about making tools unequipanle, sorry I misread the post
Summary
Tool.CanBeDropped :: boolean
Tool - Roblox API Reference
1 Like
Detecting if a queried BasePart is a descendant of a Character is definitely a widespread practice and this change would probably break a lot of stuff.
Although if you guys are to go through with this, maybe adding something like Players/GetPlayerFromDescendant would be a nice alternative to boilerplate code.
2 Likes
I don’t think this is safe long-term either. I could totally see character becoming Actor at some point, at which point, now your code is broken.
6 Likes
This… seems like it wouldn’t work anyways? Surely there are other conditions that are met?
Raycasting then using FindFirstAncestorWhichIsA(“Model”) would mean any model in your game would be returned. What was your other criteria for detecting if it was a player, that imply a tool would qualify??
Genuinely confused on this one.
1 Like
Hmm… you shoot at a player, you hit their tool, script uses findfirstancestor blah blah blah to get the Character hit(and thus the player)?
Is that confusing? Once you get the model you can figure out if its a Character or not. But with the tool update, you will find the tool and not the character model.
3 Likes
The extra condition you’re recognizing is that if you have other Models underneath the character it wouldn’t work. However, having other Models underneath the character is quite rare, and never happens with a default avatar. Technically it happens with the default character with the Status container if you actually use Humanoid Statuses for some reason, but the Status container will never have any parts under it.
2 Likes
Right, the problem will come when someone’s tool which contains parts runs into a .touched event or is hit by a ray that expects no models with parts to be in a Character.
The script can be fixed pretty easily but the big problem here is that it will have to be fixed and many games will not have support team or owner to fix it.
1 Like
I guess I can see this, but to me it still feels like a well-coded system should not fall under this problem to begin with.
2 Likes
Seems like the only possible solution to save this way of finding the character and adding the Model class to tools is to make :FindFirstAncestorWhichIsA search for only Model instances and ignore combination of several classes, other than raw models.
Which is probably not going happen to happen…
And it may break some other scripts that use this function to find combination of classes.
In your code, what if you want a tool part being hit to count as hitting a player(such as a limb)? Otherwise the tool becomes an unintentional shield, no?
You cycle through every player to see if a part that was hit is one of them? For every hit? Seems like a lot of overhead, how performant is this?
This doesn’t help unless you are starting with a model. If you are starting with a part that may or may not be a foot, hand, tool part, etc. You have to search up the tree, not down.
I like @Dogutsune 's example. For a simpler method this would do the same:
hitmodel = hitpart:FindFirstAncestorWhichIsA("Model")
if hitmodel:IsA("Tool") then
hitmodel = hitmodel:FindFirstAncestorWhichIsA("Model")
end
--at this point hitmodel is your Character if you have hit a character body part or a tool, or its not a character.For a simpler method:
local model = part:FindFirstAncestorOfClass("Model")
4 Likes
I guess it depends how often you are using it. In my cases, I’ve never had any issues
Nice, find/replace-all, done! 
The Tool class will still exist and keep it’s current behavior. Simply, Tool will adopt Model's API, the keyword here is inherit. With that being said, the Tool class is where the .Equipped event and almost everything that makes a Tool a Tool is.
This API change adds the functionality to the Tool class which it doesn’t already have.
The Model & Instance class will remain untouched.
Please correct me if I’m wrong, but isn’t that what they are doing? The class tool (and backpackitem) is still there, they’re just adding another level of inheritance between backpackitem class and instance.
2 Likes
I feel as though you can nip any backwards compatibility woes in the bud if you added an overload to IsA which determines whether or not tool:IsA("Model") respects this upcoming inheritance change.
Something along the lines of:
IsA(self: Instance, "Model", respect_tool_inherits_model: boolean?)
Which’d make any code calling Tool:IsA("Model") have to acknowledge the new Tool inheritance instead of quite literally being blindsided by it, aka the current trajectory this API change is headed.
1 Like
That’s horrible lol… I think this change is just a band-aid situation, people are going to have to adjust their code if they’ve been writing lazy code, bottom line.
11 Likes
They’re still gonna have to adjust it whether or not their code is “lazy”.
1 Like