unseenfaith / komada Goto Github PK

Version of Komada

0.18.1

Are core files modified?

No

Describe the problem

The addKey function incorrectly checks for values in key and defaultValue.

Expected Behaviour

The if condition checking for key and DefaultValue checks for an unset variable.

Actual Behaviour

The if condition checks for false instead. This results in problems if you need to use false as DefaultValue.

Steps to Reproduce.

!eval client.funcs.confs.addKey("cmdPrompt", false)

Version of Komada

v0.20.10

Are core files modified?

No.

Describe the problem

Uncaught promise error when trying to send a message in a channel that the bot can see but cannot talk in. This happens with System Commands and custom commands.

Expected Behaviour

The error should be caught or handled in some way.

Actual Behaviour

This Error is given:
Uncaught Promise Error: DiscordAPIError: Missing Permissions at item.request.gen.end (/root/node_modules/komada/node_modules/discord.js/src/rest/handlers/RequestHandler.js:52:65) at then (/root/node_modules/komada/node_modules/snekfetch/src/index.js:263:21) at <anonymous> at process._tickDomainCallback (internal/process/next_tick.js:228:7)

Steps to Reproduce.

1. Make a text channel that the bot can read messages, but not send messages.
2. Use a command in that channel and receive an error in the console.

Another uncaught promise error (dont know how to reproduce this one)

Uncaught Promise Error: TypeError: Cannot read property 'missing' of null at Object.exports.run (/komada/src/inhibitors/missingBotPermissions.js:22:88)

Version of Komada

0.18 on Centos 7

Are core files modified?

No

Describe the problem

I noticed however that after upgrading to 0.18, ready.js in the events folder is not executing on bot being ready.

Expected Behaviour

When the bot loads, ready.js from events is fired. I have a console.log to tell me when it is fired. It also creates an open port to receive metadata from a radio system to put as a channel topic in a guild.

Actual Behaviour

ready.js does not appear to fire. Nothing in the log about it firing, and the server port supposed to start up on ready is not started.

Steps to Reproduce.

1. create a ready.js script in events.
2. Make ready.js output something to the console on fire.
3. Start the bot via. pm2 or via. node.
4. ready.js does not appear to fire.

Version of Komada

0.18.3#indev

Are core files modified?

No

Describe the problem

TypeError: client.funcs.permissionLevel(...).catch is not a function
    at Object.module.exports [as awaitMessage] (/mnt/c/Users/manue/node_modules/komada/functions/awaitMessage.js:8:90)
    at module.exports (/mnt/c/Users/manue/functions/handleCommand.js:17:22)

Expected Behaviour

