|
| 23 Jun 2016 10:54 PM |
removes deprecated but that only means its not recommended
title |
|
|
| Report Abuse |
|
|
|
| 23 Jun 2016 10:55 PM |
remove makes it nil destroy does something else
Add 13,000 posts |
|
|
| Report Abuse |
|
|
|
| 23 Jun 2016 10:55 PM |
| Well I only use remove() so I would't really know... wait why is it not recommended? |
|
|
| Report Abuse |
|
|
Borsy
|
  |
| Joined: 31 Jul 2014 |
| Total Posts: 15111 |
|
|
| 23 Jun 2016 10:56 PM |
i think remove doesn't stop sounds, destroy does either way just use :Destroy() unless you love blue underlines
|
|
|
| Report Abuse |
|
|
DevVince
|
  |
| Joined: 08 Nov 2008 |
| Total Posts: 9245 |
|
|
| 23 Jun 2016 10:57 PM |
Remove just parents it to nil so it's recommenced to use object.Parent = nil instead. But with Destroy it Destroys it and you can't get it back.
So with Remove the object still exists, so if you have a gun and all the buttons use remove they will all still exist and over time make the sever lag really bad. |
|
|
| Report Abuse |
|
|
|
| 23 Jun 2016 10:57 PM |
"remove() makes it nil"
doesnt that mean it gets rid of it, it no longer will appear in workspace, and doesnt destroy do the same thing
if i did part:remove() and part:Destroy() they do the exact same thing |
|
|
| Report Abuse |
|
|
eRanged
|
  |
| Joined: 15 Jun 2013 |
| Total Posts: 9746 |
|
|
| 23 Jun 2016 10:57 PM |
| remove makes it nil, Destroy actually destroys the object I believe. I think destroy is better for lagging purposes because it's still apart of the game with remove. |
|
|
| Report Abuse |
|
|
|
| 23 Jun 2016 10:57 PM |
destroy doesn't make it nil, it entirely destroys it
making the parent nil is different
Add 13,000 posts |
|
|
| Report Abuse |
|
|
| |
|
Borsy
|
  |
| Joined: 31 Jul 2014 |
| Total Posts: 15111 |
|
|
| 23 Jun 2016 10:58 PM |
basically using remove will be less efficient and more ram usage
|
|
|
| Report Abuse |
|
|
DevVince
|
  |
| Joined: 08 Nov 2008 |
| Total Posts: 9245 |
|
|
| 23 Jun 2016 10:59 PM |
| Remove just eat up peoples memory so don't use it at all. |
|
|
| Report Abuse |
|
|
|
| 23 Jun 2016 11:53 PM |
Remove() is out dated and was replaced with Destroy().
So don't use remove() it shouldn't even work as it's very inefficient. |
|
|
| Report Abuse |
|
|
|
| 23 Jun 2016 11:55 PM |
| They should just replace the remove code with the Destroy code... remove looks and sounds better... in my opinion, mind you. |
|
|
| Report Abuse |
|
|
Borsy
|
  |
| Joined: 31 Jul 2014 |
| Total Posts: 15111 |
|
|
| 23 Jun 2016 11:57 PM |
@twisted it'd break scripts some scripts still use remove() in case it needs to get it back
|
|
|
| Report Abuse |
|
|
| |
|
jmt99
|
  |
| Joined: 27 Jul 2008 |
| Total Posts: 4799 |
|
|
| 24 Jun 2016 12:06 AM |
@DevVince
Actually, you can still get the instance back with :Destroy()
You simply just need to have a reference to the instance before it was destroyed, and then call :Clone() on it, and then you can parent it back to the Workspace or whatever.
|
|
|
| Report Abuse |
|
|
pketny
|
  |
| Joined: 27 Dec 2010 |
| Total Posts: 1162 |
|
|
| 24 Jun 2016 08:34 AM |
@jmt99 Calling :Clone() will clone the object. You will not actually get the exact same object back.
But what you are saying is true, and kind of weird. Because this means that as long as there is still a reference to the object, the object still exists somewhere after it has been destroyed.
Which I find lacking.
There should be a function that can actually destroy an object. |
|
|
| Report Abuse |
|
|
|
| 24 Jun 2016 09:02 AM |
| I wonder if this object existance affects game performance. If so, we need an actual thing that really destroys the object. |
|
|
| Report Abuse |
|
|
pketny
|
  |
| Joined: 27 Dec 2010 |
| Total Posts: 1162 |
|
|
| 24 Jun 2016 09:07 AM |
@Iliuminatis
That's exactly what I am talking about.
We want to optimize our scripts, but as you can see, ROBLOX doesn't let us because they do not have a proper destroy function. |
|
|
| Report Abuse |
|
|
|
| 24 Jun 2016 09:08 AM |
Obviously it would affect performance, but probably not much unless you're deleting tons of stuff. And the references are removed eventually, especially if you use local variables, so you shouldn't worry about it. |
|
|
| Report Abuse |
|
|
pketny
|
  |
| Joined: 27 Dec 2010 |
| Total Posts: 1162 |
|
|
| 24 Jun 2016 09:12 AM |
The references are eventually removed indeed, but still:
local baseplate = workspace.Baseplate
baseplate:Destroy()
wait(1)
print(baseplate)
baseplate:Clone().Parent = workspace
This works, and it looks sketchy af. |
|
|
| Report Abuse |
|
|
|
| 24 Jun 2016 09:15 AM |
I think what is happening (Take note that I don't know much about this low-level stuff) is that the memory is freed and available for use, but it doesn't get removed immediately, it is only removed when it is overwritten, which will take place when something needs the space. Otherwise, Roblox would be one big memory leak. |
|
|
| Report Abuse |
|
|
pketny
|
  |
| Joined: 27 Dec 2010 |
| Total Posts: 1162 |
|
|
| 24 Jun 2016 09:19 AM |
I think it's the last case,
Memory doesn't work like that 'is freed and available for use, but it doesn't get removed immediately, it is only removed when it is overwritten,'
I'm pretty sure. |
|
|
| Report Abuse |
|
|
|
| 24 Jun 2016 09:19 AM |
| IIRC, that's the case with hard drives too. That's why just "Deleting stuff" doesn't prevent info and files from being stolen. It only frees the space, it won't erase it. |
|
|
| Report Abuse |
|
|
|
| 24 Jun 2016 09:20 AM |
| I suppose if you really wanted to know, this is right up Flux_Capacitor's alley. |
|
|
| Report Abuse |
|
|