Open-SourceBot
Open-SourceBot copied to clipboard
SebastiaanYN
Features
Let's discuss the bot features here.
- Which commands would you want to have in the bot?
- Should the bot be designed to work on one guild, or multiple?
Provide as much information as possible, so we can get a good understanding of the ideas and opinions.
Well speaking of commands i can say
- [x] Moderation
- [x] Music [this is what most of them ask for]
- [x] General commands
- [x] Developer commands
- [x] Game stats
- [ ] Canvas stuff maybe [I opted out on purpose] //Might have issues if its in javascript or maybe use jimp
And the Second thing would be good if its multiple guilds it would support both single and multiple guilds
For music i really dont know but i would prefer lavalink over ytdl-core atleast in that case java devs would be of a great help lol
Well speaking of commands i can say
- [x] Moderation
- [x] Music [this is what most of them ask for]
- [x] General commands
- [x] Developer commands
- [x] Game stats
- [ ] Canvas stuff maybe [I opted out on purpose] //Might have issues if its in javascript or maybe use jimp
And the Second thing would be good if its multiple guilds it would support both single and multiple guilds
For music i really dont know but i would prefer lavalink over ytdl-core atleast in that case java devs would be of a great help lol
These are good categories. Let's go into more detail on which commands exactly should be added, and which category they should fall under.
Well speaking of commands i can say
- [x] Moderation
- [x] Music [this is what most of them ask for]
- [x] General commands
- [x] Developer commands
- [x] Game stats
- [ ] Canvas stuff maybe [I opted out on purpose] //Might have issues if its in javascript or maybe use jimp
And the Second thing would be good if its multiple guilds it would support both single and multiple guilds For music i really dont know but i would prefer lavalink over ytdl-core atleast in that case java devs would be of a great help lol
These are good categories. Let's go into more detail on which commands exactly should be added, and which category they should fall under.
well so
Moderation
> Ban> Kick
> Mute
> Softban
> Unmute
> Unban
Music
> Play> Pause
> Queue
> Now Playing
> Remove
> Skip
> Auto Play
> Resume
> Loop
> Search
General Commands
> Help> Ping
> Botinfo
> Serverinfo
> Emojis
> userinfo
Developer Commands
> Eval> Exec
> Reload
> Reboot
> Shutdown
i dont have much idea of game stats and canvas but for canvas i have api which does image manipulation created by my friend and i have contributed to its project will share it later on
As much as i Could i have put into thing you can modify these commands given by me or add them more
Maybe something like starboard too ?
- [x] Custom Commands
- [x] Fun commands
might be any commands
-
Moderation Kick, Ban, TempBan, Soft Ban, Unban, Mute, TempMute, Kick, Warn, unwarn, Purge, Report System, History to see your punishment history all with an incident system like Source
-
General Coin system, Gambling, Bot and server info, Online command like Source but for server only, Rank/XP System, Pay (If you do the coins), a leaderboard for xp and coins, A shop thingy maybe?
-
Developer Query the docs commands, OTher shit maybe?
-
Music With queue system etc self-explanatory
-
Game States Ping apis with your username for your stats
-
Fun Starboard, 8ball, bunch of random shit really
-
Custom Community Driven created as they ask for it
Edit: I thought of more SHit Designed for multiple Servers but can work on 1 etc dependent on the amount of servers Bot is in.
Automate Actions E.G Reporting advertising in status, deleting invites unless they are above a certain rank/ invite is to the server
Basics of a web dashboard maybe?
Auto role assigning
reminders, announcements lotsss of shit
As of this moment, this new open source bot will not have moderation (at least on {TSC})
I think anything we do have is modular and can be enabled / disabled. Either through command or potential website. #NewMee6
As to features?
Welcoming & Leaving - Using Canvas - Login Verification - Random character generation Moderation - The generic commands - Ban, Kick, Mute, Role Management (includes reaction based roles) Music - Could be an issue depending on host. Development - If we were to have eval, make it modular like every command (seb I know you want this. So lets compromise) :P, Docs commands - Perhaps scrape more than just Spigot, JDA, Java, Discord.JS, and JS. Perhaps HTML, CSS, PHP, C#, Python (if applicable) Automated Actions - Modular - Reports advertising in status, links being sent, anti-spam & swearword filter. Economy - Modular - coins, shops, boosters, administration commands to set coins, boosters etc (This is for server admins when they're is a bug and stats could be wiped or anything.)
Anything else I think of I will edit into this message.
Canvas might be a issue if JavaScript comes .... you may try jimp in that case...
I think it might be a good idea to use Docker. That would solve most issues related to bindings, since everything would just be ran in a linux environment.
I think it might be a good idea to use Docker. That would solve most issues related to bindings, since everything would just be ran in a linux environment.
well if you are referring to me ... there might be some people who might wanna test the bot on a windows system which would throw errors in case of canvas
I think it might be a good idea to use Docker. That would solve most issues related to bindings, since everything would just be ran in a linux environment.
well if you are referring to me ... there might be some people who might wanna test the bot on a windows system which would throw errors in case of canvas
Figure out how to install MSVC then. The bot will (probably) be ran on a Linux based system so that needs the most testing on.
All features should be able to be disabled/enabled
Make everything like a toggleable module, Exe's architecture :wink:
I think it might be a good idea to use Docker. That would solve most issues related to bindings, since everything would just be ran in a linux environment.
well if you are referring to me ... there might be some people who might wanna test the bot on a windows system which would throw errors in case of canvas
That's exactly what Docker is for. It creates an environment that will always be the same. It uses a VM on Windows to run the linux environments, which means that everyone can run each part of the bot while only needing docker.
Canvas might be a issue if JavaScript comes .... you may try jimp in that case...
I agree that Jimp should be used instead of Canvas, because it doesn't require python or node-gyp. And because node-gyp can be troublesome to install.
Canvas might be a issue if JavaScript comes .... you may try jimp in that case...
I agree that Jimp should be used instead of Canvas, because it doesn't require python or node-gyp. And because node-gyp can be troublesome to install.
Using Docker would solve this entirely. Making both equal options
well i don't have any issues if its canvas or jimp 🤷♂️ ... because i have fixed my node-gyp errors 😄
but if you still wanna use canvas then you may try canvas@next which worked for me when i had node-gyp errors too
If we are using js, should we make it a class based bot?
Everything should be in a modular design, no matter what language
If we are using JDA, use maven, ALSO add a neat economy with shop and neat stuff
If we are using JDA, use maven, ALSO add a neat economy with shop and neat stuff
JDA will not be used unfortunately. It has been voted by the community to use D.JS and that is what will be used.
If we are using JDA, use maven, ALSO add a neat economy with shop and neat stuff
JDA will not be used unfortunately. It has been voted by the community to use D.JS and that is what will be used.
The poll hasn't ended yet
Since the bot is obviously open source, I believe that each aspect of the code should be highly documented on it's purpose, features, and usage as well as following ES6 (assuming JavaScript) Syntax Rules to the best of the contributor's abilities and/or the usage of Repo-specific style guides. This being said, there should be a concise template to follow to write this documentation so no confusion is birthed between contributions, as well as the necessity for each contribution to highly monitored for the best performance and syntax usage.
Starting off, features should be the basics: moderation and economy, with more being implemented by the contributors. I believe this will create the foundation for expected cleanliness of the code as well as the most sought-after aspects of every other bot. As for database, I assume this will become a hassle due to users who fork the repo not having access to the database. I'm sure there is a way around this.
The bot should work on all guilds, not just specific guilds. This way code is compatible with users who wish to fork the repo and test the bot for themselves, but also should not be posted on bot sites, nor allowed to be added to other users guilds. Users who wish to add the bot to their guild can use the code provided here but using their own token. To me this feels more secure.*
Since the bot is presumably going to be written in JavaScript I highly recommend keeping the repo up-to-date on the latest Discord.js version as well as making sure there is no outdated code.
As stated by Functional/Ramid:
Everything should be in a modular design, no matter what language
The bot should use a command handler, obviously, but should also use the modules like cogs in Discord.py. This will allow hotloading of commands by moderators+ if an error is occurred.
*Rethinking, this may lead to users copying code and repurposing it into their own bot, possibly allowing them to profit if they make paid bots. This is the problem with open source. My thoughts still stand, but let me know your ideas on the matter.
If more should be added or something to be changed, let me know.
Well speaking of discord.js latest version is it gonna be master or stable... 🤔 Most of them might do stable is what i am guessing 😕
For the less smarts, when you go in doing the various files, DJS or JDA whatever it wins, make comments on every line, or almost every line, explaining what that does, #prayfordiscord-bot-help
Since the bot is obviously open source, I believe that each aspect of the code should be highly documented on it's purpose, features, and usage as well as following ES6 (assuming JavaScript) Syntax Rules to the best of the contributor's abilities and/or the usage of Repo-specific style guides. This being said, there should be a concise template to follow to write this documentation so no confusion is birthed between contributions, as well as the necessity for each contribution to highly monitored for the best performance and syntax usage.
Starting off, features should be the basics: moderation and economy, with more being implemented by the contributors. I believe this will create the foundation for expected cleanliness of the code as well as the most sought-after aspects of every other bot. As for database, I assume this will become a hassle due to users who fork the repo not having access to the database. I'm sure there is a way around this.
The bot should work on all guilds, not just specific guilds. This way code is compatible with users who wish to fork the repo and test the bot for themselves, but also should not be posted on bot sites, nor allowed to be added to other users guilds. Users who wish to add the bot to their guild can use the code provided here but using their own token. To me this feels more secure.*
Since the bot is presumably going to be written in JavaScript I highly recommend keeping the repo up-to-date on the latest Discord.js version as well as making sure there is no outdated code.
As stated by Functional/Ramid:
Everything should be in a modular design, no matter what language
The bot should use a command handler, obviously, but should also use the modules like cogs in Discord.py. This will allow hotloading of commands by moderators+ if an error is occurred.
*Rethinking, this may lead to users copying code and repurposing it into their own bot, possibly allowing them to profit if they make paid bots. This is the problem with open source. My thoughts still stand, but let me know your ideas on the matter.
If more should be added or something to be changed, let me know.
We will not accept any PR's with undocumented code
Well speaking of discord.js latest version is it gonna be master or stable... 🤔 Most of them might do stable is what i am guessing 😕
I think the bot should be using the master branch going forward. Stable isn't going to be the norm that much longer to be honest. I know a few people and frameworks as well that are built on top of master. I even plan on updating my bots to master in the next month or so.
I think the bot should be using the master branch going forward.
I disagree, I think we should be using stable throughout the lifecycle. When d.js receives an update it can slowly be moved towards the new version.
Stable Makes sense for an open source bot because as seb said we will likely need other frameworks and things can break between versions so a stable and development branch will simply make things easier to manage and less likely to break
Stable Makes sense for an open source bot because as seb said we will likely need other frameworks and things can break between versions so a stable and development branch will simply make things easier to manage and less likely to break
That is a fair point. I'm thinking how things could play out in the future, but with the possibility of other frameworks and such conflicting with master, it's fair to wait.
Stable Makes sense for an open source bot because as seb said we will likely need other frameworks and things can break between versions so a stable and development branch will simply make things easier to manage and less likely to break
That is a fair point. I'm thinking how things could play out in the future, but with the possibility of other frameworks and such conflicting with master, it's fair to wait.
Well to be honest this might sound little more of work why not make two branches the main branches will be focused on stable build and there will be a another branch which will be built with master so when master comes out we can directly merge with the stable and lets make sure that the updates we are doing on stable will be on master too at the same time... I surely know its more and its very hard to do this stuff but this is just a suggestion :man_shrugging: so i will add a reaction with :+1: and :-1: react accordingly what you guys think