Voyager | A Roblox API wrapper for Discord webhooks

Resources Community Resources
, , , ,
#4

Change the name. There’s already a resource for Discord Webhooks (Not for Roblox) called Discohook. You should look up the names you’re going to use before you actually use them…

3 Likes
#5

There’s already a resource for Discord Webhooks

Personally I don’t see the issue with the name, both utilities can exist with the same name, there is a huge difference between utilities as one is a Roblox API wrapper and the other is a website, while yes both do similar things like sending messages through Discord webhooks, it does not justify a rename.

But if enough people want a rename then I’ll happily rename it, but at the current moment I don’t see any benefit and I’d much rather spend my time improving the module rather than waste time renaming it.

1 Like
#6

I was only telling you to rename the resource because people looking for this could find the other resource & get confused searching for the Roblox stuff and not finding anything, and vice versa, but I doubt they’ll do anything about it so if you want to, I guess you could keep the name.

1 Like
#7

Your module is amazingly made and super useful. I love to see work such as yours that developers spend lots of time and love on. I will most likely use your module for an advanced feedback system.

1 Like
#8

would be cool if you found a way to implement features like these

#9

That’s a completely different Discord field.

This resource is for webhooks, not Discord Bots.

1 Like
#10

:tada: v2.2.0 is here! :tada:

New stuff

  • Voyager now supports self hosted WebhookProxys.

  • thread_name support for forum channels.

  • Reworked the way Voyager handles flags to be easier to use.

  • Improved request validation.

  • Bug fixes.

  • Better code quality.


Breaking changes

  • Removed User:hasFlag

  • Removed User:getFlags

  • Embed:setImage(url, height, width) → Embed:setImage(url)

  • Embed:setThumbnail(url, height, width) → Embed:setThumbnail(url)

  • User.publicFlags: number → User.publicFlags: PublicUserFlags

  • Message.flags: number → Message.flags: MessageFlags

  • Webhook.Enum.AvatarImageFormats.jpeg → Webhook.Enum.AvatarImageFormats.JPEG

  • Webhook.Enum.AvatarImageFormats.png → Webhook.Enum.AvatarImageFormats.PNG

  • Webhook.Enum.AvatarImageFormats.webp → Webhook.Enum.AvatarImageFormats.WebP

  • Webhook.Enum.AvatarImageFormats.gif → Webhook.Enum.AvatarImageFormats.GIF


Full change log

  • Added BaseFlags object

  • Added PublicUserFlags object

  • Added MessageFlags object

  • Webhook constructor has a new parameter: customProxyUrl

  • Webhook:_validateExecuteRequest’s third parameter now takes an OptionalExecuteInfo object and has been renamed to optionalExecuteInfo

  • Embed:setImage now only takes the url parameter

  • Embed:setThumbnail now only takes the url parameter

  • OptionalExecuteInfo constructor has 2 new parameters messageFlags and threadName

  • OptionalExecuteInfo now has 2 new properties OptionalExecuteInfo.messageFlags and OptionalExecuteInfo.threadName

  • User.publicFlags now returns a PublicUserFlags object instead of a bitfield

  • Removed User:hasFlag

  • Removed User:getFlags

  • Message.flags now returns a MessageFlags object instead of a bitfield

  • Webhook.Enum.AvatarImageFormats.jpeg → Webhook.Enum.AvatarImageFormats.JPEG

  • Webhook.Enum.AvatarImageFormats.png → Webhook.Enum.AvatarImageFormats.PNG

  • Webhook.Enum.AvatarImageFormats.webp → Webhook.Enum.AvatarImageFormats.WebP

  • Webhook.Enum.AvatarImageFormats.gif → Webhook.Enum.AvatarImageFormats.GIF


TL;DR

This new version of Voyager mainly consists of internal code changes to improve code quality and maintainability. However, there are a few new features such as better flag handling, thread_name support for forum channels, support for self-hosted WebhookProxys and even better request validation. Unfortunately, there are some breaking changes. Be sure to check the list of breaking changes before switching version, moving forward deprecation will be used instead.


