I have made myself a customer leaderboard GUI, I still want to show people that I am the owner, is there a way to add icons onto a custom GUI leaderboard?
If anyone can provide me with sources or information that can help I would really appreciate it.
You can have a imagelabel that is beside all the icons on the custom leaderboard then have this script inside.
wait(.1)
local plr = game.Players.LocalPlayer
local YourUserId = 000000 -- Paste your userid here.
if plr.UserId == YourUserId then
script.Parent.Visible = true
end
Yea, its possible, there is a property of the player called Membership Type. so you can pretty much have the same thing for each membership(BC, TBC, and OBC) and just replace the if statement with
if plr.MembershipType == Enum.MembershipType.BuildersClub then
script.Parent.Visible = true
end
It is possible, but it aint recommended with the owner, because if you ever change your username, you will have to go in and change it to, where your userid will stay the same if you change your username.
On my custom leaderboard, I had set up an ImageLabel alongside a TextLabel for each player. Setting up the ImageLabel to display the correct image would have been done in a way such as this:
And then when creating the section on the leaderboard for each player, I’d use the following to select an image, for example:
local mType = player.MembershipType
if mType == Enum.MembershipType.BuildersClub then
ImageLabel.Image = Icons.BC_ICON
end
And so on using elseif statements with a combination of GetRankInGroup and game.CreatorId (or other functions that suit your specific needs) for other icons.
StarterGui:SetCore(“PromptSendFriendRequest” or “PromptUnfriend”, otherPlayer) - Has to be called from the client you want to prompt sending a friend request. This can also be used to accept friend requests. PromptBlockPlayer and PromptUnblockPlayer also do exist.
You can use StarterGui:GetCore(“PlayerFriendedEvent” | “PlayerUnfriendedEvent”) to process friending / unfriending. (Equally, PlayerBlockedEvent and PlayerUnblockedEvent exist). Note that these return a BindableEvent rather than an RBXScriptSignal.
This question has already been asked before. As well, I wrote a big guide on that thread once before. Please do make use of your search bar in the future.
Why is the wait(0.1) at the top here? Adding a wait at the top of your script is unnecessary and in some cases, bad practice. Is it in regards to LocalPlayer? LocalPlayer is implicitly available to all LocalScripts.
Mostly of habit, for one it doesn’t hurt anything, and it is because I’ve got to where I do in all of my scripts so I don’t have to worry about one thing loading before another. Either way, its probably isn’t needed, but it doesn’t hurt anything in the long run.
The point isn’t really about whether it “hurts something” or not. There really isn’t a point to doing this. You’d be adding an unnecessary delay where you can get something done instantaneously. You should always aim for your operations taking as little time as possible, or being as minimally computationally expensive as possible. That especially goes for anything regarding the client; you should be as fast and responsive as possible.
If this happens, you’re doing something wrong or reinventing a wheel of some kind. Even if a wait is necessary beforehand, there’s already ways to yield a thread until what you need is in place. Wait is not an appropriate method of “waiting for things to load” (it doesn’t do that in the first place) and the only thing that’s of concern is anything that has to be replicated.
In your specific code example, the wait plus your reason for doing it is relevant only to ensuring that the Gui exists and that LocalPlayer isn’t nil.
Again, LocalPlayer is implicitly available to LocalScripts.
WaitForChild exists if you’re unsure if something has replicated or cloned over. Assuming the LocalScript is a descendant of the LayerCollector by the code written, you’d just need to wait for the element responsible (even though you should put LocalScripts directly under the LayerCollector and not bury them in your object hierarchy, for simplicity’s sake).