Planned Features

• Add an ignore user feature which will ignore requests to certain commands or all commands (depending on what I can construct when I have free time).
• Default to default prefix if Prefix Manager load() returns a null.

More to be added, please give your suggestions below and I will try to implement it if it is possible!

This was a bit of an oversight on my part but as the title implied, the pagination does not check if the message sender and the user who pressed is the same person.

A critical patch will be sent later.

One should be able to trigger commands with <@{id}> command and <@!{id}> command if it is enabled in VelenBuilder. It is really helpful if two bots have the same prefix or you can't remember the prefix of the bot.

Bookmark for implementation of middlewares and afterwares with the following:

• Category default middleware and afterwares.
• Global default middleware and afterwares.
• Individual command middleware and afterward.

Inspired a bit by Laravel's group feature wherein you can specify a middleware like this:

Route::group("api")->middleware("some_middleware");

Velen would take a different approach and instead use .cvelen files to create categories with settings, concept:

&[some_category]: category {
   middleware: some_middleware
   afterware: some_afterware
}

Velen velen = Velen.ofDefaults();
velen.addMiddleware("some_middleware", (event...) -> System.out.println("Hello World"));
velen.addAfterware("some_afterware", (event...) -> System.out.println("Goodbye World"));

This is up to debate. this will also replace the existing Conditions feature.

Interceptor

An interceptor will be an additional option to commands where you can add your own condition that the user or message must meet before the command will be triggered. An example would be:

VelenCommand.of("intercept", velen, (event, message, user, args) -> message.reply("Hello"))
.addInterceptor(event -> event.getMessage().contains("this command"))
.attach();

What the example will do is it will reply with "Hello" IF the message contains this command and it won't trigger if it doesn't. Additionally, if possible, I would also love to add a message which will be sent for intercepted commands that is purely optional.

Currently, Fuzzy Scoring (the multiple one used in VelenUtils) has a little thing where if two participants have the same score, it will pick the first one which may sound normal but for cases like hel -> hello, help, the scoring system will pick hello instead of help.

Solution:
Add a little if check to the scoring system where it will select the shortest length if an equals happens since the shortest length is more of a reasonable choice than the first one, instead of hel -> hello, help, we'd instead get: hel -> help, hello which sounds more correct to me.

The behavior of Velen right now disregards any duplicate commands whether it'd be a global command or a server-specific slash command which isn't the proper behavior. There may be one or multiple solutions to approach this, but so far that we thought of is the following:

• A method called Velen#index(DiscordApi) that fetches the list of slash commands globally, stores it.
• The method then performs a little bit of "indexing" by assigning Velen commands that have an equal name to a command in the list and has no server_only field attached to it before assigning a private slash command id to the command via internal methods: VelenCommandImpl#assign_slash_id. **
• Velen will then start performing slash command searches via O(N) again through something like commands.stream().filter(command -> id == comand.getAssignedSlashId()).findFirst(). ***

There is also another way to go about storing the slash command id without sacrificing O(1) but does take up a bit of memory, depending on how Java works and this preposition is to:

• Store the slash command id linked with the command in an HashMap that we call indexes that then routes to the specific Velen command in a HashMap such as: Map<Long, VelenCommand> since Maps stores references as far as I can remember and this shouldn't take up any resources.

While working on migrating Amelia from its own custom command system to Velen, I encountered one issue with pagination and that is, the fact that the current pagination method doesn't support normal pagination where you don't have a select reaction.

As always, my idea for this pagination is simple:

new Paginate<String>(results).paginateSimple(event, new PaginateSimpleEvent<>() {...});

The method: paginateSimple would simply be paginate but without the select reaction which means, there will only be three reactions: cancel, next and back.

According to my checks on the code again, it seems like the Permission requirement for slash commands is missing a return statement which is used to force the method to break away.

(Fix will be out later today together with the two issues).

