Disappearing Ghost Backpack

When joining a game in the Play mode, a backpack already exists for the Player, despite no character existing. The Backpack is almost immediately destroyed (presumably as a sequence of an internal LoadCharacter call) and replaced by a new one, before a new Character is added.

One would expect a Backpack to not be removed in the first place. If I were to do

local Backpack = game.Players.PlayerAdded:Wait():WaitForChild("Backpack")

I would get a Backpack that would be parented to nil within a few milliseconds.
This bug occurs consistently and predictably.

Example:

local Players = game:GetService("Players")
local function distributeTools(Player)
	Player.CharacterAdded:Connect(function(char)
		print(char)
	end)
	Player.ChildAdded:Connect(function(c)
		print(c.Name.." added")
	end)
	Player.ChildRemoved:Connect(function(c)
		print(c.Name.." removed")
	end)
end
Players.PlayerAdded:Connect(distributeTools)

Order of output:

Backpack removed --Why on earth did this exist in the first place?
Backpack added
WoolHat

I code between large hiatuses, so unfortunately I cannot list a specific date. The Backpack is most likely destroyed, because its parent property becomes locked.

6 Likes

Just a thought but do you have anything in the StarterPack?

Nope. The code I posted reveals the “bug” even in a fresh studio environment.
I say “bug” in quotes because this is my first bug report and I am insecure about it.

Four years later, this stupid bug is still out there, doesn’t fit into any game development logic, and the problem hasn’t been officially noticed.
If you want players to join the game, inserting certain tools into the player’s backpack through a script can be very frustrating for developers(Because the tool inserts the Ghost Backpack by default, and then it is removed instantaneously). I can now only track Backpack by tracking Player.ChildAdded, which makes my code look ugly and inelegant.

3 Likes

Can the roblox staff help me explain what the empty backpack does?

Yes, we could also put all the tools in the Starterpack and write a script to determine if the player has a certain stringvalue tag and remove the tool if it doesn’t. This also avoids the weird Ghost Backpack. But I still think this logic is a compromise.

I’m pretty sure I just came across this exact same issue while trying to load items for a custom inventory system I made for a YouTube tutorial. In my loading items function, my code runs

player:WaitForChild("Backpack")

to wait for the backpack to appear, in case it’s not there at first. But occasionally (not every single time, but more often than not), at some point between that :WaitForChild() and when the code starts cloning items into the player’s backpack, player.Backpack becomes nil for some reason, causing all my items to be set with a nil parent. With some additional testing, it appears that the backpack’s .Parent property is also set to nil right before all this happens

image

(There’s a double print, but it only changes once)

Anyway, I’m pretty sure this confirms what WoolHat was saying because the only explanation so far that makes sense is that the backpack is appearing, getting destroyed, and then appearing again, but the tools try loading in during that small timeframe where the backpack doesn’t exist, causing me hours of confusion until I found this post. It definitely seems like something that might be a Studio bug, but I’m not entirely sure.

Edit: With more testing I realized it was because of a typo I had on one line that waits for the character to load in the first time before trying to load the items. The destroying and re-creating the backpack happens before the character loads in, so properly waiting for the character to load in first as well as the backpack, like so:

if not player.Character then player.CharacterAdded:Wait() end
player:WaitForChild("Backpack") -- not sure if this line is required, but my code has it and it seems to work consistently now

Seems to fix it and make it work just fine.

^ just for anyone else who stumbles across this issue in their own games