I haven’t looked at this post since yesterday. Respectfully, I’m implying from the messages above that the idea you gave Tool.Unequipped & Tool.Equipped is just not what I’m going for. And I didn’t explain what my system was and what I was actually going for, I didn’t want to go and over detail my post.
1 Like
(Would also not work for what I’m going for) ^
To clarify, When I was talking about the “Backpack” I meant the Player’s backpack game.Players[Player].Backpack. If anyone has an idea of a simpler way dm me, or reply to the post.
Why? A tool can only come from one of three places (picked up by character from workspace, equipped by character from backpack or manually parented to character by script).
1 Like
It doesn’t hurt to go into detail about what specifically you’re trying to do, even if you include it as a separate section or something. That helps to understand what other ways might exist to do what you want. In this case, what you seem to want to do actually entirely changes my perspective.
Since your goal sounds like you want to avoid duplicating UI elements (in your hotbar) for already added tools, you could insert a value into a table with the tool as the key. It could be simply true, it could be the UI element itself, or it could be a table of data, perhaps containing things like the current player who has the tool, as well as the UI element. In other words, a hashmap of a player’s tools to some helpful stuff for cleaning up/keeping track of hotbar stuff.
This means that, regardless of name, and regardless of where the tool goes, when it’s added, you will always be representing only ever that the tool is/isn’t in the hotbar (by either being in the hashmap or not), and you will never be able to accidentally remove or add it multiple times.
In order to know when to create your hotbar elements, you can connect to the tool’s AncestryChanged event, and if the tool isn’t in the player’s backpack or in the player’s character (which you should have access to both from your hotbar code) then the tool must be either dropped or not held. This also provides you a clean way to tell when a tool is/isn’t equipped, since, you’re able to check if the tool is within the player’s character or not during AncestryChanged, and update your UI elements to indicate that the tool is equipped.
If the tool is already in your hashmap, it’s already part of the hotbar, so, you can insert a guard clause for that. When the tool is removed from both the backpack and character, you can remove it from your hashmap (thus freeing it up to be re-added) and disconnect the associated AncestryChanged event so you stop tracking the tool.
This also allows you to handle tools directly added to the player’s character, since, tools added to the backpack will be unequipped tools, but tools added directly to the character (e.g. by being picked up) will be equipped already, so you’d still want your hotbar to add a UI element then even if the tool doesn’t exist. With the ancestry tracking that you’re trying to do, that wouldn’t happen, but, in the default Roblox UI, it does.
I think that should cleanly cover everything you’re looking for, and it should be a lot more straightforward than I make it sound (cough I wrote four whole paragraphs about it for some reason).
2 Likes