ghost-discord / ghost Goto Github PK

The API system for Watch2Gether has been updated:
API documentation

1. The property name needs to be changed.
2. It's now possible for the bot host to get his/her own API key. The default one can be removed but it might be useful to improve the documentation on this.

The changes to the code need to be done in a month or so.

Aliases are included in ModuleInfo and are fully configurable, but none are set up and CommandRegistry ignores them when searching by name.

@cbryant02 mentioned exposing a REST API for the GUI wrapper to work through. I'd be happy to take a crack at this if given a little direction/place to start/some basic requirements, since I'm not terribly familiar with the code base beyond what I've contributed in command modules.

Heroku dynos have ephemeral filesystems, meaning the H2 database gets deleted on Dyno restart. This obviously isn't ideal.

Fortunately, Heroku has a few choices for persistent RDBMS; it's just a matter of adding support for non-H2 persistence solutions.

Being able to load modules externally (i.e. from a folder next to the .jar) would be a great extension of the module system. Theoretically, implementing this shouldn't be terribly hard with the way that module loading and invocation works right now; at the very least, we'd have to make moduleClasses in CommandRegistry a class-level member and add a tryLoadModule() method. Dynamically loading and unloading module files at runtime would easily be possible with the NIO WatchService API.

Logging needs to be increased project-wide. Simple issue, long-term effort. Any new code should log where possible and reasonable.

Thankfully, TinyLog makes logging integration pretty easy (see org.pmw.tinylog.Logger), and the configuration code is already in the project.

Problem

Using Discord's permissions alone is really confusing from the end user's standpoint and doesn't offer enough fine-grained control over what the bot and/or guild members can do. I'd like to propose a new permissions system, and will be developing the idea more over time.

First steps and core ideas

These aren't necessarily in any sort of order.

• Completely do away with the use of Discord permissions in module declarations.
  I think we can probably find a way to deal with these upstream, but I haven't experimented enough with how Discord4J handles "insufficient permissions" errors.
• Offer a small set of clearly-named "access levels" that gradually offer access to more commands as you "climb the ladder"
• Implement a way to attach these access levels to certain roles and/or groups of roles
• Provide a clear, clutter-free interface for managing access levels and delegating commands
• Develop a system for storing these settings to the persistence layer

Is your feature request related to a problem? If so, describe or link to the issue.
When I wrote my contribution, I had to reach out to @cbryant02 to find out the command prefix because the wiki did not mention what it was.
Describe the solution you'd like
I'd like to see a basic guide on using Ghost2 added to the wiki, even just a single paragraph.

Note: this is in response to a card in the "to do" category in ghost2's project page that suggests building a GUI.

I also think there should be a GUI wrapper for the less tech-savvy, but I think this wrapper should be developed independently. In keeping with the Unix philosophy, we should

"Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features".

For example, a lot of Unix CLI tools that are somewhat complicated to use have had GUI wrappers built for them, sometimes many different ones. For example,ffmpeg, a video editing CLI tool, has at least seven different GUIs.