Thank you

I would like to thank all of you for your support. Your kind words are what motivates me to keep working on this project. Even if you didn’t leave a comment, simply giving this project the time of day to check out on the devforum means everything to me.

#12

:tada: v2.3.0 is here! :tada:

New stuff

  • Discohook has been renamed to Voyager

  • The structure of the lib has changed, now all the module scripts are kept inside a folder.

  • Enum has moved from the Webhook module script into Voyager/utilities

  • Documentation has been moved to a mkdocs site

  • Documentation site now has a tutorial section

  • Added use case examples to github repo

  • Added Webhook:_request

  • Added Webhook:_validateEditMessageRequest

  • Webhook:execute’s queue and waitForMessage params are now optional

  • Webhook object got a new property ratelimitInfo

  • Webhook methods like :_request, :execute, :editMessage, :deleteMessage now return a table containing information about the request’s status.

  • Added User.globalName

  • Removed Embed:toDictionary

  • Bug fixes

  • Improvements to internal code


Deprecations

  • Author.discriminator

  • User.discriminator

  • User.displayName


TL;DR

Discohook has been renamed to Voyager. New documintation site is here! Stop using Author.discriminator, User.discriminator, User.displayName as they have been deprecated. Version 2.3.1 will most likely remove all deprecated properties. The structure of the lib has changed, now all the module scripts are kept inside a folder.


What’s next?

Unfortunately, for the foreseeable future no new features will be coming to Voyager. In addition to this, I as the main maintainer will not be searching the codebase for bugs anymore. The reason I’ve decided to do this is because Voyager has become robust enough to not warrent this anymore. I will still maintain Voyager with bug fixes, if bugs are reported to the github. also Voyager already covers a good amount of Discord’s webhook API, the things that have been left out of Voyager are things that I see as having no use case.

1 Like
#13

:tada: v2.4.0 is here! :tada:

New stuff

  • Added Webhook.fromUrl()

  • Added Message.jumpUrl

  • Added Message.createdAt

  • Added EditedMessage.editedAt

  • Added EditedThreadMessage.editedAt

  • Revamped manual ratelimiting (now actually useable!)

  • Added RatelimitInformation type

  • Added RatelimitedInformation type

  • Webhook methods _request, execute, editMessage and deleteMessage now also return a dictionary of either type RatelimitInformation or RatelimitedInformation

  • Added RequestStatus.message

  • Added RequestStatus.reason

  • Bug fixes

  • Improvements to internal code


Deprecations

  • Message.timestamp

  • EditedMessage.editedTimestamp

  • EditedThreadMessage.editedTimestamp

  • Webhook.ratelimitInfo

  • RatelimitInfo Type


What’s next?

  • Publishing Voyager to a Roblox package manager like Wally.

  • Moving Voyager to a new OOP idiom, one in particular that caught my attention was the idiom discovered by @darmantinjr, the pros of moving to this idiom are in the devform post, but to put it in short I feel like it would improve internal code quality and developer experience in general. Since this change is quite big I would love to hear what you all think about it in a poll below, the results will help me finalise the decision on whether or not to implement this change.

  • Refactoring the Webhook class’s methods. The first change I’d make to them is renaming the execute method to sendMessage or something similar, then I’d split up the methods into two different methods to reflecting this format → editMessage, editMessageInThread for example, this would serve to make code more readable.

  • Small refactor to the Embed class as I feel like it does not abstract enough from the API, examples of this being the color and timestamp properties being the raw values sent to the API.

  • Change from camel case to pascal case to match roblox’s official styling. example: Webhook:editMessage() → Webhook:EditMessage()

That’s all I currently have in mind for Voyager at the moment, please do note that all the above are subject to change! Any breaking changes mentioned will not be added in v2 of Voyager. If you have any thoughts you would like to share with me on the changes mentioned here please do let me know. Thanks for reading!


Idiom Change
  • I am in support of this change.
  • I am not in support of this change.

0 voters

1 Like
#14

