Remove the "unexpectedly tried to set the parent" restriction

Feature Requests Engine Features
#1

Currently if you try to set something’s parent inside of a childadded event you get spammed with

Something unexpectedly tried to set the parent of DestroyBuilding to NULL while trying to set the parent of DestroyBuilding. Current parent is Building1.

This is dumb. There’s no reason this should be restricted. All it does it spam my output and make it more difficult to do what I want.

4 Likes
#2

I’ve run into this on numerous occasions. To get around it, I use game.Debris:AddItem(item, 0). I know it doesn’t wait 0 seconds, but 0 is easier than typing 1/30. I suppose you could use Delay or a simple wait, but I find that AddItem looks more appealing to the eye. However, you’re correct – this shouldn’t even have to be an issue.

#3

Isn’t this similar to synchronous issues? Trying to manipulate the same thing before it was done being manipulated the time before. However, it hapening within a ChildAdded listener would lead me to think the operation was already complete…so I don’t know. I agree with you.

#4

I thought they said they were removing this a while back? Except, that never happened.

#5

Maybe because if ChildAdded fires, you expect that his parent is the one whose event you’re listening to.
(And if a later connected event already destroyed it… weird)

Just doing wait() and then destroying it works fine

#6

The thread that’s setting the Parent of an object should have authority over the Parent as long as it’s being set. Why should this not be so?

#7

I’m going to assume that the things some devs are doing don’t intentional break the rule, it just happens. Since the warning never causes any serious problems, why have it spam the output?

#8

This is how I understand the problem with this:

Say you have 3 functions listening to a Parent change:

A, B, C

When something sets the parent, it calls the listeners, like this:

A(newParent)
B(newParent)
C(newParent)

If function B sets Parent before C runs, what should function C do?

#9

[quote] This is how I understand the problem with this:

Say you have 3 functions listening to a Parent change:

A, B, C

When something sets the parent, it calls the listeners, like this:

A(newParent)
B(newParent)
C(newParent)

If function B sets Parent before C runs, what should function C do? [/quote]

C shall set the parent after B runs. That’s the beauty of single-threading: functions are like macros. However, ROBLOX is multithreaded and two threads may be trying to set the parent at the same time. This introduces a race condition, and to solve it, ROBLOX usually throws an error on Lua threads, and lets any C-calls through.

#10

The Parent property isn’t a YieldProperty or anything. Why can it even be conceived that a parent can be set WHILE a parent is being set?

And this issue was actually introduced as a feature for some unknown and probably obscure reason. Why would you make an error a feature when it never used to be an error?

#11

It’s way better that way it is right now. It causes a lot of issues when you can have concurrent modification of the parent property. Rest assured, there is good reason to have the warning on the C side: It makes things much easier on the engine code if the case is disallowed.

More importantly, the use cases are dubious: When you’re doing something that triggers this problem you should really step back and ask yourself whether what you’re doing is really correct. Any time that you’re running into this case you’re probably trying to have one part of your code “fight with” another part of it over what should be happening, which should probably be resolved via refactoring your code rather than forcing things through. Pretty much the only legitimate use case for allowing concurrent parent modification is to “fight with” core engine actions, like avatar parts being added to your character, or a hat being moved from the character into the workspace. A far better solution to that problem would be to expose API allowing you to elegantly fix those engine behaviors that you don’t want rather than allowing error prone concurrent parent modification.

1 Like