Order of events?

[Dev_Peashie]

When using Humanoid:AddAccessory(A_Hair) and the Head of the player is smaller/bigger than the normal, the Accessory change its size. My doubt is, which event fires first, the change of size of the Handle or the Parent of the Accessory?

Seems that Parent is always the last event to fire, is this always consistent? Is there a risk that the Parent event could fire BEFORE the Size event?

This is a example script just to test what I want to know:

local Accss = game.ServerStorage:WaitForChild("Accs")

game.Players.PlayerAdded:Connect(function(ply)
	local CHAR = ply.Character or ply.CharacterAdded:Wait()
	local HUM = CHAR:WaitForChild("Humanoid")
	repeat task.wait() until ply:HasAppearanceLoaded()
	task.wait(3)
	
	while true do
		local newAccss = Accss:Clone()
		newAccss.Handle:GetPropertyChangedSignal("Size"):Connect(function()
			print("size done")
		end)
		newAccss:GetPropertyChangedSignal("Parent"):Connect(function()
			warn("parent done") -- CAN I TRUST THIS WILL BE THE LAST EVENT TO FIRE ALWAYS?
		end)

		HUM:AddAccessory(newAccss)	
		task.wait(2)
	end
end)

Thank you for your time, any reply will be appreciated!

[bytenand]

I believe the Parent property will be the last affected property of the accessory. I experimented with a script similar to yours, and every single time a new accessory was cloned, it always printed:

size done
parent done

in that exact order.

Here’s the code I used:

-- services
local players = game:GetService("Players")
local serverStorage = game:GetService("ServerStorage")

-- variables
local accessory = serverStorage:WaitForChild("Accessory")

-- functions
local function playerAdded(player: Player)
	local function characterAdded(character: Model)
		local humanoid = character:WaitForChild("Humanoid")
		
		if (not player:HasAppearanceLoaded()) then
			player.CharacterAppearanceLoaded:Wait()
		end
		
		while (true) do
			local newAccessory = accessory:Clone()
			
			newAccessory.Handle:GetPropertyChangedSignal("Size"):Connect(
				function ()
					print("size done")
				end
			)
			
			newAccessory:GetPropertyChangedSignal("Parent"):Connect(
				function ()
					warn("parent done") -- Yes I can trust that the parent property will be affected last.
				end
			)
			
			humanoid:AddAccessory(newAccessory)
			
			task.wait(0.25)
		end
	end
	
	player.CharacterAdded:Connect(characterAdded)
	
	if (player.Character) then
		characterAdded(player.Character)
	end
end

players.PlayerAdded:Connect(playerAdded)

for index, player in ipairs(players:GetPlayers()) do
	playerAdded(player)
end

If this isn’t the answer you’re looking for, then I probably misread.

Any who, I wish you luck with what you’re doing

[Dev_Peashie]

Yes, I’ve been testing it too with this script:

local Accss = game.ServerStorage:WaitForChild("Accs")

game.Players.PlayerAdded:Connect(function(ply)
	local CHAR = ply.Character or ply.CharacterAdded:Wait()
	local HUM = CHAR:WaitForChild("Humanoid")
	
	repeat task.wait() until ply:HasAppearanceLoaded()
	
	task.wait(3)
	
	local BenchM = {}
	
	for c=1, 50 do
		local first = false
		local second = false
		
		local newAccss = Accss:Clone()
		newAccss.Handle:GetPropertyChangedSignal("Size"):Connect(function()
			if first then
				second = "Size"
			else
				first = "Size"
			end
		end)
		newAccss:GetPropertyChangedSignal("Parent"):Connect(function()
			if first then
				second = "Parent"
			else
				first = "Parent"
			end
		end)

		HUM:AddAccessory(newAccss)
		repeat task.wait() until first and second
		table.insert(BenchM, {First = first, Second = second})
		task.wait()
	end

	local constant = false
	
	for _, mark in ipairs(BenchM) do
		if not constant then
			warn("the first place on first try", mark["First"])
			constant = mark["First"]
		end
		if mark["First"] ~= constant then
			warn("its not constant", mark["First"])
		else
			print("cool", mark["First"])
		end
	end
end)

Printing a table to measure if any inconsistency occurs, and seems its not. I’m just a little worried if there is not any scenario in which maybe a real server or server struggling with tasks could fire the parent before the size, with this script due to not enough wait time server is struggling but, still Parent is always the last event to fire, still, Im wondering if could be any weird scenario where it doesnt

[bytenand]

I believe that the parent would be last to fire regardless of how inconvenienced the server is with networking and computations.

I believe that the properties sort of fall into a stack; once a call is made to change a property it falls into that stack and will be executed on the next (physics) simulation.

I assume that the :AddAccessory method calls for the size property to be changed first, and then the parent. And because the size property is filled into the stack first, it’ll be the first to run. And the parent property will be ran afterwards. If that makes sense. It’s a very vague explanation, so apologies for that.

Of course in that stack, there are more properties which are changed; and even in separate instances such as welds. But I strongly assume that the parent property will always be the last to run.

Additionally, if you’re still concerned, you could try forcefully lagging the server via unanchored parts.

[Dev_Peashie]

Thank you so much for your help and testing it on your side too.
I assume exactly the same about that stack.
Mainly because a common good practice is to change all properties of parts before parenting them, so its like common sense that the default behavior of roblox engine would do that too, in order to avoid extra physics calculations that are not needed.
I feel more confy on relying that Parent will always be the last one to happen, thank you for your help!