I’m tryin to make a script where the model disappears with a destroy function but then reappears. But I can’t find a function that is able t revert a destroy function so I’m not sure if it exist or not.
2 Likes
Instead of using :Destroy(), just set the parent of the object to nil. Then, when you want your object back, just parent it back to Workspace. Remember to keep a variable of the object so you can access it while it’s in nil!
7 Likes
How do you parent an object back to the workspace?
An easier way to be able to access it without variables (this lets you bring it back from the dead on most any script) is to just parent it to serverStorage or lighting. (Keep in mind you’ll only be able to access it in ServerStorage on the server!)
Try something like this:
-- To make it go away
local part = game.Workspace.Part
part.Parent = nil
-- To make it come back
part.Parent = workspace
3 Likes
There’s a massively simple solution.
Here’s a little fact not many people know;
There used to be a function named Remove(), but it was supposedly “replaced” with Destroy(), despite being less useful.
The funny thing is, it’s still activated in all contexts.
I have been on Roblox since 2007, as a result, I’ve had experience with a lot of the now deprecated functions.
So here’s how it works:
In a nutshell, as long as you remember to make a “local name = name” reference to something, you can call name:Remove(), and unlike Destroy(), it doesn’t “lock” the parent as nil, it just replaces it with nil.
Then you might ask, why is it deprecated?
I don’t know. 
Here’s what you do to use it;
local Part = Instance.new(“Part”)
Part.Parent = workspace
(whatever you do with this part goes here)
(when you want to Destroy() it, use Remove() instead)
Part:Remove()
(when you want to bring it out of nil, just parent it again)
example:
Part.Parent = workspace
Boom, there you go.
PS: Remove(), like Destroy() will work on any instance.
Just make sure whatever you want to bring back has a “local name = name” reference as I mentioned earlier, and boom, you’re all set. 
2 Likes
I’d imagine :Remove is deprecated because sometimes when you see Remove you think: Oh this is gonna be gone forever, yet that’s not how it works. Destroy on the other hand is a better name that leaves little room for interpretation.
Also, you should never use deprecated methods no matter what. Things aren’t deprecated in name only, to preserve their existing functionality they won’t be touched again, this means things like performance, compatibility improvements, etc. Won’t be applied
And because you already have to do a parent operation in the first place, for purpose of consistency you can just Parent it to nil without calling a deprecated piece of the API
1 Like
No offense, but I can’t see how your point makes sense, it still functions, what else matters?
Deprecation is only a label, it doesn’t change how well it functions, nor decides if it works or not.
You shouldn’t use deprecated functions anyways whether they work or not. If an engine update breaks them, they will not be fixed, they will be removed. This means some update down the line your script could stop working and you have to go through your scripts to find the issue and it’s a real hassle. They remain deprecated until they break or roblox decides to remove them. The “what else matters?” is future proofing your scripts. Deprecation notices are posted so developers have time to update their scripts without their game breaking (not to disregard the deprecation notice), which is why some deprecated methods still work but they have no intentions for updates or fixes.
it still functions, what else matters?
That’s not how things work. You have to take into account, will this work in the future? Is this an optimal way to do it?
I’ve already knocked out both questions with my reply, that’s where it makes sense
2 Likes
Okay, they’re functions, right?
I’m sure you can see where I’m going with this.
If you use the standard destroy() and it’s been destroyed, it’s gone, forever. there’s no way to bring it back.
1 Like