search

RSA-Internal / PandaProtector

1 stars 2 forks source link

Separate guild functionality #78

Open TinyPandas opened 3 years ago

TinyPandas commented 3 years ago

o.o

everything only works for one guild atm.. (might only be relevant to one or two extra guilds, but why be exclusive if OS?)

cntkillme commented 3 years ago

I agree completely and we should definitely do this, but I'm unsure how to actually get a channel without having a message being sent or some other way that gives us a reference to the current guild.

TinyPandas commented 3 years ago

Everything would remain the same, we just need to handle different config.json for each server. This is where mongo might come in handy, if we convert to a Model based on config. We would have to fetch the config on first call without, then cache.

cntkillme commented 3 years ago

Each server already can have its own config.json, unless I'm misunderstanding what you mean

TinyPandas commented 3 years ago

Sure, if they host their own implementation of the bot. However, what I'm referring to is if they add the bot to their guild as we host it. For example: I wanted to add it not only in the live server, but also the test server. This would not work due to having a global config.

cntkillme commented 3 years ago

Okay if we plan on going forward with this some time in the future (not sure if we should, since this bot is highly guild-specific with things like the showcase channel and eventually gamejam features):

  1. setState/getState in store/state.ts needs to be parameterized by guildId, and guild-specific config must be saved somewhere (file, db, something else?).
  2. Global config (e.g., debugChannelId) should not be part of guild-specific config.
  3. Determine how to properly horizontally scale (e.g., how many mongo connections per shard, etc.).
  4. Throttle command usage and cache the results of various expensive operations.