ghost-discord / ghost Goto Github PK
View Code? Open in Web Editor NEW๐ค A modular, multi-feature Discord bot
License: GNU General Public License v3.0
๐ค A modular, multi-feature Discord bot
License: GNU General Public License v3.0
All items not checked off of this list are open for contribution - feel free to open a PR for any of them!
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.
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.
Ghost2Application.getApplicationInstance().getConfig()
before the invoke
method is called (for example in the initializer block, field or constructor).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
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.
Aliases are included in ModuleInfo and are fully configurable, but none are set up and CommandRegistry ignores them when searching by name.
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.
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:
jakarta.activation
, will probably need to patch manifest and include in project files/build)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.
These aren't necessarily in any sort of order.
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.
The API system for Watch2Gether has been updated:
API documentation
The changes to the code need to be done in a month or so.
Currently implemented:
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.
All items not checked off of this list are open for contribution - feel free to open a PR for any of them!
Done! #25
Non-self-explanatory items will have a note attached. I'll check items off myself as they're completed.
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:
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.
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.
@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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.