Skip to content

Use of Non-Roblox Tool Instances#132

Closed
MrModification wants to merge 2 commits intoryanlua:mainfrom
MrModification:main
Closed

Use of Non-Roblox Tool Instances#132
MrModification wants to merge 2 commits intoryanlua:mainfrom
MrModification:main

Conversation

@MrModification
Copy link

Uses :GetAttribute("")
Beneficial for developers wanting to use a system other than Roblox's default Tool

To create a new Custom Tool you need
An instance, with the following Attributes:

  • Tool --Any however if its Bool ensure that its true and not false
  • DisplayName --String
  • Icon --String
  • ToolTip --String
  • CanBeDropped --Bool

This allows for a tool to be very raw and scriptable instead of stripping a default tool down

Signed-off-by: MrModification <davgardner24@gmail.com>
Signed-off-by: MrModification <davgardner24@gmail.com>
@ryanlua
Copy link
Owner

ryanlua commented Feb 20, 2026

Thanks for the PR. While I do appreciate the effort put into this, it's out of scope for Satchel. I'll be closing because I haven't heard a need to add custom tools that would justify updating the documentation or maintaining this feature.

@ryanlua ryanlua closed this Feb 20, 2026
@MrModification
Copy link
Author

The benefit may be niche, i made the modifications to better support the flow of a game I'm working on. And thought maybe a few others would benefit too.

Roblox tools have Tool.Activated, Tool.Equipped and others which are okay for basic systems. However, for modular/unified tool systems hacky solutions are required. CustomTool instances: likely the Model with attributes or just a Value with attributes, have no default Roblox implementations. That means, no user input, no animation, no replication, no state. It's very raw but very extensible. Custom: animations, config, input mapping, validation, ui hooks, state machine all without Roblox forcing unwanted behavior/interference. This approach allows custom tool systems to use Satchel and it's clean ui, instead of making a custom inventory system or fighting hacky solutions.

Satchel is very clean and only a few modifications were made to support custom tools:


New Functions:

  • UnequipCustomTools() --Gets all Children of character with "Tool" Attribute and parents them to backpack (Should only have one, exception is for newly added tool as Roblox no longer handles that)
  • EquipCustomTools() --Parents tool to character

Modified Functions:

  • UnequipAllTools() --Added UnequipCustomTools() below Humanoid:UnequipTools()
  • EquipNewTool() --Added logic gate for "Tool" Attribute
  • MakeSlot() --Changed hardcoded tool.TextureId and tool.ToolTip to allow attributes, these work with roblox default tools as well
  • OnChildAdded() --Added check for "Tool" Attribute and logic gate for unequipping old custom tools
  • OnChildRemoved() --Added check for "Tool" Attribute and logic gate for CanBeDropped (This is a bug fix because roblox likes parenting non tool instance to nil)
  • do -- Hotkey stuff --Added check for "Tool" Attribute and logic gate for CanBeDropped

New Connections:

  • ToolAttributeConn --Checks for tool Attribute changes

In my opinion, it's still a very maintainable system because the core of Satchel wasn't altered it functions only as a bypass of "If statements" and allows for Attributes. I Believe this will make satchel even more favorable for advanced systems/scripters. I thank you for satchel and i will continue to use it in other projects of mine. I appreciate your time and hope you’ll reconsider supporting this feature.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants