Upcoming API change: Tools inherit Models

Updates Announcements
, ,
#46

I still find tools almost entirely unusable because of the baked-in backspace behaviour; it’s the only reason I find every reason to avoid using tools unless the experience I’m working on doesn’t care about that behaviour. Besides that, having Tool inherit from Model is great, especially now that it would be possible to designate a PrimaryPart for a Tool for welding/attachment purposes.

ETA: Since two people have replied: I’m not talking about CanBeDropped. I’m talking about the built-in behaviour for the backspace key that invokes blackboxed behaviour to drop the tool into either the world or the backpack based on the property. CanBeDropped does not disable the baked-in backspacing behaviour.

8 Likes
#47

so you can put characters in the StarterPack?

1 Like
#48

??? There’s no mention of characters in the original post or the thread. Models aren’t only used for characters.

2 Likes
#49

This is great! i always had issues moving tools around, especially ones with multiple parts! it would get the handles and welds messed up! glad tools are finally becoming easier to use!

1 Like
#50

The first screenshot are the methods from the Tool class, the bottom are the methods inherited from instance.

1 Like
#51

I truly love this update! I now don’t have to turn a tool into a model to place it in the world. :smiley:

(I would turn it into a model, to change its position, mainly because it didn’t have any weld and I couldn’t just use CFrame on the handle)

2 Likes
#52

What’s wrong with using Instance:FindFirstAncestorOfClass('Model')?

#53

For some reason inheritance and class hierarchy is so incredibly confusing to so many people here.

How it currently is:
image

How it will become:
image

Tools are still tools, models are still models, things that are already models will continue to be models, and models will not become tools.

However, tools will also be models, so functions and properties on models will also be available on tools. Thanks for coming to my TED talk.

18 Likes
#54

So, to be certain the tool Instance Class will remain it will just inherit properties from the Model Class?

#55

Yup, the change is purely additive, with Tools gaining additional capabilities (having PrimaryPart / pivot and related methods)

3 Likes
#56

Yes I know, that is exactly what I said :laughing:

#57

Assuming you’re referring to dropping, that behaviour is disableable.

https://create.roblox.com/docs/reference/engine/classes/Tool#CanBeDropped

If you’re referring to the ‘return’ behaviour (i.e. tool being unequipped) then I’d be curious to hear why it’s such a breaking issue for your games.

#58

Will tool:IsA("Tool") still return true? This small line of code is an essential piece to my main framework, and changing this would be a pain in the b*tt.

#59

Yes. Please see PeZsmistic’s post for a more in-depth explanation, but – in summary:

1 Like
#60

So it will be both a model and a tool? But doesn’t the “IsA” function reflect on the ClassName?

#61

image
image891×231 38.6 KB

IsA respects class inheritance. A tool is simultaneously a tool, a backpackitem, a model, a pvinstance, and an instance (or will be).

4 Likes
#62

It’s not the ability to drop tools to the world or the backpack, it’s backspace itself invoking any kind of baked-in behaviour. I avoid using tools because of that.

Not being able to backspace tools isn’t a breaking issue for my experiences; if it is, I write my own tool management system from scratch and avoid tools. It has more to do with the intentional design of my experiences that use tools that I don’t want being unequipped. I should not have to force the tool back into the character to attempt to void this behaviour.

This doesn’t just go for Roblox experiences. Outside of Roblox, you write this logic yourself anyway. Developers should be able to control over when they want tools being equipped and not. Roblox bakes this into the tool object and the backpack CoreGui; when you disable the backpack CoreGui, you’re left only with the baked-in unequip behaviour which is gross. I know when I want to control the equip state of a tool and I don’t want Roblox black-boxing it from me.

7 Likes
#64

Great news! This will fix a minor issue with a plugin that I installed and I’m happy about it.

#65

Will this affect tools that are being used to play an animation?

#66

Work-arounds aren’t helpful if the game is abandoned. I suspect there are many playable games out there that have no devs at this point.

I suspect this is a fairly widespread and common practice of finding the character model from a touched part or ray cast.

(I just checked my game and I only have 20 scripts that will require fixing)