mtasa-blue
mtasa-blue copied to clipboard
Add Discord integration for servers
This PR will allow any server to setup their own discord bots, send messages to discord channels, etc.
Current functions:
bool discordStart ( );
void discordLogin ( string token );
bool discordOnEvent ( discord-event event, function callback );
table discordGetCache ( );
discord-guild discordGetGuild ( string id );
Current discordOnEvent events:
on_voice_state_update
on_voice_client_disconnect
on_voice_client_speaking
on_log ( string message, int severity );
on_guild_join_request_delete
on_interaction_create
on_slashcommand
on_button_click
on_autocomplete
on_select_click
on_message_context_menu
on_user_context_menu
on_form_submit
on_guild_delete
on_channel_delete
on_channel_update
on_ready ( string sessionID, string shardID, table guilds, int guildCount );
on_message_delete
on_guild_member_remove
on_resumed
on_guild_role_create
on_typing_start
on_message_reaction_add
on_guild_members_chunk
on_message_reaction_remove
on_guild_create
on_channel_create
on_message_reaction_remove_emoji
on_message_delete_bulk
on_guild_role_update
on_guild_role_delete
on_channel_pins_update
on_message_reaction_remove_all
on_voice_server_update
on_guild_emojis_update
on_guild_stickers_update
on_presence_update
on_webhooks_update
on_automod_rule_create
on_automod_rule_update
on_automod_rule_delete
on_automod_rule_execute
on_guild_member_add
on_invite_delete
on_guild_update
on_guild_integrations_update
on_guild_member_update
on_invite_create
on_message_update
on_user_update
on_message_create
on_message_poll_vote_add
on_message_poll_vote_remove
on_guild_audit_log_entry_create
on_guild_ban_add
on_guild_ban_remove
on_integration_create
on_integration_update
on_integration_delete
on_thread_create
on_thread_update
on_thread_delete
on_thread_list_sync
on_thread_member_update
on_thread_members_update
on_guild_scheduled_event_create
on_guild_scheduled_event_update
on_guild_scheduled_event_delete
on_guild_scheduled_event_user_add
on_guild_scheduled_event_user_remove
on_voice_buffer_send
on_voice_user_talking
on_voice_ready
on_voice_receive
on_voice_receive_combined
on_voice_track_marker
on_stage_instance_create ( string guildID, string channelID, string topic, string level, bool discoverable );
on_stage_instance_update ( string guildID, string channelID, string topic, string level, bool discoverable );
on_stage_instance_delete ( string guildID, string channelID, string topic, string level, bool discoverable );
on_entitlement_create ( string skuID, string appID, string ownerID, string type, string startsAtTimestamp, string endsAtTimestamp, int flags );
on_entitlement_update ( string skuID, string appID, string ownerID, string type, string startsAtTimestamp, string endsAtTimestamp, int flags );
on_entitlement_delete ( string skuID, string appID, string ownerID, string type, string startsAtTimestamp, string endsAtTimestamp, int flags );
+9999 new functions, +99999 new events, +158,832 lines of code ( to be exact ), +9999% more issues - thats how i imagine introduction of this feature, for what? to get complains from people that discord changed api, and now function X not working or they added new feature that is not supported and now people need to wait half a year to be available, crashes, more crashes, more complains that something not working, tons of code to maintain, just time spent on creating new wiki pages for aal new functionality will be massive.
I know how many functions such libraries has, i use one on my own, discord keep chaning/adding new features, mta can't keep up with updating existing way way way smaller libraries.
Just make better http and socket support and tell people to use node.js/c#/python/brainfuck/zig/fortran/assembly to make their own bot.
Oh and most important: people already are using bots outside mta, they probably won't migrate :)
This is not my favourite physics library that NEEDS to be inside mta to function properly.
i agree with CrosRoad here. This would be a hassle to maintain
i agree with CrosRoad here. This would be a hassle to maintain
Nah, it wouldnt. Its the same as with node or any other discord lib. Users would need to update their bot if breaking changes happen either way.
Updating the bot is easy, but updating this lib in mtasa-blue takes more time and as he said, there's not as big and active of a developer community like js
Why reinvent the wheel when we can use the existing solutions
https://github.com/botder/mtasa-discord-bot
I appreciate your effort in creating this @TracerDS but the existing popular frameworks are already being used by servers and have great and quick updates to them
Updating the bot is easy, but updating this lib in mtasa-blue takes more time and as he said, there's not as big and active of a developer community like js
There is a huge and active community for dpp. It wouldnt take more time. The same time as for other languages even.
https://github.com/botder/mtasa-discord-bot
This is only a webhook and not a bot. Not the same solution. It has limitations and it obviously isnt implemented as native feature
https://github.com/botder/mtasa-discord-bot
This is only a webhook and not a bot. Not the same solution. It has limitations and it obviously isnt implemented as native feature
This is not webhook, this is bot with sockets module
https://github.com/botder/mtasa-discord-bot
This is only a webhook and not a bot. Not the same solution. It has limitations and it obviously isnt implemented as native feature
This is not webhook, this is bot with sockets module
Previous versions used to act just like webhook (no profile, just sending info). Dunno if that changed over time. In any case even when using other languages the same thing will eventually happen. Its just a matter of time. With this PR it will be a native feature without using sockets module and relying purely on the mta itself.
Found 3 more issues:
- only one bot allowed? why not "createDiscordBot(token)"?
- discordOnEvent - why won't you use current event system?
- performance, even if you subscribe for what you need, you can still get in peak like 1/2 events per minute per user, often those events contain a lot of metadata, author, content and so on. If you have 200 people on discord, and 10 on server - you won't notice, but if you have 10000+ people on discord and 200+ players on server in peak where you need cpu time the most, you can lose few % cpu time by processing data you don't need.
Found 3 more issues:
- only one bot allowed? why not "createDiscordBot(token)"?
- discordOnEvent - why won't you use current event system?
- performance, even if you subscribe for what you need, you can still get in peak like 1/2 events per minute per user, often those events contain a lot of metadata, author, content and so on. If you have 200 people on discord, and 10 on server - you won't notice, but if you have 10000+ people on discord and 200+ players on server in peak where you need cpu time the most, you can lose few % cpu time by processing data you don't need.
- Bot is created separately in each resource. That might need some optimizing
- There are lots of discord events. It would pollute the "global event namespace"
- Discord lib already handles critical performance issues. Its as fast as it can get.
https://github.com/botder/mtasa-discord-bot
This is only a webhook and not a bot. Not the same solution. It has limitations and it obviously isnt implemented as native feature
This is not webhook, this is bot with sockets module
Previous versions used to act just like webhook (no profile, just sending info). Dunno if that changed over time. In any case even when using other languages the same thing will eventually happen. Its just a matter of time. With this PR it will be a native feature without using sockets module and relying purely on the mta itself.
As the owner and developer of mtasa-discord-bot I have to disappoint you, because it always used discord.js for sending messages back and forth; and never webhooks. If you need more features in that repo/from Discord API, then fork it and use it via discord.js - it's probably the best Discord API library you can find.
As the owner and developer of mtasa-discord-bot I have to disappoint you, because it always used discord.js for sending messages back and forth; and never webhooks. If you need more features in that repo/from Discord API, then fork it and use it via discord.js - it's probably the best Discord API library you can find.
My bad, thought it offered webhook functionality in the past. Nvm it then.
Either way having a native solution is much better than connecting to external api tbf
your pull request should be just regular resource, thats wy i mentioned to make better socket and http support. I don't want to turn off my server to update discord functions due to update from discord itself
^ i learned that myself when i had discord bot built in server, cool i can just call discord api from inside command directly, but maintenance was the worst
your pull request should be just regular resource, thats wy i mentioned to make better socket and http support. I don't want to turn off my server to update discord functions due to update from discord itself
^ i learned that myself when i had discord bot built in server, cool i can just call discord api from inside command directly, but maintenance was the worst
With how things go these days updates wont be frequent. Why is that a problem?
Updates are not the worst, performance wise it can be bad especially big servers, and why 1 resource = 1 bot? maybe i want 2 bots in one resource? i myself use two bots, one for development, second for production, people may want to do the same, how they are going to do that? loadstring? you know modules are in development hell right now and we won't see them until gta7
Updates are not the worst, performance wise it can be bad especially big servers, and why 1 resource = 1 bot? maybe i want 2 bots in one resource? i myself use two bots, one for development, second for production, people may want to do the same, how they are going to do that? loadstring? you know modules are in development hell right now and we won't see them until gta7
First the discord bot must be ready. Then we can think of making multiple bots per resource
This draft pull request is stale because it has been open for at least 90 days with no activity. Please continue on your draft pull request or it will be closed in 30 days automatically.
Im not interested in advancing this PR further anymore. If someone wants to refresh it, feel free to do so.