Just recently I wished this was a feature! Glad to see it being added now - will make dealing with tool positions a lot easier. Small change but good change.
1 Like
Here’s an implementation which just repeats FindFirstAncestorWhichIsA until it finds an inheritor of Model that isn’t a Tool.
local function FindCharacter(instance: Instance)
while not instance:IsA("Model") or instance:IsA("Tool") do
instance = instance:FindFirstAncestorWhichIsA("Model")
end
return instance
end
Another thing that can be done for tools is simply to do this:
local tool = instance:FindFirstAncestorWhichIsA("Tool")
local character = tool.Parent
This is a pretty robust way to do it, it works pretty much identically to local character = instance:FindFirstAncestorWhichIsA("Model") did, because equipped tools go into the character directly.
Everything is nice except for the shared :IsA(“Model”)
Only benefits, and a single change that will have to be made when finding a player character from a part (often RayCasts):
part:FindFirstAncestorWhichIsA(“Model”)
Becomes:
part:FindFirstAncestorOfClass(“Model”)
I see a lot of people making it more complicated than it is, and while it could indeed break older games that are no longer supported, the actual better use all along was using the Class function.
4 Likes
You’d have to recursively search through its ancestry until you either find a model with a humanoid in it, or until there’s no longer a model ancestor left. Like so:
local function IsPartOfCharacter(Object)
local ModelAncestor = Object:FindFirstAncestorOfClass("Model")
local Humanoid = ModelAncestor and ModelAncestor:FindFirstChildOfClass("Humanoid")
if Humanoid then
return true
elseif ModelAncestor ~= nil then
return IsPartOfCharacter(ModelAncestor)
end
return false
end
An even easier solution though, is to parent all characters in folders. You could then call :IsDescendantOf or FindFirstAncestor.
This is changing the base class of tools, not its actual class. Yes :IsA(“Tool”) will still work.
1 Like
Maybe it could only be applied to games that have been opened in studio after the update so old games don’t break.
1 Like
If they changed characters into actors it would have to be toggle-able and default to off for old places to avoid breaking any code, because scripts under actors run in entirely separate environments. So any developer that enabled it would be able to notice and fix any incompatibilities, including the one mentioned.
1 Like
Point here is that it’s not fully backwards compatible. What once was reasonable, now isn’t.
That was the question I was answering:
1 Like
I don’t see why it shouldn’t??
At that point they might as well just create a separate class that just represents character models, instead of bothering with actors at all.
real subclass moment, nice; altho im personally not sure how i would properly implement this
Bruh, so the tools instance/class will get removed?
no.
The Base Class for Tools will now inherit from Model instead of just Instance.
To clear the confusion up, the Tool object will now inherit from Model instead of Instance. Instance is just the base class for all objects, and when the Model class inherits Tool, the properties that every model has will now be on tools, along with what Tools originally had.
As a result of this change,
Tools will now have a Pivot and Transform section.
That’s going to be a problem because now I have to do some major code rewrites and really think about handling this in existing code. I mainly use it in touched events to see if a player has touched a part or not. If I’m going to have to do a rewrite, then I’m going to make it a callable function so the code exists in one place only, but that causes it’s own issues.
Change IsA:(“Model”) to OfClass(“Model”). A tool will be a Model, but is not of the Class Model.
Well, there’s two problems. First one is that some games will be broken cause of this when there are lines in scripts like this: if item:IsA("Tool") and it will take a lot of time to replace all the lines if you have a game with a lot of scripts.
Second is all models will have the events that tools have. That would cause confusion for new developers and probably cause some errors as well. I don’t really like this change.
Read the comments. That’s not how inheritance works, IsA("Tool") will still work as it always has.
That’s still not how inheritance works. Again, read the comments addressing this because the people above me have already spelled it out plainly. The only change is that Tools will be both IsA("Tool") and IsA("Model"). IsA takes inheritance into account. That’s why IsA("BasePart") and IsA("Part") both work. And Tools will have Model events and methods. Models won’t have Tool events or methods. Inheritance is one-directional.
3 Likes