Is there a way to disable tool autoequip on pickup?

You can write your topic however you want, but you need to answer these questions:

  1. What do you want to achieve? Keep it simple and clear!
    I want to disable auto equip when a tool is picked up.

  2. What is the issue? Include screenshots / videos if possible!
    The issue is that when you walk over a tool, it auto equips, is there a way to disable it?

  3. What solutions have you tried so far? Did you look for solutions on the Developer Hub?
    I looked at some solutions in the developer hub and forums but none of them suit my needs, I also tried looking through the Roblox core functions. But I couldn’t find one that works.

Any help would be appreciated. Thank you!

4 Likes

you could create a custom tool pickup system

1 Like

When you make a tool in roblox and name the handle “Handle” this creates a child named “TouchInterest” which allows players to pick up the tool automatically when touched. Simply use ChildAdded event to detect when this touchinterest is created and destroy it.

local Event = Tool.Handle.ChildAdded
ChildAdded:Connect(function(Child)
if Child.Name == "TouchInterest" then
ChildAdded:Disconnect()
Child:Destroy()
end
end)
2 Likes

Great solution :smiley:

I would also suggest anchoring the handle when it comes to rest. Players walking over the part can collide with and move the handle around.

Good idea

30char

Also forgot to mention OP make sure you can disconnect this event once the child has been destroyed since it would have no more use and disconnecting the event would free up any memory being used.

if he creates a pickup system, wouldn’t it create another TouchInterest when its dropped again?
he could keep a server script inside the tool that automatically removes it when the tool parent is changed to something other than a model containing a humanoid, starterpack, or backpack.

Imagine you have 10 clients, that means 10 server-scripts are replicated to 10 clients.
and this could lead to computation/memory usage impact. So I recommend to parent client-scripts to the tool and then have one server-script for remote events.

Just turn off “CanBeDropped” to false, not sure why OP would allow players to drop tools if he doesn’t want them to pick it up.

Just set the parent of the tool to the players backpack when it’s equipped for the first time.

Clients do not run any server-side scripts, they are simply told that a Script instance exists alongside some properties. only one affected would be the Server itself hosting.

10 server scripts isnt the end of the world, brickbattle gear feature this with their projectiles as they have their own server script to handle collisions (paintball gun, slingshot, rubber ball, rocket, bomb, etc)

OP should disable dropping tools if they need not be dropped, and if he wants to implement his own pickup script he can rebind Backspace to a function that’ll handle the removal of unwanted tools, and a method of returning them to the backpack.

But, that’s bad practice, having a server script for each different tool or to handle collisions like that, that could be placed in a single module script and ran by a single server script.

Not to mention this causes more time then you think, as you’re probably retyping the same code with minor changes, when you could just use a more dynamic script.

It also causes beginners to rely on Server Scripts and Local Scripts, and will leave them with bad habits that they’ll need to get over if they continue roblox development.

Plus I agree on what with @Amritss has to say about what OP should do.

1 Like

I should’ve clarified, I meant that if there are 10 clients what games usually do is they clone the tool into the player’s backpack and the server-scripts parented to the tool are also cloned and then the server-code runs whenever the player does something on the tool such as activating it if the server-script has a tool activated event.

The server already has alot of workload, so doing this would be worse and if your game does get popular its basically gonna be unplayable at some point

Also how do you know brickbattle does this? You’re a client, you can’t see server-scripts.

Imagine you have 50 players in one server, 50 server-scripts. 50 events connected (minimum!), all taking up tons of memory.

local ChildAddedConnection = game.Workspace.ChildAdded:Connect(function(InstanceAdded)
	if InstanceAdded and InstanceAdded.ClassName == "Tool" then
		if InstanceAdded:FindFirstChild("Handle") and InstanceAdded.Handle:FindFirstChildWhichIsA("TouchTransmitter") then
			InstanceAdded.Handle:FindFirstChildWhichIsA("TouchTransmitter"):Destroy()
		end
	end
end)

whenever a child is parented to workspace this function is called, function checks if returned child from the ChildAdded event is a Tool.
it then checks if said Tool has a handle, then checks if it has a TouchTransmitter (TouchInterest) and Removes it if it exists.

If you think this could be written more efficiently or smaller then by all means reply with your critique and own code; I’m always wanting to learn!

Yes, I believe it could be written more efficiently (even though you didn’t reply to me)

This event won’t just run for the touchinterest, but for other children being added aswell. Granted that’s what my code also does, but there’s a difference.

The workspace has tons of children being added to it all the time, this event would fire more frequently which would take longer to process and thus impact frame rates. Especially if you had a big map, you may have hundreds of baseparts and this event would fire for alot of them.

Whereas, my code only runs for a child being added to the handle. And the only child that really is added to the handle is the touchinterest.

The only other child I could really think of being added to a handle may be a weldconstraint

By the way from the posts before the reason why having these memory leaks are so detrimental on the server is because a server could run for days or weeks. Making the player experience horrible for many, whereas atleast with client memory leaks it’s only for one client and would end after the client leaves and not affect anyone else in the server (but you should optimize both memory usage on the client/server).

Thank you! Ive been looking for a solution for ages and couldn’t find one. Your a lifesaver man!

1 Like

Yeah no problem, always happy to help.

local script in the tool.

game.Players.LocalPlayer.Character:FindFirstChildOfClass("Humanoid"):UnequipTools()
script:Destroy()
1 Like

huhh

30char

I was testing. this works fine. as long as they can’t drop the tool.