As a GUI wrapper will necessarily drag in more dependencies (at least JavaFX, for a Java project) and more complexity (testing with JavaFX isn't always easy), I think a GUI wrapper should live in a completely different repository. This will also:

• enable users to run ghost2 on a headless server (I'm fairly certain it would run well on a Raspberry Pi or the like);
• allow a GUI to be built in another language (I know for example that recent JavaFX builds don't support ARM platforms); and
• allow for native interfaces.

So on top of proposing that the GUI wrapper be completely independent from this repo, I think its development should also be delayed until the release of 1.0.

As it stands, Command implementations simply call super(String) to set their own name; CommandDispatcher uses that name to match commands in chat to the appropriate class, then calls Command#invoke on it.

The issue with this is that command names are only accessible via instance, so we have to instantiate an instance of each Command subclass to check their names. CommandRegistry is the current solution to this.

Ideally, Command should make its name statically accessible, but I'm not sure how to go about setting the name statically from each subclass elegantly & enforcably.

Describe the bug

Trying to access Ghost2Application.getApplicationInstance().getConfig() in a module's field or initializer block will throw a NullPointerException and cause the module to not get loaded, and output:

ERROR: Module subclass com.github.coleb1911.ghost2.commands.modules.XXXX is written incorrectly. Refer to the wiki for help. (Reason(s): Module threw an exception in its constructor. java.lang.NullPointerException)

This error is difficult to debug, since it has no line number attached and since it doesn't necessarily come from the module's constructor. It can also come from a field or an initializer block.

Reproduction
Steps to reproduce the bug.

1. Create a module
2. Access Ghost2Application.getApplicationInstance().getConfig() before the invoke method is called (for example in the initializer block, field or constructor).
3. Query the bot on Discord for the relevant command.
4. The bot will not respond, and the console will show above message.

Expected behavior
The system properties should be accessible during creation of the module, for example if one wants to store them in final fields. The current API design doesn't warn against it or prevent it, and leads to potential bugs.

Actual behavior
Ghost2Application.getApplicationInstance() returns null if called before invoke method.

Platform

• OS: Linux (Ubuntu 16.04)
• 60552b2

Note: this has been moved from #19. See the final post there for some important info.

All items not checked off of this list are open for contribution - feel free to open a PR for any of them!

Fun

• 8ball
• Image manipulation
  • deepfry
  • jpegify
  • optimize
  • imagesearch - find similar images on Google
  • sharpen
  • blur
  • grayscale
• watch2gether - create a watch2gether room
• urbandictionary
• wikipedia
• xkcd
• chess
• tictactoe
• rockpaperscissors / rps

Moderation

• softban [user]
• warn [user] [reason]
• chatlogs [user]
• Add filtering (user, content type, text, etc.) to purge

Utility

• calc [expression]
• graph [expression]
• translate [to] [text] [from]
• dictionary [word]
• compile [source] - compile (NOT execute) a source file
  • javac
  • gcc / g++
  • pyc
• hexdump [file] - print raw hex data for a file (first 1000-ish bytes or output to text file)
• codepoint [character] - find the Unicode codepoint(s) for a character
• isup [host] - check if a host/address is responding
• uptime
• feedback / report
• sed

Other/Unplanned/Possible

• Destiny 2 integration

Apparently there's a way to disable sending embeds via Discord permissions (see this guide), but I'm not aware of which permission is involved.

help and any future commands that use embeds need to recognize when embeds are disabled and provide text-only alternatives to them.

Working branch: music-rework

Currently implemented:

• play
• search
• shuffle
• stop
• join
• leave
• queue
• queueremove / remove / qr

The performance of String.format() is apparently really, really bad. Calls to the method should be replaced with the + operator or a StringBuilder across the project.

Non-self-explanatory items will have a note attached. I'll check items off myself as they're completed.

Operator

• claimoperator
• shutdown

Config

• prefix

Info

• about: bot info - version, frameworks, github, etc.
• invite
• help / h

Moderation

• purge
• kick
• ban
• mute

Utility

• ping
• screenshare

java.activation was removed in Java 11, but Hibernate depends on it, so jlink doesn't work above Java 10.

There's a few options here:

1. Use a different ORM framework & EntityManager
2. Get jlink in 11 to recognize the module from the Java 10 JDK
3. Get jlink to recognize the non-modular Maven artifact (automatic module name is jakarta.activation, will probably need to patch manifest and include in project files/build)

All items not checked off of this list are open for contribution - feel free to open a PR for any of them!

Operator

• restart (on hold, #21)
• update [release/nightly] (on hold, #21)
• exec (maybe non-operator with tons of limitation, doubtful)

Config

• autorole
• confirm - used for manual autorole assignment

Info

• Allow invoking commands via mention

Fun

• 8ball
• Image manipulation
  • Replace ImageJ?
  • deepfry
  • deepdream
  • jpegify
  • optimize
  • imagesearch - find similar images on Google
  • sharpen
  • blur
  • grayscale
• watch2gether - create a watch2gether room
• urbandictionary
• wikipedia
• xkcd

Moderation

• softban [user]
• warn [user] [reason]
• chatlogs [user]
• Add filtering (user, content type, text, etc.) to purge

Music

Done! #25

Utility

• calc [expression]
• graph [expression]
• translate [to] [text] [from]
• dictionary [word]
• compile [source] - compile (NOT execute) a source file
  • javac
  • gcc / g++
  • pyc
• hexdump [file] - print raw hex data for a file (first 1000-ish bytes or output to text file)
• codepoint [character] - find the Unicode codepoint(s) for a character
• isup [host] - check if a host/address is responding
• uptime
• feedback / report
• sed

Other/Unplanned/Possible

• Destiny 2 integration