local origin = game.Workspace.Base["Server Reset"]
local reset = origin:Clone()
while true do
wait(10)
reset.Parent = game.Workspace.Base
reset.Name = "Scheduled Reset"
reset.Yeetandelete.Disabled = false
end
I think Yeetanddelete deletes the model, and because he doesn’t clone it again and uses the same variable it doesn’t exist and is parented to nil so it can’t be moved to a new parent
That doesn’t matter here. The parent is a model, not a part or anything else of the sort. You cannot lock a model in studio. and even if you could, its not showing up as locked as I already tested that theory by using the unlock tool via the home ribbon
put the local reset = game.Workspace.Base["Server Reset"]:Clone()
inside of the loop because if i’m not wrong does Yeetanddelete destroys it?
which makes roblox put the model inside of nil and locks it, which is why you’re getting the error
I understand that, I should’ve clarified earlier however; the Yeetandelete instance you’re seeing in my code is actually a script that is disabled by default. The way the code is structured in the cloning script should not be able to disable it before actually cloning the instance correctly.
edit: if you’re still confused, here is the code and the status of the script of the “server reset” from studio:
The code you posted on this thread and the code in the screenshot are different. What’s real?
This error typically only shows up if you are attempting to set the parent of a destroyed object. If you were running into a race condition, then it would be a warning stating that something else unexpectedly tried to set the parent and that said request was dropped.
Of course they are different. If you look closely, you can see that I have posted both codes involving the cloning sequence script from the workspace (from my original post) and the server reset script on the next screenshot (in my reply to QuantixDev). Also I have never heard of a race condition before. What exactly is that?
the Yeetanddelete script literally deletes the model on the last line.
In the loop where you clone the model, you keep the same variable which links to the first cloned model which was deleted by the script, that means you have a reference to an object in nil.
You need to update the origin variable to be a reference to a newer clone so that it’s not referenced to a ‘destroyed’ object
The thing I was trying to explain beforehand was the circumstance that my script was Disabled by default, thus I assumed that the destroy function should’ve not been possible (until the script was reenabled); this seems to not be the case. I have no idea why this is a thing but I appreciate your helpful feedback. I will keep this in mind for future code (despite it being very odd)
local origin = game.Workspace.Base["Server Reset"] -- Main reference to the model
while true do
wait(10)
origin = origin:Clone() -- New clone reference
origin.Parent = game.Workspace.Base
origin.Name = "Scheduled Reset"
origin.Yeetandelete.Disabled = false
end
Yes I fixed the problem, but it made me run into another one on the spot; now the script that is cloned (the scheduled reset model script) will not function at all. It clones correctly now, it’s just that the script will not work for some reason.
Here’s the new code I implemented for the Yeetandelete code for the server reset mode script:
game:GetService("ReplicatedStorage"):WaitForChild("SpecialCases")
local reset = game:GetService("ReplicatedStorage").SpecialCases["Server Reset"]:Clone()
while true do
wait(10)
reset.Parent = workspace.Base
reset.Name = "Scheduled Reset"
wait(10)
reset:Destroy()
end
It’s enabled by default now and it has not worked. I even tried the other way around; disabling it by default and having the cloner reenable the clone. I thought it was a local script for a few seconds and quickly realized having a local script in this fashion is not necessary if the cloner script is parented via workspace
edit: There are 0 errors whatsoever either that come up
I just fixed it. Apparently I forgot to realize that the yeet and delete script was checking if its parented model was inside the ItemHolder folder, not the Base model which was where I was continuining to make it relocate to whenever it got cloned via the cloner script. Thank you for your help!