All of these should check if the prefix value is null and handle it appropriately by defaulting to the default prefix, in the case of the reloadPrefix. I think I would prefer having it remove the prefix if it is null though, it's not a critical thing to change since it's still part of the end-user to ensure that the value shouldn't really be null (in my opinion).

What is this about?

The development of Velen has been stalled since a newer, more updated, and better framework is being completed instead which aims to replace Velen's slash command functionality. If you want to use a better slash command framework then I highly recommend using Nexus instead which performs so much faster and better especially in command synchronization, code appearance, and so forth. You can view examples of my new framework @ Examples.

Although still in the alpha phase, it has many if not all the current functionality of Velen and improvised upon. I'd like to thank everyone who helped out with Nexus for allowing this framework to flourish as well as it is now. 👋🏻

Do I have to move frameworks now?

NO! Not at all! Velen will be maintained in a weaker sense. It will receive patches that fix known vulnerabilities and be upgraded to the latest Javacord versions. If you do not need Velen to take advantage of the very latest features of Javacord at point-blank then using Velen is all good for you since I will keep updating it to the newest Javacord version without any worry, ensuring that it is always compatible with Javacord!

Why are you abandoning Velen?

The reason why I am abandoning Velen for Nexus is because of one thing: I don't believe in the future of hybrid and message commands anymore and the system of Velen doesn't fit well with me since to use the newer system of Velen, you have to copy over all the files that are .velen which is ugly and tiring for every change.

Nexus takes this away by using an OOP-form of generating commands that do not use ugly builders and give you access to the information of your command within arms reach. A simple Nexus command can be created by using this:

@NexusAttach
public class PingCommand implements NexusHandler {

    private final String name = "ping";
    private final String description = "Replies with a pong."

   @Override
    public void onEvent(NexusCommandEvent event) {
        event.respondNow().setContent("Pong!").exceptionally(ExceptionLogger.get());
    }

}

public class MainClass {

   private static final Nexus NEXUS = Nexus.builder().build();
   private static final int TOTAL_SHARDS = 2;

   public static void main(String[] args) {
      NEXUS.createCommandFrom(new PingCommand());
      new DiscordApiBuilder()
                .setToken(System.getenv("token"))
                .setAllIntents()
                .setTotalShards(TOTAL_SHARDS)
                .addListener(NEXUS)
                .loginAllShards()
                .forEach(future -> future.thenAccept(discordApi -> NEXUS.getShardManager().put(discordApi))
                .exceptionally(ExceptionLogger.get()));

        NEXUS.getSynchronizer()
                .synchronize(TOTAL_SHARDS)
                .thenAccept(unused -> System.out.println("Discord is now updated with all the commands."))
                .exceptionally(ExceptionLogger.get());
      
   }

}

It also has a more advanced middleware system that is far simpler and easier to work with than on Velen, its codebase is also easier to maintain with most built-in features such as rate-limiters, authentication (user, perms, roles) being written as middleware to speed up responses. All of these reasons combined with the fact that slash commands and interactions are the future makes me think that Nexus is the better choice for the future.

I do feel horrible for abandoning the Discord bots that are using Velen heavily but I do wish for the developers behind those bots to experience a better framework than what Velen has to offer and maintaining this framework is kind of futile for such, as such, Velen will be unmaintained from hereon.

Conclusion

This doesn't mean that Velen will no longer receive updates that will bring it up-to-date with the latest Javacord versions. I will continue to make Velen up-to-date with Javacord as much as possible and also patching any vulnerabilities if found, but that's about the limit.

Why are you doing this so complicated? The regex patterns you are using have named groups for getting the id.

• Combine SlashEvent and nomal Event
• Only one listener (Use the new argument extraction to allow getting arguments for normal events)

This would allow making Hybrid commands way easier. Instead of having to create two "listeners" for the same command, it would allow to reduce duplicate code and put both in one listener.

Velen should now update to the latest version of Javacord and fix any compatibility issues between the latest snapshot that Velen was based on and the current version of v3.4.0. There are no plans to update to v3.5.0 as of right now since v3.5.0 will be among the most breaking versions of Javacord.