Undo is not restoring an object from instance:Destroy()

Help and Feedback Scripting Support
,
#1

I’m making a Studio plugin where I press a textbutton to destroy an object and use the change history service to set a waypoint, but when I undo this action the objects don’t get re-added to the workspace

The code looks a bit like this (I’ve simplified it to make it more readable):

ChangeHistoryService:SetWaypoint("Remove object")
obj:Destroy()
ChangeHistoryService:SetWaypoint("Remove object")

I’ve also tried using different names for the start and end waypoints, but neither of those make a difference.

The object I’m destroying is a model that contains many nested parts, models and values inside it. When I press undo I get some warning text in the output saying “The parent property of X is locked, current parent:NULL, new parent Y” for what looks like every descendant of that model.

I’m also using the change history service for a few other actions and not seeing any issues, including when I add the very object I’m deleting via another button. If I undo the add action it will remove the object as expected, and then if I redo that undo it will add it back again. So I’m not really sure what’s different here, especially since if I manually delete the object in explorer the undo works fine.

Does anyone know what I’m doing wrong here? Is there an alternative way to destroy the object that I’m missing?

Thanks in advance for your help!

2 Likes
#2

I would post a bug report.

Although, since it’s a plugin, you could probably just parent obj to nil. I don’t think it would be a memory leak, since there aren’t going to be any connections attached to it in build mode. Maybe, though.

1 Like
#3

I’ll post a bug report then, as it looks like I’m doing everything correctly.

Parenting the object to nil actually does fix things… I’ve no idea about the memory leak either, but it seems like calling Destroy shouldn’t behave this way.

Thanks!

1 Like
#4

I just found that called obj:Remove() fixes everything and presumably is a bit cleaner than setting the parent to nil

2 Likes
#5

This is because Destroy() not only sets the parent to nil, but it also locks the parent property, meaning that the parent property can’t be changed. You just have to set the parent to nil, but not call destroy on it.

1 Like
#6

True, but you would think that setting a waypoint would also keep track of things like that.

#7

Waypoints do keep track of changes, that’s what it’s for. The problem is that it literally can’t change it back to the way it was.

1 Like