Developers Should Have Access to the PlayerList

[Azutreo (Azu)]

Note: I don’t know the exact category to put this due to the fact that this relates to both Studio and the Client. I chose studio because that’s where you would edit it.
^^Changed to Client**

Although it is really easy to create our own playerlists and such, As a Roblox developer, it is currently impossible to make an exact clone of the Roblox default playerlist.

With recent updates, Roblox has been allowing customization to the chat, certain UIs, and more core code that couldn’t be altered before. But, what I am requesting is a way, much like the chat, to be able to access the playerlist and edit it.

Most may be wondering why not just make my own? Well, there are a few reasons.

1. I personally try to keep as core-rooted as possible in terms of Roblox UI, which is why I love the chat update so much. If I made my own, I would personally prefer to make a clone of the PlayerList
2. Even with a clone like I have in which I can edit anything about the gui, I feel it seems restricted for the users. One feature I love is the ability to right-click and send someone a friend request or follow them. Using a custom playerlist, the only way to follow someone is to go to their Roblox Profile.
   Note: I also want to suggest adding a way to follow people using the Escape menu
3. If we have the ability to edit the PlayerList, we could just use that as a base and extend off of that, changing the sizes, fonts, etc. to make it seem more custom whilst still not making our own from scratch.

If I stand alone here, then alright. I would still appreciate a look into it. If it’s not possible or not requested enough, then I suggest we at least add a system to the Escape menu to follow a player like mentioned in my not up there.

[buildthomas]

Note: I don’t know the exact category to put this due to the fact that this relates to both Studio and the Client. I chose studio because that’s where you would edit it.

If you are suggesting something that has an effect both in Studio and in-game, this should go in Client Features (changes to the engine/API should go in there).

As a Roblox developer, it is currently impossible to make an exact clone of the Roblox default playerlist.

Most CoreGui items like this are implemented in Lua, and they are open source. See here:
https://github.com/Roblox/Core-Scripts

For the Player List specifically, see this script:
https://github.com/Roblox/Core-Scripts/blob/master/CoreScriptsRoot/Modules/PlayerlistModule.lua

Take it and edit it to your liking.

[Azutreo (Azu)]

I’ve tried that. Editting it and adding it to my own game removes the core features of it like the following ability I mentioned above, which i really want to keep.

[As8D]

Another impossibility by using a custom copy of the Player List, is that leaderstats won’t be able to show in the topbar, because the real Player List is hidden.

Redoing the Player List probably isn’t on the roadmap, but it can considerably make the 6-7 modules used and several thousands of lines of code much shorter - without considering possible platform-specific layouts, I did a custom Player List in just a 200 or so lines of code, added the ability for custom roles and context menu buttons, whereas the corescript Player List is more than 2,000 lines of code.

To OP, the ability to send a friend request / remove a friend etc. already is possible, but triggers an extra prompt. No public API exists for following, though.
http://wiki.roblox.com/index.php?title=API:Class/StarterGui/SetCore

[mathhhew]

I actually think this is a great idea.

[Azutreo (Azu)]

Yea, the issue I was getting at was the follower feature through the playerlist.

[Autterfly]

While this sounds like a great idea and feature (because honestly more customization == profit???) there might be an issue with things such as scam-bot games which could overwrite the playerlist to try to trick users (sorta like they do already, albeit better) and some may be naive enough to fall for the trick.

[EchoReaper]

there might be an issue with things such as scam-bot games which could overwrite the playerlist to try to trick users

This can already be done by disabling the PlayerList and re-adding a copy or using a custom one that looks decent.

The main blocker for this is more than likely updating developer-customized features. We’ve already experienced bad things with chat update compatibility, so we won’t see any new customizable features until this challenge is resolved (I offered a few suggestions in the linked thread).

[Autterfly]

It’s a bit different when you’re doing things such as editing CoreGui; why make it easier for the malicious users?

[EchoReaper]

Because we already do it for the chat/chat bubbles. Malicious use of services is not a matter of if, but a matter of when – people out to abuse ROBLOX are extremely dedicated and forced artificial difficulty will not decrease the amount of scam games, with its only effect being difficulty for legitimate developers. Sorry, we’re not going to intentionally butcher our platform to make it slightly more difficult to put out scam games – we will tackle them separately and more effectively.

[Autterfly]

Ah alrighty, fair enough. Then (on the other side of the argument) I guess there wouldn’t be much of an issue with this being added then?

[EchoReaper]

There are no issues with scamming, but we still have a hurdle to jump with this and similar features that developers can control. ROBLOX has experienced problems where they’ve pushed an update to the chat and it’s broken developer-implemented changes, so they’re looking into ways to improve that process before adding any more developer-customized features.

[Azutreo (Azu)]

Yea, all that is pretty valid. I was thinking whether there would be a way to be able to edit the playerlist without actually being able to edit it’s CoreAPI
I don’t know how that would be done because if only textlabels and frames were editable, then what’s the point if you want to… perhaps remove a player for a “vanish” mode or something.

[EchoReaper]

That’s the approach the chat uses. We’re not actually able to edit the CoreGui with custom chat – it’s 100% standard ROBLOX Lua, and we interface with the CoreGui via events/methods (which are optional, of course).

The problem with tweaking the PlayerList, whether it’s done through the CoreGui or not, is that ROBLOX updates will break your changes. Let’s say ROBLOX changes the structure of the list, so instead of name-stat-stat,name-stat-stat, it’s [frame: name-stat-stat],[frame: name-stat-stat], etc. Your script breaks and ROBLOX has to hold back on updating it in order to avoid breaking games.

I offered some suggestions to resolve the issue in the thread I linked earlier, so hopefully ROBLOX will change how developer-modifiable features will work to resolve this problem.

[Azutreo (Azu)]

Valid point. Perhaps a re-write to the PlayerList is required to make it more modular. :?

[EchoReaper]

Unfortunately modularization would not help either. This is something that needs to change with how ROBLOX handles developer-tweakable features in general rather than anything specific with the player list. I’ve made a suggestion on the linked thread, so hopefully that can be used as a start for implementing any necessary changes.

The Humanoid's 80/20 features should be ported to Lua

I don’t know how feasible it is to automagically back-port updates to customized Lua-ported features. I was going to originally suggest modularization, but even if we supported something like:

---------------------------
--      Chat Module      --
---------------------------
local chatModule = {}

function chatModule:GetPlayerChatColor(player)
    return self.chatColors[player.UserId % #self.chatColors]
end

return chatModule

----------------------------
--       User Script      --
----------------------------
local chatModule = require(chatModule)

chatModule.GetPlayerChatColor = function(self, player)
    return player:IsInGroup(1) and Color3.new(1,1,1) or Color3.new(0,0,0)
end)

to make minor customizations, what happens when we start changing the state differently in a replaced function and the feature breaks because another part of the script expects the state to be different? What happens when we want to change the arguments/what we return and a user has replaced the function?