Add a text flag to not replicate commands from the discord to the server

  • Y'know how people rn have to post a dot and then edit the message, it'd be better if there was a way to natively do that without needing jape tactics

    Ex on discord: "[dnr] My message here", tfm or whatever tf is replacing it would see the "[dnr]" and then wouldn't post the message to the minecraft server

    ピバラ。

  • Neutral. I see where this comes from but it'd defeat the purpose of the bridge. Imo walls of text or anything that disrupts or deviates from the game itself should be the exception.

    TotalFreedom's Executive Community & Marketing Manager

  • Object.

    While I feel like this is a cool idea, from what I've seen with people doing the "jape" with the dot-edit, I only see the use of this function in two places:

    1. To circumvent large walls of text from flooding the in-game chat;
    2. To chat without sending the message to in-game chat because someone in-game should not hear about what you are saying.

    The simpler of the two would be the 2nd use, since it is not the server's responsibility to allow you to talk behind someone's back. If you have a problem with that person, I recommend you go directly towards the person with your issue, or resolve this in your DMs/GCs.

    For the first one, I believe Paldiu has been working on a new Discord bridge alongside the new permission-node-enabled TFM. I suppose with this we should be able to customize it so that it will cut off long messages so that people does not need to do the "jape tactic".

    A brief demo of what that can look like (using the text from The FitnessGram Pacer Test):

    Display Spoiler

    Unprocessed Discord channel message:

    "The FitnessGram™ Pacer Test is a multistage aerobic capacity test that progressively gets more difficult as it continues. The 20 meter pacer test will begin in 30 seconds. Line up at the start. The running speed starts slowly, but gets faster each minute after you hear this signal. [beep] A single lap should be completed each time you hear this sound. [ding] Remember to run in a straight line, and run as long as possible. The second time you fail to complete a lap before the sound, your test is over. The test will begin on the word start. On your mark, get ready, start."

    Processed in-game chat message:

    "The FitnessGram™ Pacer Test is a multistage aerobic capacity test that progressively gets more difficult as it continues. The 20 meter pacer test will begin in 30 seconds. Line up [...]"

    While the exact execution and the cut-off in an ideal scenario would be decided by the community and Paul, I believe that this is a good enough solution to the existing problem.

    One last note that no matter what we "fix", the "jank" is still going to always exist because I don't believe it's feasible to re-send every discord chat message that was ever edited, nor is there any good real-time way to tell in-game chat that a Discord message was edited. I would rather we address the underlying motives of using this unintended feature (or, more commonly put, a bug) instead of "streamlining" it with another intended feature.

    With that said, please let everyone know if there is anything missing that people occasionally use the dot-edit technique with, so the community can address it and talk about it as well.

    C'est la vie

  • There is no "bug" with dot-edit messages. This feature is as intended.
    There are no feasible reasons in which we should be including a filter for individuals so they don't have to dot-edit their messages; it's not that much work to do that, and it would be more work on the development side to implement such a feature.

    I understand the idea and the thought behind it but ultimately, it would be a waste of developer focus when there's plenty of other feature requests that have already been made that would be better off being implemented first.

    • Official Post

    So once we are able to move to a standard plugin this will be mostly native anyway, you can post your long message and it gets pretty aggressively truncated in server so it's not super spammy.

    Wild1145

    Network Owner at TotalFreedom

    Managing Director at ATLAS Media Group Ltd.

    Founder & Owner at MastodonApp.UK

  • So once we are able to move to a standard plugin this will be mostly native anyway, you can post your long message and it gets pretty aggressively truncated in server so it's not super spammy.

    Unfortunately due to the things we currently have in the discord bot and how it communicates with our plugin, a "standard plugin" is not in the realm of possibility. Even if we migrated our admin chat to Network Manager, we will still need to implement our own discord impl to communicate those messages to our discord server. The OTS plugins do not support that kind of communication and only skims readable messages.

    The only way we can get away with using something like EXDiscord or DiscordSRV is if we reduce certain functionalities.

    • Official Post

    So once we are able to move to a standard plugin this will be mostly native anyway, you can post your long message and it gets pretty aggressively truncated in server so it's not super spammy.

    Unfortunately due to the things we currently have in the discord bot and how it communicates with our plugin, a "standard plugin" is not in the realm of possibility. Even if we migrated our admin chat to Network Manager, we will still need to implement our own discord impl to communicate those messages to our discord server. The OTS plugins do not support that kind of communication and only skims readable messages.

    The only way we can get away with using something like EXDiscord or DiscordSRV is if we reduce certain functionalities

    Network Manager have their own plugin for admin / staff chats so DiscordSRV / Essentials Disocrd / Similar would be absolutely fine at that point, it's been tested on the hub and in our plots dev server. The current limitation is TFM.

  • Unfortunately due to the things we currently have in the discord bot and how it communicates with our plugin, a "standard plugin" is not in the realm of possibility. Even if we migrated our admin chat to Network Manager, we will still need to implement our own discord impl to communicate those messages to our discord server. The OTS plugins do not support that kind of communication and only skims readable messages.

    The only way we can get away with using something like EXDiscord or DiscordSRV is if we reduce certain functionalities

    Network Manager have their own plugin for admin / staff chats so DiscordSRV / Essentials Disocrd / Similar would be absolutely fine at that point, it's been tested on the hub and in our plots dev server. The current limitation is TFM.

    I would also like to make the argument that both DiscordSRV and EXDiscord are written using JDA, while the Discord implementation that I've got on the RELEASE-2023.03 branch is written with D4J.
    In most cases, JDA is a fine product and works as intended without issue. However, due to the nature of how MC functions on a performance level, I argue that D4J would be a better option for us. The discord bot I've written for TFM (which is 100% operational) uses this API instead of JDA and I would highly recommend that we keep this even if it's a project maintained exclusively by myself (which is fine by me, I can even release it on spigot if that makes you feel better). Some minor tweaks to it can make it run exclusively standalone, so that isn't a concern either.

    I could write an entire essay on why D4J is a better option for us than JDA alternatives, but I don't think that's necessary. Though, if it is, I will be more than happy to explain exactly why we should use this over the alternatives.

    • Official Post

    Network Manager have their own plugin for admin / staff chats so DiscordSRV / Essentials Disocrd / Similar would be absolutely fine at that point, it's been tested on the hub and in our plots dev server. The current limitation is TFM.

    I would also like to make the argument that both DiscordSRV and EXDiscord are written using JDA, while the Discord implementation that I've got on the RELEASE-2023.03 branch is written with D4J.
    In most cases, JDA is a fine product and works as intended without issue. However, due to the nature of how MC functions on a performance level, I argue that D4J would be a better option for us. The discord bot I've written for TFM (which is 100% operational) uses this API instead of JDA and I would highly recommend that we keep this even if it's a project maintained exclusively by myself (which is fine by me, I can even release it on spigot if that makes you feel better). Some minor tweaks to it can make it run exclusively standalone, so that isn't a concern either.

    I could write an entire essay on why D4J is a better option for us than JDA alternatives, but I don't think that's necessary. Though, if it is, I will be more than happy to explain exactly why we should use this over the alternatives.

    If we can make it it's own stand alone plugin that live on our Github and is maintained and maintainable (Ideally even with tests though that seems to be a novel thing in MC Dev) I'm happy to use basically whatever, I just don't want any special sauce and it needs to be that we could swap it out for DiscordSRV / similar if we had to in the future.

    Wild1145

    Network Owner at TotalFreedom

    Managing Director at ATLAS Media Group Ltd.

    Founder & Owner at MastodonApp.UK

  • I would also like to make the argument that both DiscordSRV and EXDiscord are written using JDA, while the Discord implementation that I've got on the RELEASE-2023.03 branch is written with D4J.
    In most cases, JDA is a fine product and works as intended without issue. However, due to the nature of how MC functions on a performance level, I argue that D4J would be a better option for us. The discord bot I've written for TFM (which is 100% operational) uses this API instead of JDA and I would highly recommend that we keep this even if it's a project maintained exclusively by myself (which is fine by me, I can even release it on spigot if that makes you feel better). Some minor tweaks to it can make it run exclusively standalone, so that isn't a concern either.

    I could write an entire essay on why D4J is a better option for us than JDA alternatives, but I don't think that's necessary. Though, if it is, I will be more than happy to explain exactly why we should use this over the alternatives.

    If we can make it it's own stand alone plugin that live on our Github and is maintained and maintainable (Ideally even with tests though that seems to be a novel thing in MC Dev) I'm happy to use basically whatever, I just don't want any special sauce and it needs to be that we could swap it out for DiscordSRV / similar if we had to in the future.

    That's fine, we can do that. I can also make sure to fully document the entire project to ensure maintainability.