As a Roblox developer, it is currently too hard to …
Create a Tool (Instance) that IS compatible with the rest of the features on the Roblox Engine, so that it is distributable as a Model or as a Place itself, for anyone to learn from and use, or for quick Bug Reproduction games. As example, a Tool that you can use with ClickDetector as well.
With compatible I mean:
- Supports the built-in Backpack System from the Roblox Engine.
- Does not require aid from external custom ModuleScripts to receive Input from.
- Simple Drag-And-Drop out of the Box for everyone, and any default Template Game, e.g. Baseplate.
- Works together with ClickDetector. It works together with ProximityPrompts already.
It is TOO DIFFICULT to create a Tool that doesn’t block built-in ClickDetectors.
- The only way to create such a Tool is by not using the Tool Instance.
- Any support by Scripts to make a Tool support ClickDetectors is not a solution due to performance. The Tool is enforcing that “Cursor Pointing Finger Icon”, built-in by Roblox.
- Not using the Tool Instance, would also mean No Default Support for the built-in Backpack.
It’s so difficult, that even during the RB Battles Event, an issue was encountered where one wanted to use a Tool and ClickDetector’s on Stickers, and had to alter something, so it doesn’t use Tool Instances or ClickDetectors anymore.
With a planned change to Accessories and Particles in First-Person, it is impacting a workaround that I’ve seen: Hiding Avatar Particle Effects in First-Person
Those games that use this “workaround” are actually using Accessories or other things. But Accessory Instances, specifically because it inherits similar features that Tools do. And if Accessories have Particles, those Particles would also disappear due to the First-Person update, and the developer wouldn’t be able to control it without altering default PlayerScripts.
Tools and Accessories are a-like:
- They also rely on “Handle”, and seem to share the same system.
- When an Accessory gets moved into a Character hierarchy, it will put itself at the needed location, same way Tools do.
- Accessories universally adapt to the required Attachment Location, the same way Tools do. The
RightGripAttachment - Accessories adapt based on Avatar Scale.
However Accessory Instance is not a perfect Tool replacement:
- You have to implement the clicking and rest of logic.
- They don’t work with the Backpack, making it completely not a replacement at all, only partially
- It’s not worth as a workaround, just because it supports
RightGripAttachment - Removing an Accessory from the Character hierarchy, distorts the location of the Constraints afterwards, unlike when dropping a Tool.
See an example from here:
The Tool’s position of both look the same. Difference is that Tools come with pre-defined input logic and equipping logic. Accessories don’t, but Accessories don’t block ClickDetectors, as you can see in the image by looking at the cursor.
If this issue is addressed, it would improve my development experience because …
You’d be able to use Tools and ClickDetectors together. Whether one should use ClickDetector in general is another question.
- You can share it to others without any other dependencies such as Frameworks. Because it would be compatible with the rest of the vanilla Roblox Engine.
- You can click on ClickDetectors without having to unequip a Tool.
- ClickDetectors have a Hover Event, but those don’t trigger when it is obstructed, hence why a Raycast with a special Collision Group would be better.
- It allows for simple games, like quick Test Games.
Some use it so you don’t have to use Raycasts (due to performance) to determine whether your cursor is on a part or not, to do specific actions, e.g. ClickDetector’s Hover Event. Reliability regarding that is another question.
Because a Raycast relying on Render things can be very scary to performance if it is used wrong, and sometimes can require implementations of separate CollisionGroups with Collision Filters.
Nowadays, one should use ContextAction or UserInputService for Input. The Tool is still a unique Instance that works with the default built-in Backpack System. And also received VR Laser Pointer updates by Roblox, apparently.
In one of my recent use cases I wanted to create a Test Game for something where you’d have a Tool Instance equipped at all times. But then I remember that ClickDetectors and Tools can’t be used together. Because the Tool Instance prevents it.
You can click on 2D UI, but you can’t click on 3D Buttons without scripted Raycast or ProximityPrompt, or BillboardGui a-like things within the PlayerGui.
I wanted to use ClickDetector Instances with Tool Instances at that moment.
The HopperBin is an older instance inherited by BackpackItem. Infact the HopperBin reveals the ClickDetector Cursor if it’s not in “Script” Mode, but doesn’t let you click on it. Revealing that it is possible to change the behavior. And the “RequireHandle” Property was added through the inspiration from the HopperBin, I think.
The HopperBin in its “Script” mode is sort of the equavilient of a Tool.
If there could be a way to have a Property that disables this forced behavior, it would be great.
Because Tools force this icon as well, and I’d hope for a Tool Instance that doesn’t force this behavior.