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.
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.
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.
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.
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.
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!
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.
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
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.
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.
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!
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.
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.
v2.2.0 is here! 
