2 Likes
a LOT of these seem unneccessary, for example
couldn’t you just get the Id FROM the info?
.. this is self-explanatory
Oh sorry let me paginate through all 67,000,000 of builderman’s followers to get the count
Roblox only does 200 friends so you need api to get all friends and you would have to getasync and just getting ids is the fastest
Get user friends info isn’t even used i don’t think
In general it’s not technically bad to have this many events… But in the long run it’s probably bad practice, due to things becoming unorganized and repetitive. I would consider combining some.
It would be wise to bundle similar remotes together under folders (put all the getters for users under User), but I’m wondering why you would need some of these remotes in the first place.
Why does the client need access to GetUniverseId?
So they can get a universe id of a place
How necessary are these RemoteFunctions for your game to begin with? You’d be better off making your own web app lol
1 Like
don’t create a post and then NOT show me what these functions do and THEN give me a snarky and sarcastic response when i try to help
1 Like
That’s a lot of RemoteFunctions, but for the most part, I like it. Some aspects that could be improved are capitalization consistency and interpretable names. Some of the bottom Remotes use camelCase casing instead of PascalCase in their names. I’m not sure if that’s intentional. Also, some of the names seem to lack context. As one of the posts above expresses, GetUniverseId is not exactly a foolproof name/description; it doesn’t define what exactly it takes, or what it’s for. GetUniverseIdFromPlaceId would probably be a more suitable name. There are probably some other names that lack context as well, but that is just one example, and it’s not that big of a deal. But if you’re just mirroring the Roblox API method names, then this is irrelevant, because that’s still a sturdier fulcrum for your naming conventions. As for organization, there’s probably more than enough Remotes to validate putting them into separate sub-folders, like for Users, Places, Groups, Search, Gamepasses, etc. However, this is just a preference, and you’d have to navigate a tree of folders instead of just relying on autocomplete to get what you want instantly from one place while scripting.
In all fairness, he did do that to solidify what the RemoteFunctions do, in an extreme scenario, and your initial post was a bit presumptuous. His original question was about organization, not digging into what the Remotes do. If you don’t like his reply, report it, and see if it’s actually breaking the rules. Otherwise, leave it be, or if it’s really personal, discuss it in a private message. Please just let the Dev Forum be a peaceful place 
not making unnecessary remotes is a key part of optimization
in order to know whether a remote is really needed, we gotta know what they’re actually for
2 Likes
(mods took down my original post for no reason)
Excellent point, good sir! But I do believe understanding what these RemoteFunctions do is a key part of helping to organize and optimize the Original Poster’s game! Have a wonderful, scrumptious, absolutely exquisite rest of your evening!
4 Likes
The camal case ones are custom and use multiple API endpoints like getUserGamepasses which gets all of the user’s universes and then cycles through those and gets all of their gamepasses.
The pascal case ones only use 1 API
1 Like
What you’re doing is fine as long as none go unused and each RemoteFunction is doing something that can’t be done on the client. There are a surprising number of things that can stay client-side, like UserService and some group operations.
Definitely keep them segregated if they have individual quotas (like HTTP requests)
If you start to have Set* endpoints, I’d group everything in a folder like Get.UserInfo.
I would just put them in organized folders inside of that one folder.
For example, remote functions to do with any friends api could be put in a friends folder.
I would combine some though.
For what purpose? When does the client actually need that info, and why is it given arbitrary access to it at any time?
Some of these could give exploiters a vector to exhaust your API usage limits (which I assume you already accommodate with custom rate-limiting/caching). However, it would be good to know what client logic you plan on having that requires all of these APIs.
1 Like
Don’t worry it is only 1 person per server so idc