Group context API


#1

Hello DevForumers!

So basically I think I’m gonna start with the basic template…

It’s currently hard to manage groups in-game so I think these things would be cool for everybody:

  • Group context menu - you could manage and see groups you are in
  • Group join dialogue and it’s callbacks
  • Server based functions:
    • Is player awaiting for acceptation?
    • Accept / decline player request
    • Promote player
    • Hopefully shout?

Why these things? I think there’s some simple reason. Roblox already has setupped some functions such as checking role etc., but it hasn’t made any of the group managing functions. It would be really easy if you could use just function to accept or promote player witheout doing proxy and things like that. Roblox can easily check is game’s holder an exact group and run these functions, so you don’t have to do api, security tokens which can be stolen.

About group join dialogue - wouldn’t anybody dream of doing “Click to join our fan group!” button instead of “Search up (GAME TITLE) on Roblox and join us to get… bla bla bla”

Tell me what you think about that!

Regards!

EDIT: I also think that Loadstring should be disables to use this feature.

EDIT2: However like people said - group API scripts should be placed in the ServerScriptService or there should be a tickbox in settings in order to prevent malvare in free models and other danger.


#2

To add to that, it shall only work if the place owner owns the group the user has set in the script for safety reasons.


#3

Exactly, that’s what I mean. If player is group’s owner or game is held by group.


#4

I don’t see any significant problems off the top of my head as long as it’s required for the Script to be a ServerScript and it be in ServerScriptService (as it should be regardless). Meet those conditions, you got my support as it’d be pretty nifty.


#5

That embedded button would be super useful. I could see it also being useful for game play buttons and the like, too.

As for the group functions, those are all good, apart from one issue: code the owner does not know of/understand.

Someone could find a way to get the owner to put malicious code in their game that shouts inappropriate text and kicks everyone. Or the owner could be stuffing around with free models and a common group-kick virus stuffs up their completely unrelated groups.

A tickbox like experimental mode/http enabled/etc. for the theoretical group API with a warning could help with this, however it’s still a danger.


#6

Ikr, but there were games which were stolen with the scripts from ServerScriptService, so that’s nothing old.


#7

I agree with you - there should be note about danger and some option like HttpEnabled, but Im sure that Roblox has enough options to verify the server while we don’t. For example - I have never heard of issues with the purchase dialogue. As for the malware scripts - group managing api could be enabled only in the ServerScriptsService to block the malware scripts (if they exist) and warn people to not put unsafe things into it.


#8

No, I was meaning in terms of things like admin commands and free models that have server-side code but are beyond the understanding/control of the game’s owner.

You know how there are virus scripts in free models? Imagine one that parents itself to ServerScriptService and removes everyone from every group the place’s owner has permission to do so.

Letting clients do anything is just plain stupid.


#9

Yes, I am aware of them. I think that reparenting script by itself into ServerScriptService should be disabled though. I meant - I think that it should be enabled in only some cases.
ScriptA descendant of ServerScriptService parents ScriptB into it (from Workspace) - OK
ScriptA descendant of ServerScriptService parents itself into other place in ServerScriptService - OK
ScriptA descendant of Workspace parents itself into ServerScriptService - Not well


#10

No, it should still be allowed on all server-sided scripts. ServerScriptService should not be a requirement for anything, and it never has been. This would be inconsistent and pointless - and, considering the context, what if they put their admin script into ServerScriptService anyway?

What you’re theorising could potentially break current code and puts a band-aid on the issue (to expand on the metaphor, it wouldn’t cover the wound fully either xd).

I think a simple toggle would solve the issue the best way possible – unless the issue doesn’t get created at all.