Functions Module

Resources Community Resources
, ,
#1

Hi folks, today I have created a module you could use when scripting, or if you are new to scripting, to save you some precious time and effort.

Open-sourced code can be found here: General Functions | Webhook Module

Requiring the Modules

In order to use the module, you need to require it.

To get started, create a script, and respectively insert the line required for the library you wish to use.

local Functions = require(5495308850);
local Webhooks = require(5576797903);

Now you can get onto actually using the functions, which are explained below:

Using the Functions

Webhook Library

Function 1: SendQuote

In order to use this function, add a line of code in your script with the following details:

Webhook: The Discord webhook being used.
Message: The message you want sent.
Player: The player sending the quote.

To send the data, use the following in your script:

Webhooks:SendQuote(Webhook, Message, Player)

And it will post through the webhook a message like the following:

“Message” - Player Name

Function 2: SendMessage

In order to use this function, add a line of code in your script with the following details:

Webhook: The Discord webhook being used.
Message: The message you want sent.

To send the data, use the following in your script:

Webhooks:SendMessage(Webhook, Message)

And it will post through the webhook a message like the following:

Message

Function 3: SendEmbed

In order to use this function, add a line of code in your script with the following details:

Webhook: The Discord webhook being used.
Title: The embed title.
Description: The embed description.

To send the data, use the following in your script:

Webhooks:-SendEmbed(Webhook, Title, Description)

And it will post through the webhook an embed with the given title and description.

General Functions

Function 1: GetPlayerFromPartialName

To use this function, you need the following information:

PartialName: The partial name you wish to get the player from.

Add a line in your script with the following:

local Player = Functions:GetPlayerFromPartialName(PartialName)

This cycles through every player in the game until it finds a match and then returns that match.

NOTE: This returns a player, not a Name.

Function 2: HandTo

To use this function, you need the following information:

Sender: The player sending the tool.
Receiver: The player receiving the tool.

Add a line in your script with the following:

Functions:HandTo(Sender, Receiver)

What this does is it will search the sender’s character for the tool they are holding, and move it into the receivers backpack. Both the sender and receiver must be players, such as game.Players.Diamond9195, not "Diamond9195".

Update Archive

Version: 1.1
  • Removed Function 5: GameAnnounce
    – Could mess with a games color scheme
  • Removed Function 7: GetGroupInfo
    – Already covered by game.GroupService:GetGroupInfoAsync()
  • Moved all Discord-side functions to a separate library
    – Helps with readability when writing scripts.
Version: 1.0

Module released as a first draft to the public with 7 functions.

Suggestions/Improvements/Comments

I am open for any feedback you wish to give. If you would like a function added, please specify the function name and what it should do and tag me in the reply. If you have any improvements or comments feel free to reply to this post with them and I will be happy to reply.

4 Likes
#2

I feel like these kinds of amalgamation resources are pretty bad for development use. They’re often subject to a bad anti-pattern, API bloat. A library should only cover one certain item in the development process rather than several topics in one module.

This module right now contains five libraries at minimum worth of functions: webhooks, service utilities (players and groups), broadcasts (center ribbon) and tool management. Although there is no concrete standard, often these would be split into their own modules so that you’re only importing the pieces your code needs, not everything altogether. Splitting them also helps for readability which is super important in code.

local Functions = require(123456)
local Webhooks = require("Webhooks")

This is an example of how code may look depending on implementation. Do you see where the readability factor comes from? When I want to work with webhooks, I want to make it brutally obvious that I’ve imported a webhook library first before working with it. It’s not as readable if you just see one import yet a good chunk of functions you want to be using just come from that one library.

I have complaints with 5, 6 and 7. Each of these provide decent utility but they’re problematic for games looking to use this resource in production. I haven’t taken a look at the source so please correct me if I’ve gotten something wrong. These are all negligible under the argument of “developers can just choose not to use them”.

  • Function 5 shouldn’t be in a module at all because each game’s implementation of broadcasts, if they want it at all, will be different. If you already have a Gui set up, then it can break the game’s UI theme or consistency very badly. This isn’t a chat command system so that would probably be all the more cause to stay away from the use of this function.

  • Function 6 may not be compatible for all cases of games, especially cafe games that make heavy use of handing tools to others. They may want to write in their own processes to function with other systems, such as accepting or rejecting a hand tool request and incrementing or decrementing points.

  • Function 7 is already covered by GroupService.GetGroupInfoAsync. This function reinvents the wheel for a natively supported function and should not be used or present here at all. GroupService has this function as well as others you may need to when you want to work with group data for your game.

I would personally recommend splitting these into separate libraries that are compatible with other library loaders or frameworks. You can still publish everything as a single package of libraries you’ve made, which other developers can then pick and choose what they want to use. It would mean that direct requires would have longer paths but that’s really a non-issue compared to the negatives, chiefly code readability and not adopting good practice.

7 Likes
#3

Alright, I will separate them into separate modules.

I never thought of this when making it, I will remove it now.

I will remove that aswell.

I am aware, and it isn’t made for scripters who are experienced as such, it is mainly for new scripters who have no idea where to start.

Thanks for the feedback, anything stated here will be put in soon.

1 Like
#4

All changes specified in my previous reply have been added

Regarding this here, the module only covers the giving of the tool. If games wanted to implement that system they easily could.