So I’m not sure if you’re getting the glitch that sometimes I have to deal with but for me, sometimes the CharacterAdded function doesn’t seem to want to play when someone first joins the game, you could just make a quick thing to run it a second time just in case it doesn’t show.
Here’s a script that I think might help
local TweenService = game:GetService("TweenService")
local MarketPlaceService = game:GetService("MarketplaceService")
local gamePassId = 10847450
local gamepassid2 = 11286393
local groupId = 7496720
local function CreateTag(Player)
Player.Character:WaitForChild("Head")
if Player.Character.Head:FindFirstChild("Overhead") == nil then
local clone = script.Overhead:Clone()
clone.Parent = Player.Character.Head
local nameLabel = clone.nameLabel
wait(1)
local prz = TweenService:Create(nameLabel, TweenInfo.new(1,Enum.EasingStyle.Quint,Enum.EasingDirection.Out,0,false,0), {Position = UDim2.new(0,0,0,0)})
prz:Play()
nameLabel.Text = Player.Name
if MarketPlaceService:UserOwnsGamePassAsync(Player.UserId, gamePassId) then
while true do
local Color = Color3.new(math.random(), math.random(), math.random())
InformationLabel.TextStrokeTransparency = 0
local ColorTween = TweenService:Create(InformationLabel, TweenInfo.new(3), {TextStrokeColor3 = Color})
ColorTween:Play()
wait(2)
end
end
end
end
game.Players.PlayerAdded:Connect(function(Player)
Player.CharacterAdded:Connect(function(char)
CreateTag(Player)
end)
game.Workspace:WaitForChild(Player.Name)
CreateTag(Player)
end)
You aren’t setting the BillboardGui’s Adornee. You should always explicitly set it if you’re looking for a surefire method of having the BillboardGui render over the specified part. Developers should not be relying on the behaviour of BillboardGuis rendering on player heads by only parenting them.
Do you have the feature that changes heads to MeshParts enabled? Another workaround for this can be to use the HumanoidRootPart as your adornee instead since that’s the only part in a rig that’s guaranteed not to change. As for this current code though I would opt for WaitForChild, don’t think the character is guaranteed to be 100% built when CharacterAdded fires as of right now meaning the Head could be missing when you try to index it.
It’s fine if you aren’t using it. I wagered that the engine rebuilt the Head if that feature was enabled much like how it rebuilds the rig to apply bundles. In any case, I would just try and go for a head Adornee.
local RankUI = script.OverheadGui:Clone()
RankUI.Adornee = Character:WaitForChild("Head")
RankUI.Parent = Character
Your console ever error when the Adornee doesn’t read anything?
Commit to debugging then, can’t just copy paste my code. I left an additional note asking if you ever saw any errors in the console with your original code.
Just for reference, I created my own nametag script in a couple of seconds and it’s giving me the exact results I’m expecting. That is, it adorns above my head and adornee isn’t nil.
local Players = game:GetService("Players")
local ServerStorage = game:GetService("ServerStorage")
local function playerAdded(player)
local function characterAdded(character)
local new = ServerStorage.BillboardGui:Clone()
new.Adornee = character:WaitForChild("Head")
new.Parent = character
end
player.CharacterAdded:Connect(characterAdded)
if player.Character then
characterAdded(player.Character)
end
end
Players.PlayerAdded:Connect(playerAdded)
for _, player in ipairs(Players:GetPlayers()) do
playerAdded(player)
end
Frankly sounds like a case of poor code architecture, though your code looks fine as it is (minus the lack of initial state setting) and yet has a problem that shouldn’t be. I advise you to check your console or do some debugging when you run into similar such issues.
Nope, just seems like a case of bad code architecture, the mesh of a Head would not affect the rendering of a BillboardGui. I put that same head on and it renders as intended.
local players = game:GetService("Players")
local me = players.colbert2677
local desc = players:GetHumanoidDescriptionFromUserId(players:GetUserIdFromNameAsync("ch0c0lAte98"))
me:LoadCharacterWithHumanoidDescription(desc)
I had this same issue, where the Name GUI would not appear over the person’s head if they had a custom head, like the Woman Head for instance. If anyone has a similar issue, I fixed this by using the CharacterAppearanceLoaded method instead of the CharacterAdded method.
I used to have this issue.
Instead of getting the character like this: player.Character or player.CharacterAdded:Connect(function(character)
Try getting the character from workspace like this: game.Workspace[player.Name]
That’s horrible advice. This runs the risk of indexing the wrong instance if a player is named the same as an instance in the current session and can introduce a number of unexpected errors. Never get the player by searching them with a name in the Workspace. You already get a reference to the character instance through the player’s Character property or passed as an argument to CharacterAdded.
I remember having the same problem and I fixed it like this:
function CharacterAdded(Character)
task.wait(1)
--Insert the code that puts the GUI in the head here
end
game.Players.PlayerAdded:Connect(function(Player)
Player.CharacterAdded:Connect(CharacterAdded)
if Player.Character then CharacterAdded(Player.Character) end
end
This is an old topic but I have a few things to add:
First thing, don’t know why but I ran into this issue as well. Did what you said to do and debugged turns out for whatever reason, the first head that is added to the character is destroyed, then a second head is added then the first head is disposed of which caused my billboard guis to be adorned to a destroyed instance:
^ first print is the overhead’s parent (irrelevant), second is inside of the childadded connection later in the post, third is the old head’s class name but again not relevant.
We have a custom respawn handler so CharacterAutoLoads is false but unsure as to whether or not this is a contributor to the issue. However disabling workspace.MeshPartHeadsAndAccessories actually seems to cause it not to happen so don’t really know. Tried printing the first head’s class name and it’s still a mesh , so two mesh parts are still made for whatever reason but the first one is discarded.
Anyway, my fix to this was to implement the following (the character is actually being destroyed by custom respawn handler so it isn’t a memory leak, so if you’re implementing this solution ensure you disconnect your connections when a new char is added), to re-adorn the overhead to the new head (sorry for indenting, copied and pasted it here) which caused the issue to subside.
character.ChildAdded:Connect(function(child)
if child.Name == 'Head' then
newOverhead.Adornee = child
end
end)
But on a sidenote doing this for whatever reason causes the overhead to update super weirdly and sporadically so I don’t know but it seems either I’m doing something wrong, or billboards don’t like mesh parts so I’ll be disabling the mesh part heads and accessories:
For reference this is how it looks when adorned to the head with meshpart heads and accessories disabled:
Difference probably isn’t super noticeable given how low quality gyazo records gifs but I think there is still is a difference. Anyway, I’m going off-topic and I don’t know how to conclude things so I’ll end it here
