Hello fellow Devforum users. I’ll be Straight and Foward with this as possible, I come here today to find out if there is a simpler way of getting the Previous Parent of a child that’s being moved to a new parent.
The Child is a tool, I’m wanting to check if the Previous Parent of that tool is the Character / When the person is actively using it.
I have thought about using Attributes to check if the Attribute’s Value is the “Previous Parent”, But I would just like to know if anyone has a simpler way of doing this, I feel like I’m overthinking it.
local function ItemAdded(Child)
if Child:GetAttribute("PreviousParent") == Workspace[Player.Name] then
-- If the Previous Parent of the tool is the Player's Character --
end
end
I’m going to be using :ChildAdded() for the function, therefore this would not work. I’m not doing it for every item, I’m doing it for every item added to the backpack.
No, I’m not checking for a specific item. I have a hotbar system, and would like to check if when it was added to the backpack / when they put it back in the hotbar. Therefore I’m saying that the item could be anything…
You can use the ChildRemoved event/signal of an instance to detect when one of its children’s ‘Parent’ property changes.
local function OnChildRemoved(Child)
print(Child.Name) --RandomName
end
local Model = Instance.new("Model")
Model.ChildRemoved:Connect(OnChildRemoved)
local Part = Instance.new("Part")
Part.Name = "RandomName"
Part.Parent = Model
Part.Parent = nil --Fires model's 'ChildRemoved' event/signal.
IIRC currently attributes don’t support instances.
Why not just store the previous parent in a local variable?
local previousParent = instance.Parent
local ancestryChangedConnection = instance.AncestryChanged:Connect(child, newParent)
-- Stuff
previousParent = newParent
end)
-- Perhaps when the tool is unequipped
ancestryChangedConnection:Disconnect()
This also sounds pretty much just like what the Tool.Unequipped event would do for you. Doesn’t that tell you when the previous parent was a character, and thus, you could pretty easily know what that character was using a local variable of some sort? You can just have some kind of variable for the current character using the tool which you might update on Tool.Equipped. When the tool is unequipped, you can update that variable to nil but only after you’ve finished.
You can create an attribute and refer to it 6 years later after you copied it to a different program…
What do you mean “currently attributes don’t support instances.”
Down on the bottom of an object is add attribute. You can make it anything you want and use it as data. In this case what was this objects last bar parent. This would work perfectly.
I mean exactly what I said, I don’t see what’s confusing about that. Attributes don’t currently allow instances to be assigned to them, they simply throw an error that the value type isn’t allowed. This was originally possible before attributes were released, but after the release of attributes, many value types (including instances) that they could store and supported were removed so that Roblox can update the properties widget to be able to display said values properly (which, imo, makes no sense, it should really have been the other way around, especially because instances can definitely be displayed in the properties widget).
Also, the same is true for local variables. Nothing stops a local variable from being used six years later, unless your problem has to do with a script ceasing to run, but, I really don’t see how that makes a difference. What problem are you actually facing here that would even require that to be the case? If the tool is :Destroy()ed, wouldn’t you want that?
Even if the tool is parented to nil, its script won’t stop running. The time your script stops running and the time the tool is no longer a thing should really be exactly the same in this case.
Just because something has one benefit in specific cases also definitely doesn’t mean it’s the objectively best solution in every single case, and, I’m a little bit confused on why you actually want to use an attribute at all here when it could be solved pretty easily, there’s no situation I can really think of where it could/would ever matter whether or not that value will persist, especially because the instance it references almost definitely won’t.
Like I said, I’m not really understanding the problem, why doesn’t the solution I suggested work?
“Like I said, I’m not really understanding the problem”
Now you got me lost too… I take it he is taking an icon off a bar he made and the item is being put in his backpack. When the item is pulled out of the backpack he wants it to go back to the bar where it was.
If that is the case an added attribute string of the parent on the item should be an easy way to get that information back when you want to put it back on the bar. Even if you drop the object it will still have that attribute string and can still be put back on the bar the same way.
I think I over complicated this… my bad. Yes as far as reading an attribute that looks fine to me.
To be honest I don’t need to have the Instance in a value, I just need the name because I know where it came from previously, it came from the Character in the workspace.
It’s not the backpack to hotbar, It’s just so the hotbar doesn’t duplicate the item when it gets added back to the backpack folder in the player, I don’t have a backpack system as of yet. And if it’s previous parent was not the character than It would be added to the hotbar meaning that it’s a new item.