I’m sure this is intentional but I’d like to know why.
This is problematic because oftentimes tools perform some sort of cleaup when they are unequipped, but if the player happens to run into some lava or gets hit by an explosion, the handle of his tool may be destroyed. This means when he switches to another gear, the Unequipped event won’t fire so the tool won’t have a chance to remove its effects.
This was intentional. However, I’m pretty sure they did this in favor of HopperBins when they were still a thing. If you ask me, tools are quite outdated to how they should preform. There’s a lot they can do to improve their reliability.
although, it’s hard to improve old instances without breaking games that use it’s old functionality. I assume this is why they haven’t remade Humanoids yet.
That reminds me, a simple work around to this issue would be monitoring for when the handle is removed with, then creating a new handle back, then using Humanoid:UnequipTools(). This should work I imagine. (You may also have to create a new RightGrip to the tool)
This is still a thing. Not only if the Handle is removed, but if it isn’t there in the first place, the tool can still be selected and delected - it will still parent between the character and backpack - but the events do not fire.
Is this an issue if Tool.RequiresHandle is false?
Can confirm that this is still a thing.
How to Fix:
I was actually about to post some help in scripting support until I found this bug report.
I hope that this helps someone experiencing this issue.
Nothing like a reply over a year later
This behavior still exists and is extremely annoying to work with.
Bumping so hopefully staff sees this.
to my knowledge this is still happening? I haven’t found a fix for this besides forcing the player to unequip everything and waiting a second or two
I have always use Tool.Equipped and Tool.Unequipped without a handle. You do require to have RequiresHandle = false to have these events fire. If you don’t have it set to true; this is intended behaviour. ContextActionService.LocalToolEquipped and ContextActionService.LocalToolUnequipped bypass this restriction.