If client.config.cmdPrompt is set to true, it should prompt (even thought it's broken until the usage.js rewrite).

Actual Behaviour

It logs on the console as an uncaught promise error, with no new message on the channel.

Steps to Reproduce.

Download 0.18.3#indev and set cmdPrompt to true.

Version of Komada

0.20.10

Are core files modified?

No

Describe the problem

I only notice when I get errors with my moderation commands, however, my Guild settings are being reset back to their defaults or null. I do not know when this happens.

Expected Behaviour

Guild settings wouldn't get randomly reset?

Actual Behaviour

I set the guild settings, then a few days later I eval my guild settings and they are reset back to null

Steps to Reproduce.

Using eval to add items to the guild settings, such as a modLog channel ID or adminRole ID

Proof: On September 8th
https://gyazo.com/7ea7ecc815324e4873bda3ff899fb18b

On September 11th
https://gyazo.com/90d9ddb48f08ce364dd4d503c482c689

I haven't manually reset them.

Place functions like elevation and reload in ./features/core and add new optional features like points in ./features/optional

Load dynamically using the name. Some functions may require optional features.

Using the simplest method possible (json?) Enable per-server configurations: roles, prefix, enable/disable commands.

Version of Komada

0.18.1

Are core files modified?

No

Describe the problem

I wrote basic function that should send a message and then edit it

Expected Behaviour

The command file should load just fine

Actual Behaviour

At startup the loader ejects some errors about \n in markdown (???) that look like this:

{ code: null,
  message: 'Could not load new command data: /`/`/`js\n/home/szymex/test/discord/komada.js/commands/Misc/test.js:2\n  const message = await msg.channel.sendMessage("Ping?").catch(err => client.funcs.log(err, "error"))\n                        ^^^\nSyntaxError: Unexpected identifier\n    at createScript (vm.js:53:10)\n    at Object.runInThisContext (vm.js:95:10)\n    at Module._compile (module.js:543:28)\n    at Object.Module._extensions..js (module.js:580:10)\n    at Module.load (module.js:488:32)\n    at tryModuleLoad (module.js:447:12)\n    at Function.Module._load (module.js:439:3)\n    at require (internal/module.js:20:19)\n    at Promise (/home/szymex/node_modules/komada/functions/loadSingleCommand.js:30:13)\n    at Object.module.exports [as loadSingleCommand] (/home/szymex/node_modules/komada/functions/loadSingleCommand.js:3:72)\n    at files.forEach (/home/szymex/node_modules/komada/utils/loadCommands.js:10:26)\n    at Array.forEach (native)\n    at Promise (/home/szymex/node_modules/komada/utils/loadCommands.js:9:11)\n    at process._tickCallback (internal/process/next_tick.js:109:7)/`/`/`',
  stack: null }

I've put the backslashes in the error msg so it wouldn't collide with GH's markdown

Steps to Reproduce.

I don't know, my PC is Linux Mint 18.1 Cinnamon
Node 7.7.2
This is my main file: Link to gist
And my ./commands/Misc/test.js file: Link to gist

Version 12.1.0 of eslint-config-airbnb-base was just published.

This version is covered by your current version range and after updating it in your project the build failed.

eslint-config-airbnb-base is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

Version of Komada

0.19.0

Are core files modified?

functions/usage.js is, everything else is not

Describe the problem

TypeError: Cannot read property 'target' of undefined
at WebSocketConnection.onOpen (/root/discordjs/lovinibot/node_modules/komada/node_modules/discord.js/src/client/websocket/WebSocketConnection.js:318:25)
at native.client.group.onConnection (/root/discordjs/lovinibot/node_modules/uws/uws.js:53:15)

Expected Behaviour

Komada starts up

Actual Behaviour

Komada starts up but continues to spit out the error
TypeError: Cannot read property 'target' of undefined
at WebSocketConnection.onOpen (/root/discordjs/lovinibot/node_modules/komada/node_modules/discord.js/src/client/websocket/WebSocketConnection.js:318:25)
at native.client.group.onConnection (/root/discordjs/lovinibot/node_modules/uws/uws.js:53:15)

This results in an immediate crash.

Steps to Reproduce.

1. npm install komada on a 0.18.1 installation to upgrade to 0.19.0
2. npm install uws to update uws (this was an attempt to fix the bug, which was not successful).

D:\c2857\Desktop\Discord Bots\guidebot\cmds\reload.js:11
if (params[0].includes(".js")) params[0] = params[0].replace(".js","");
^

TypeError: Cannot read property 'includes' of undefined
at Object.exports.run (D:\c2857\Desktop\Discord Bots\guidebot\cmds\reload.js:11:18)
at Client.bot.on.msg (D:\c2857\Desktop\Discord Bots\guidebot\app.js:77:9)
at emitOne (events.js:96:13)
at Client.emit (events.js:188:7)
at MessageCreateHandler.handle (D:\c2857\Desktop\Discord Bots\guidebot\node_modules\discord.js\src\client\websocket\packets\handlers\MessageCreate.js:9:34)
at WebSocketPacketManager.handle (D:\c2857\Desktop\Discord Bots\guidebot\node_modules\discord.js\src\client\websocket\packets\WebSocketPacketManager.js:94:65)
at WebSocketManager.eventMessage (D:\c2857\Desktop\Discord Bots\guidebot\node_modules\discord.js\src\client\websocket\WebSocketManager.js:220:31)
at WebSocket.ws.onmessage (D:\c2857\Desktop\Discord Bots\guidebot\node_modules\discord.js\src\client\websocket\WebSocketManager.js:78:37)
at WebSocket.onMessage (D:\c2857\Desktop\Discord Bots\guidebot\node_modules\ws\lib\WebSocket.js:442:14)
at emitTwo (events.js:106:13)

I myself fixed it by adding a return if params[0] is null

Version of Komada

0.20.4

Are core files modified?

No.

Describe the problem

At logon using a Bot Token, the error TypeError: this.api.oauth2.applications is thrown
See here for the full error

Expected Behaviour

Bot logs in

Actual Behaviour

Bot doesn't work at all.

Steps to Reproduce.

Use latest indev Komada

Version of Komada

v0.20.7

Are core files modified?

No.

Describe the problem

Reloading a command doesn't reload the commands' usage arguments, if you had wrote it incorrectly and tried to reload it to fix it - or at least not in this case.

Expected Behaviour

Reloading the command which previously had incorrect syntax in the usage arguments, then fixed, should update the command usage and reload it without errors.

Actual Behaviour

The same error is displayed when trying to reload the command, as was displayed when you made the syntax mistake, despite the usage being fixed. A reboot is necessary to reload the command properly.

Steps to Reproduce.

1. Upload this test.js (a simple command with some usage args) command and load it, the arguments are written correctly.
2. Edit the file on your server and change the first argument from <anInteger:int{1,10000}> to <anInteger:int{1,10000> and reload the command, you will get an error because it is incorrect.
3. Edit the file and fix the syntax error by putting the } back in, and try to reload the command, it will show the same error in Step 2.

Use awaitMessages to make a simple quiz command. Optionally use a score/points module if present.

Version of Komada

v0.18.10

Are core files modified?

Nope

Describe the problem

When I do set the conf to a message with space example: Welcome to the server

That's will set only Welcome..

Expected Behaviour

Will set Welcome to the server

Actual Behaviour

Set only Welcome

Steps to Reproduce.

Create an string into the conf file, and try to set it with space

Same for the adminRole and modRole

Now that custom structures is merged into Discord.js#master, I can safely work towards updating Komada and putting it back on it's track to its first official release. This will either be a minor bump or Komada's official first release, depending on how much or how far I decide to go on some of the things I want to add.

Testers for this PR would be appreciated.

Moving this over here because the PR was clustered with way too much shit and I lost track of what was being done. Everything from this point onward's will be little, small additions instead of one big PR. Some of the stuff on this list is already done, but not checked off as well.

Planned Things (Will definitely add)

• New Settings (and maybe a SettingGateway port to Pieces if people want the extra option)
  • The current Settings system is quite daunting for new users, and I'd like to create a simple solution that doesn't require much effort to learn or use.
• New Argument Prompting System
  • The current argument prompting system blows. It doesn't work as intended half of the time and it could be a completely better solution. As of 99a7734 argument prompting has been removed completely from Komada, pending a better implementation.
• Readd CommandEditing
  • Broke it with Custom-Structure changes, probably just as simple as porting over the methods to the KomadaMessage class.
• Remove these dumb eslint devdependencies.

Breaking Changes

• permLevels -> PermissionLevels (index.js)
  • PermissionLevels now caches the levels inside of an array, and you can specify the number of levels by passing it in the constructor. An owner-only level will be added at the highest level you specify.
  • .addLevel(level, brk, func) => .add(level, brk, func)
  • .reset(level) -> Resets the specified level back to default (basically a delete function)
• Finalizers
  • Finalizers now require a configuration object.
  • The only property currently is "enabled". That's not to say that more won't be added a later date though.

exports.conf {
  enabled: true,
};

Low Priority Things (Might be or Might not be added)

• Localization
  • There hasn't been much demand for Localization, but this could be useful implementing nonetheless.
• Rewrite KomadaConsole
  • It works, but it could be improved in several portions and made easier to use
• Add extra events for Commands
  • commandRan, commandInhibited, thing of these nature.
• Custom Messages for Required Arguments
  • Allow users to pass messages into Komada's internal ArgumentParsing so they don't have to use Optional Arguments just to throw their own custom messages.
• Better Error Handling
  • Create a better error handling system that replaces the dumb one I added specifically for argument parsing, which let users identify problems easier and faster.
• Logs
  • I'd like to add the ability to read and write to log streams for certain things in Komada, like errors, command runs, things of that nature. Although this would be a nice feature, I'm not sure how feasible it is for Komada's user base.
• Dashboard
  • Something I've been wanting to do for awhile now is giving Users the ability to programmatically create their dashboard using Komada. Unfortunately this would take a very long time and the concept design would be hard to understand, but there's definitely potential here.
• More Documentation
  • Documentation is always good, and the website is quite lacking it. I'd like to have more examples added to the website, or even something like a Quick Starter Guide, to help those ease into the framework easily.
• Persistent KomadaStorage
  • People were using SettingGateway to store things not even related to settings, such as tags commands. While I'm not opposed to creativity, I would prefer if there was a Persistent Module within Komada that could be used freely without all the constraints that SettingGateway has.
• DataStores
  • Komada might benefit from DataStores like in Klasa and could reduce a lot of code duplication.
• Inhibitors
  • Make Inhibitors Asynchronous again, because I like making people suffer.
• Extendables
  • Make extendables reloadable.
• Stats
  • Some stats would be and useful, such as most command used in guild, most command used by user, etc.
• RichMenu/Display
  • Port these over from Klasa, shouldn't be too hard.
• Help Changes
  • I'd like to create a new help command or even better a HelpTemplate so that issues don't crop up when using the default help command.
• Implement the ability to custom load things
  • Equivalent to Klasa's CustomPieces and CustomDataStores... but in Komada format.
• QoL Changes
  • Store Command Object References instead of just strings of the command.
  • Monitor to reply with prefix. (Similar to the one currently in Klasa)
  • Maybe start validating pieces loaded into Komada?
  • The README could use a fresh coat of paint by someone currently developing the framework and not a previous developer.

Completely New Things

• Disable/Enable
  • Enabling/Disabling is now persistent through bot lives.
• Finalizer Documentation
  • "Finally" added Finalizer documentation...
• The Curvature of Komada
  • You can sub-categorize all pieces in Komada.
• Duration, Stopwatch and Timestamp classes
  • Three new classes to do simple things around the framework.
  • Duration turns time into a human-readable format to indicate how long something has passed. (such as that used in the stats command)
  • Stopwatch is a port from Klasa that gives you better control over node's perf_hooks
  • Timestamp turns time into a timestamp, such as that used in the CommandLogs.

Updated Things

• ArgumentParsing has been slightly changed, although this is subject to change.
• Loader has been completely refactored.
• Reload/Disable/Enable Command

(If Applicable) What Issue does it fix?

Makes Komada Great Again.

Version of Komada

0.21.1

Are core files modified?

Nope

Describe the problem

When I try the help command it says
"":x: | You have DMs disabled, I couldn't send you the commands in DMs."
but if i try eval message.author.send(something) is working
and is working to send messages to the bot too
I have like 45 commands + System commands

Expected Behaviour

To be sending me all the commands

Actual Behaviour

It sends me nothing

Steps to Reproduce.

I used help
didn't work
i used eval message.author.send(something)
worked
i messaged the bot
worked
i used help again
didn't work

Version of Komada

0.21.1

Are core files modified?

No

Describe the problem

...\node_modules\komada\src\classes\argResolver.js:32
async msg(arg, currentUsage, possible, repeat, msg) {
^^^

SyntaxError: Unexpected identifier
at createScript (vm.js:56:10)
at Object.runInThisContext (vm.js:97:10)
at Module._compile (module.js:542:28)
at Object.Module._extensions..js (module.js:579:10)
at Module.load (module.js:487:32)
at tryModuleLoad (module.js:446:12)
at Function.Module._load (module.js:438:3)
at Module.require (module.js:497:17)
at require (internal/module.js:20:19)
at Object. (...\node_modules\komada\src\index.js:2:16)

Expected Behaviour

To not be an error

Actual Behaviour

Is an error

Steps to Reproduce.

I just reinstalled komada after a long time, and appears that :<

https://www.npmjs.com/package/fs-extra-promise

Change all fs methods To use promisified ASYNC

Special message processors that are executed upon each message. Few examples:

• Profanity Filter
• Levels (think Mee6 levels, ugh)
• Spam Detection
• Blacklists
• etc

The processor should be a single function, and should return "false" if it's deemed that the command handler should stop processing (aka commands should not be executed). For instance the Blacklist would return false if an ID is blacklisted and should be ignored.

Database modules for various types of databases:

• JSON (flatfile)
• SQLite
• LocalStorage
• pgsql
• mysql
• etc

Each module would need to have specific functions, to be compatible:

• Init function (create db/tables, temp files, etc)
• Config (DB config especially, user/pass, etc)
• Table management (add, remove, reset, etc)
• Row management (add, remove, reset, update, etc)
• unload

Version of Komada

0.18.10, but it's present since years ago.

Are core files modified?

No

Describe the problem

1.- Usage

When a command uses the mention type in usage, and the user doesn't mention the user, it prints this message:

[2017-03-26 12:24:45] TypeError: Cannot read property '0' of null
    at validateArgs (/mnt/c/Users/manue/node_modules/komada/functions/usage.js:103:82)
    at Promise (/mnt/c/Users/manue/node_modules/komada/functions/usage.js:580:4)
    at Object.exports.run (/mnt/c/Users/manue/node_modules/komada/functions/usage.js:9:55)
    at Object.module.exports [as handleCommand] (/mnt/c/Users/manue/functions/handleCommand.js:11:45)
    at client.on (/mnt/c/Users/manue/node_modules/komada/app.js:79:18)
    at process._tickCallback (internal/process/next_tick.js:103:7)

2.- Boolean validator

Another thing in usage.js (L116-L121), it's validating if the argument is false, but not when it's true.

if (args[i] === "true") {
  args[i] = true;
} else {
  args[i] = false;
  validateArgs(++i);
}

3.- Awaitmessage

Also, now that we are here, add if (message.deletable) in L25 from awaitMessage, if you delete the message before it gets deleted, or komada couldn't send the message, it'll print this:

Uncaught Promise Error:
TypeError: message.delete is not a function
    at module.exports (/mnt/c/Users/manue/node_modules/komada/functions/awaitMessage.js:25:19)

4.- Commands

Also, I know that it's hard to catch, but if the bot has permissions to read a channel, but not to send a message into it, for example, the command ping:

[2017-03-26 12:17:55] Error: Forbidden
    at Request.callback (/mnt/c/Users/manue/node_modules/superagent/lib/node/index.js:675:11)
    at /mnt/c/Users/manue/node_modules/superagent/lib/node/index.js:883:18
    at Stream.<anonymous> (/mnt/c/Users/manue/node_modules/superagent/lib/node/parsers/json.js:16:7)
    at emitNone (events.js:86:13)
    at Stream.emit (events.js:186:7)
    at Unzip.<anonymous> (/mnt/c/Users/manue/node_modules/superagent/lib/node/unzip.js:53:12)
    at emitNone (events.js:91:20)
    at Unzip.emit (events.js:186:7)
    at endReadableNT (_stream_readable.js:974:12)
    at _combinedTickCallback (internal/process/next_tick.js:74:11)
    at process._tickCallback (internal/process/next_tick.js:98:9)
Uncaught Promise Error:
TypeError: Cannot read property 'edit' of undefined
    at exports.run (/mnt/c/Users/manue/commands/System/ping.js:3:10)
    at process._tickCallback (internal/process/next_tick.js:103:7)

Should check if the message is editable before "trying" to edit it.

Expected Behaviour

1.- Usage

Should run this line (L111) in case of mention type. I have checked the code and might be reproduceable for member. Since in /\d+/.exec(args[i])[0], when there's no number, you're trying to read the property [0] of null.

return reject(client.funcs.newError(`${currentUsage.possibles[0].name} must be a mention or valid user id.`, 1, args));

2.- Boolean validator

It should validate if the argument is either true or false, currently it does only for false.

3.- Awaitmessage

Should verify if the message was sent and is editable, instead of trying to edit it.

4.- Commands

Previously check if the command requires SEND_MESSAGES permissions before trying to run it. In conf.botPerms, maybe?

Actual Behaviour

Everything explained above.

Steps to Reproduce.

¯\_(ツ)_/¯

Dev Usage Only
Issue Workflow

• Usage
• Boolean Validator
• Await Message
• Commands

Version of Komada

0.18.5#indev

Are core files modified?

No, happens to Komada Bot too.

Describe the problem

When you execute the help command, unless you're the owner of the bot, it doesn't work.
Error STATUS 400: Bad request: Cannot send an empty message. It happens ONLY when GuildMember.permLevel (using Utils/Extendables) is 0, or DMs the command help as user.permLevel = 0.

Expected Behaviour

Send the commands to DMs.

Actual Behaviour

Notifies the user that the commands have been send to DMs, however, it doesn't send any message, just print "Bad Request" on console (with depth null).

Steps to Reproduce.

Install komada Indev v0.18.5, execute the help command being member.permLevel == 0 (works with higher permLevel).

Version of Komada

0.18.1

Are core files modified?

No

Describe the problem

When trying to specify a user ID for a command using a user parameter, the user has to exist in the guild or Komada fails to pass a user object to the command.

Expected Behaviour

When using a command that takes a user parameter, if the user does not exist in the guild, Komada will find the user and still return a user object to the command.

Actual Behaviour

Komada returns a null user object to the command if the user does not exist in the guild.

Steps to Reproduce.

Komada used to return user objects to the command even if the user was not in the guild. But it suddenly stopped doing that after I ran a custom function that scanned a bunch of user IDs from a MariaDB database and updated the database to include their username and discriminator. I was utilising Discord.js 11.1 client.FetchUser to do this.

Version 4.7.0 of eslint just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As eslint is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

Version of Komada

0.20.8

Are core files modified?

No

Describe the problem

It's not possible to use the updateArray function with SettingGateway instances initialized with a type other than guild

Expected Behaviour

updateArray should update arrays in SettingGateway instances based on all types

Actual Behaviour

updateArray throws an error and fails to update arrays on SettingGateway instances other than ones based on guild types

Steps to Reproduce.

• Create a new SettingGateway instance based on other type (eg: User) with an array key in the schema
• Create an entry with an object of your SettingGateway instance type
• Use updateArray to try to modify the array key

Ability to create event handler functions, added to /handlers/event-name.js.

The files should be named the same way as the event, to be automatically loaded. So for example /handlers/guildMemberAdd.js would handle new guild members and react accordingly.

Version of Komada

github:dirigeants/komada#indev

Are core files modified?

No, not until I added a space to fix this issue.

Describe the problem

The color highlighting on the help messages that arrive in the DM can be affected by the prefix. For example by using the . prefix it changes the entire color to Blue instead of the awesome Blue and Orange. Changing the prefix to , or / solves this issue but that forces users to use a specific prefix. I would suggest adding a space to the help.

Problem: https://cdn.discordapp.com/attachments/339948384368721921/348868699165556746/unknown.png

Suggestion: https://cdn.discordapp.com/attachments/342436526380154881/348924110941847553/unknown.png

Steps to Reproduce.

Set prefix to . and type .help

Version of Komada

0.19.0

Are core files modified?

functions/usage.js

Describe the problem

Attempting to run Komada results in a client.funcs.log is not a function error

Expected Behaviour

Komada boots and operates normally.

Actual Behaviour

Komada crashes with this error:
You have triggered an unhandledRejection, you may have forgotten to catch a Promise rejection:
TypeError: client.funcs.log is not a function
at Promise.all.catch.e (/root/discordjs/lovinibot/node_modules/komada/utils/loadFunctions.js:18:51)
Uncaught Promise Error:
TypeError: client.funcs.log is not a function
at Promise.all.catch.e (/root/discordjs/lovinibot/node_modules/komada/utils/loadFunctions.js:18:51)

Steps to Reproduce.

A small improvement to the Help command would be to filter returned commands to only the ones the Member can execute.

Version of Komada

Latest Komada#master

Are core files modified?

Only the help command to add a ${prefix} space in the beginning so the asiidoc colors work and dont get ruined by the prefix.

Describe the problem

CommandLogger doesnt log any commands when enabled in the config.json file.

Expected Behaviour

Log the commands as described in docs.

Actual Behaviour

None

Steps to Reproduce.

Edit json file to have it enabled -> use a command

"cmdLogging": true,

Version of Komada

github:dirigeants/komada#indev

Are core files modified?

No

Describe the problem

It isn't really a problem but would be an awesome feature to add on. Right now i have about 5 function files. I am in need of creating a new function file but this new function will require calling one of those previous 5 functions. However, if the new function loads before the older functions then it wont work at all. It would be nice to have a way to require functions similar to how in commands exports.conf you can require certain functions.

Expected Behaviour

A function that requires other functions don't load before other functions.

Potentially update Komada Core to use Node 7 Async/Await.

Version of Komada

v0.18.1

Are core files modified?

No

Describe the problem

The ready.js event is executed before komada is even finished loading all of the other components, such as the functions.

Expected Behaviour

Komada loads all available components, such as events, functions, commands, monitors, and so on, and THEN executes ready.js event if exists once everything is loaded and Discord is connected to. That way, a required database.js function is loaded, which ready.js uses to prune out banned users who snuck in the guild when the bot was offline.

Actual Behaviour

Komada loads all event handlers, then executes ready.js, then loads the rest of the components like commands, functions, and so on. This causes the bot to error because my ready.js needs the database.js function to prune banned users.

Dirty workaround

For anyone else who may have this issue, I set my user pruning functions inside a 15 second setTimeout to give the bot 15 seconds to load the rest of the components before pruning. This is not supposed to be a production fix though (sometimes the bot may take more than 15 seconds).

Steps to Reproduce.

My explanations above should answer this question easily.

As you can see by the screenshot above, when I try to pin a message that was posted BEFORE the bot was rebooted AFTER said bot rebooted, it cannot fetch the message.

Version of Komada

0.19.0

Are core files modified?

Only a couple, but nothing that interferes with permissionLevel.js

Describe the problem

permissionLevel.js returns the wrong number for permissions.

Expected Behaviour

permissionLevel.js returns 10 for bot owner, 4 for guild owner, 3 for adminRole user, 2 for modRole user, 0 for everyone else.

Actual Behaviour

permissionLevel.js ignores admins, mods, and guild owners; only returns 10 for bot owner or 0 for everyone else.

Steps to Reproduce.

Using a command which accesses msg.author.permLevel.

Some way to enable or disable a command.

First pass: temporary until reboot.

Second pass: saved per server

Add basic permission system determined by a custom numbering system, can be personalized by the user (default: will look at roles "mod" and "admin" or something).