:tada: v2.5.0 is here! :tada:

New stuff

  • Added utility MentionFormatter

  • Added utility EmojiFormatter

  • Added utility DateFormatter

  • Added property Author.mention

  • Added enum AvatarImageFormats.WEBP

  • Added enum MessageFlags.SUPPRESS_NOTIFICATIONS

  • Added method MessageFlags:getFlags()

  • Typing improvements

  • Improvements to internal code


Deprecations

  • Class Emoji

  • Class Reaction

  • Property Message.reactions


What’s next?

Hopefully the release of v3! I’ve begun planning what changes should take place in v3, unfortunately it’s still a little early to say what I have in mind, but in the coming weeks I should be able to finish up planning. I know that some of you may have some questions, so I will leave a short Q&A below.

Q: Will new features be added to v2 while v3 is being developed?
A: No, I will only supply v2 with bugfixes until v3 is released.

Q: How long will v3 take to develop?
A: While I’m unsure how long the development process will be, I can say for sure that it wont be here anytime soon.

Q: How will I know how to migrate my v2 code to v3?
A: I will create a code migration guide which will be found in the documentation.

2 Likes
#15

sorry everyone, I accidentally posted the v3 release notes while writing them.

1 Like
#16

:tada: v3.0.1 is here! :tada:

What’s new?

  • Voyager classes are now no longer parented to a folder, they are now parented to a module script. Requiring this module script gives you access to all Voyager classes without the need to individually require them.

  • Documentation page has been given a new look.

  • Improved documentation.

  • All methods and properties have been renamed in pascal case (excluding constructor methods) to match roblox’s official code style

  • Added method SendMessageInThread to Webhook

  • Added method EditMessageInThread to Webhook

  • Added method DeleteMessageInThread to Webhook

  • Added method SetFieldAt to Embed

  • Added method RemoveFieldAt to Embed

  • Added method RemoveAllFields to Embed

  • Added new type ProxyInformation

  • Added property ProxyInformation to RequestStatus

  • Added property RatelimitInformation to RequestStatus

  • Improved Embed validation

  • Improved request validation

  • Improved internal code

  • Voyager is now on wally!

How do I migrate my code to v3?

Please visit this section of the documentation to see the full list of breaking changes.

What happened to v3.0.0?

Unfortunately due to inexperience with wally, v3.0.0 was not compatible with wally due to voyager not having an init.lua to package the internals and expose them publicly. Sadly I did not catch this until it was too late, v3.0.0 was uploaded to wally in a non-functioning state.

I decided it would be best to hold back the release of v3.0.0 and release v3.0.1 instead, so both the version on wally and toolbox/model file would be functioning as intended.

What’s next?

At the current moment I intend to stay alert for any new bugs this update may bring.

As for any upcoming features I don’t really have any in mind right now, so if you wish to see a new feature added, make sure to leave an issue on the github.

Future updates will most likely consist of bug fixes, but new features can also be added just less frequently.

#17

local message, b = voyager:SendMessage(nil, {embed})

message is = nil for some reason. Do you know why?

#18

Hello Unceen, the reason why message is nil is because Voyager defaults to using the queue for sending messages, when a message is queued no message object will be returned. To fix this you need to set the queue argument to false and the waitForMessage argument to true. If you need an example go here and scroll down until you see example 5.

Hope this helps.

1 Like
#19

Thank you! I’m really loving this module. I feel like it’s really simple to use and more user-friendly than discohook for example. Looking forward to future updates!

1 Like
#20

Looks like the proxy went down.

#21

will creating threads ever be supported?

#22

You can create threads in forum channels only at the moment. I don’t think the webhook API allows for creating threads in regular channels sadly, if you know how to, please do let me know and i’ll add it next release.

#23

image

sites like discohook also have an option to create threads, so it is possible. as far as i know

#24

Discohook can only create forum threads (see picture below), and the documentation link you sent is detailing gateway events for threads, gateway events are only for bots and not webhooks.

image
image948×108 4.67 KB

1 Like