search

SebastiaanYN / Open-SourceBot

An open source Discord bot created and run by TheSourceCode community.
http://open.sourcebot.net
MIT License
74 stars 78 forks source link

Features #3

Open SebastiaanYN opened 5 years ago

SebastiaanYN commented 5 years ago

Let's discuss the bot features here.

Provide as much information as possible, so we can get a good understanding of the ideas and opinions.

anishshobithps commented 5 years ago

Well speaking of commands i can say

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

SebastiaanYN commented 5 years ago

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.

anishshobithps commented 5 years ago

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

anishshobithps commented 5 years ago

Maybe something like starboard too ?

might be any commands

SacredAI commented 5 years ago

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

Mas03 commented 5 years ago

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.

anishshobithps commented 5 years ago

Canvas might be a issue if JavaScript comes .... you may try jimp in that case...

SebastiaanYN commented 5 years ago

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.

TheForbiddenAi commented 5 years ago

All features should be able to be disabled/enabled

anishshobithps commented 5 years ago

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

ramidzkh commented 5 years ago

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:

SebastiaanYN commented 5 years ago

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.

Solaris9 commented 5 years ago

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.

SebastiaanYN commented 5 years ago

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

anishshobithps commented 5 years ago

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

SleepySwords commented 5 years ago

If we are using js, should we make it a class based bot?

ramidzkh commented 5 years ago

If we are using js, should we make it a class based bot?

Everything should be in a modular design, no matter what language

SleepySwords commented 5 years ago

Now I kinda want to use typescript

devan-mysterio commented 5 years ago

If we are using JDA, use maven, ALSO add a neat economy with shop and neat stuff

Mas03 commented 5 years ago

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.

TheForbiddenAi commented 5 years ago

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

clayjens commented 5 years ago

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.

anishshobithps commented 5 years ago

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 😕

antocs commented 5 years ago

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

TheForbiddenAi commented 5 years ago

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

acollierr17 commented 5 years ago

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.

SebastiaanYN commented 5 years ago

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.

SacredAI commented 5 years ago

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

acollierr17 commented 5 years ago

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.

anishshobithps commented 5 years ago

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

acollierr17 commented 5 years ago

I think it would make the most since to focus on one branch for the time being. That being the stable branch. I'm more than certain this project will slowly move towards master as we progress. People are free to fork and work on master, but the project's main focus will probably be on the stable branch.

On Tue, Mar 12, 2019, 07:23 ExTrEmE HeRo notifications@github.com wrote:

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 🤷‍♂️ so i will add a reaction with 👍 and 👎 react accordingly what you guys think

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/The-SourceCode/Open-SourceBot/issues/3#issuecomment-471961076, or mute the thread https://github.com/notifications/unsubscribe-auth/AP0M0UvnBbTHocooc10dYvTTKjMJDN4Zks5vV45DgaJpZM4bnbXW .

SleepySwords commented 5 years ago

So are we using ts or just js

Fallenthetaco commented 5 years ago

He just said we're doing discord.js. So I assume we're doing js

Andy724 commented 5 years ago

Discord.js has TypeScript typings, so either would work. Using TypeScript could make the bot easier to maintain though.

SebastiaanYN commented 5 years ago

The bot will be in JavaScript, not TypeScript.

SebastiaanYN commented 5 years ago

Add a point system

Could you elaborate?

anishshobithps commented 5 years ago

Ehh not mysql

SebastiaanYN commented 5 years ago

Like MySQL point system for the chat

You mean that you can talk to get experience and levels? And then with possible role rewards?

Jacxk commented 5 years ago

We could also add commands like to make polls and giveaways using reactions, and save those in a database maybe so we can see (if we wanted) the pasts giveaways and polls.

antocs commented 5 years ago

Maybe make a to-do list in the README, or a TO-DO.md with the features to do / accepted, so that if somebody wants to commit something, he knows what to do

anishshobithps commented 5 years ago

Use Projects on the github repo so all the todo stuff like above would be monitored by everyone and they can proceed accordingly

SebastiaanYN commented 5 years ago

When work on the actual features start we'll start creating a list for them

VoxelMC commented 5 years ago

When work on the actual features start we'll start creating a list for them

@SebastiaanYN I'd like to help work on the actual features, what do I need to know?

SebastiaanYN commented 5 years ago

@VoxelMC development is currently very slow, if not halted. I'm waiting for @DarkSeraphim to review some pull requests.

VoxelMC commented 5 years ago

@VoxelMC development is currently very slow, if not halted. I'm waiting for @DarkSeraphim to review some pull requests.

@SebastiaanYN is there anything in particular that I could work on in the meantime? like a command or something like that??