Posts by wild1145

    From 22:30 BST today (GMT+1) we will be increasing the minimum version required to play on the network from 1.18.0 up to 1.19.4.


    This will allow us to bring our hub up to date, and enable me to (If I get time) start working on upgrades to the Skyblock server as well as finally finishing the work to launch the dedicated plots server.


    For most people I don't expect this to cause any issues, but it's something to be aware of none the less.

    Please, for the love of god, just allow the server to be updated relatively fast to the latest version of Minecraft which Scissors has support for

    As a point, I've been pushing for this, however have been told we can't and as TFM development is now abandoned we're likely many months away while code is re-written and tested and assured to production quality.



    Just about every point you made in this post doesn't ring true just for administration on TF, it seems to me like it also rings true for the development of the Minecraft server. Due to the way the pull request system works, there is always one reviewer required in order to merge a pull request. This is, of course, quite logical, considering if this restriction was not in place then it'd be trivial to get developer and merge permissions on TF, make a new branch, add some malicious code, open a pull request, merge it yourself and have malicious code on the development branch for whoever knows how long. This works fine when there's at least 2 active developers, but due to the nature of the developer role on TF, being without an activity requirement, and the terrible build times of TFM and just massive codebase issues, there is often only one active developer who wants to actively improve the codebase of TFM, without anyone to merge these PRs. When your PR is merged into the development, it often takes months for it to be published as a release, or put on the server. A lot of the fun in programming, at least for me, is to see your project actually running in production. Not just to have it approved and merged into the current development revision. I do understand that this is in the interest of stability, and I agree that is of high importance, but this certainly isn't the correct way to do it. It feels similar to the Debian project's stable flavour, which essentially holds back the non-security updates of packages. This, for me, is the reason that I haven't tried to make as many pull requests to TFM as I could've, it's just tiring to write changes and then get them sent into code review purgatory. Not knowing if your changes will be denied, accepted or ever merged into TFM in the first place. Code reviews aren't good when they're never done, and as such actually get in the way of development, instead of actually improving stability and code quality, as they are meant for. Neither is the branch system of TFM.


    In terms of a lot of this, we had originally intended to do monthly releases, but we had no code to deploy most of the time because developers went inactive and didn't feel like it. We do have to ensure we have a stable server because it's caused us huge issues in the past, but the original intention was to be doing it in an agile kanban approach where technically we could cut a release whenever. The issue was we had no code to release though and there was little point cutting releases for the sake of it.



    I don't see myself being a developer for much longer if the server isn't updated to 1.20 (it is stable now) within the next 6 months.


    I know some people will probably be angry if I bring Kaboom up in a thread about the state of TF, but I think in this case it is certainly warranted. After all, the server is usually always on the latest version of Minecraft a few weeks after release, and the plugins are updated every month or so. I find it much easier to contribute to Kaboom, even though the owner isn't available for contact on any sort of social media, due to the nature of the server, or there not being any sort of actual "development team", besides on and off contributors. Maybe this example isn't very good.

    I entirely agree, I wish we could get back to the point where we were running much newer versions of Minecraft, and our current setup enables us to do that without impacting the other servers on the network. Again the issue that's stopped us moving from our current version is lack of developer effort to provide a production ready 1.19 (now 1.20) TFM and other plugins release.

    After being here for approaching 11 years as an admin now, it's hard to disagree with any of your points really.


    Being 100% honest, it's really hard to motivate myself to work on TF stuff now, after the last couple of years of fairly consistent death threats, doxing and general issues it causes my life it's hard to keep loving the place especially when I've been working on building other communities which are significantly more friendly and grateful for the amount of time, effort and money that goes into running things like this.


    To be honest, I think a lot of people here forget this is something they get for free and is intended for their entertainment.


    I'm open to options to turn things around, but I'll be 100% honest, given how much TF costs and how generally ungrateful people have been for the place existing, if the mood / vibe / general impression people get joining TF / our Discord / forums doesn't improve over the coming months, I'll start to re-consider shit-canning this once and for all.

    Further to the recent emergent change block, we will be relaxing some of the restrictions currently in place now that the threat is more fully understood.


    As per the previous announcement, configuration file updates and Scissors updates were permitted to production and non production services.


    With immediate effect plugins that are built by our development team may be deployed to the non production infrastructure after specific targeted malware scanning has taken place, and with the approval of both videogamesm12 and Paldiu.


    These same plugins may be prompted from the Non Production Servers to the production environment no earlier than 6 hours after the plugin was uploaded to the development server, and only when the plugin to be uploaded as well as a randomly selected plugin have been checked for malware. Once these criteria are met the plugin may be promoted to the production server with the approval of only videogamesm12 or myself.


    Any other changes to the servers will remain blocked.


    Block Start: 7 June 2023 14:30 UTC

    Block End: Indefinite

    Next Block Review Date: 1 June 2023 13:00 UTC

    The long term plan will be to host a proper Wiki (Something like wiki.totalfredom.me) however it's waiting on us to be able to solve a few annoying technical problems around single sign on before we can launch this and similar things. At that point all those sorts of posts would be moved into the Wiki is my plan.

    Further to the earlier emergent change block, we will be extending this block until 11:00 AM UTC Tomorrow when the next review will take place.


    We have been able to work with the Scissors team and confirm the secure supply chain of the server binary and as a result updates to Scissors are now permitted across the network. Likewise updates to common configuration files across the network is now permitted.



    Any other changes to the servers will remain blocked.


    Block Start: 7 June 2023 14:30 UTC


    Block End: Indefinite


    Next Block Review Date: 8 June 2023 11:00 UTC

    Due to an emergent malware threat currently posing a risk to the integrity of our infrastructure, all changes to any of our minecraft community servers is now blocked with immediate effect. At the current time there will be no exceptions to the change block.


    This block impacts all plugins and configurations across the servers, as well as the infrastructure powering these servers.


    Block Start: 7 June 2023 14:30 UTC

    Block End: Indefinite


    Next Block Review Date: 7 June 2023 20:00 UTC

    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.

    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.

    We have a partial ability to restore posts though they'll all show up as bots when we do so, after the last time this happened we setup a backup process to export all of the content on a regular basis so not all will be lost, I'm just trying to figure out the best way to restore it as a lot of the ways that are recommended involves spinning up an entirely new server which I'd rather not do given everyone is in the current one. We will probably look to manually re-create everything off of the template and then look to restore posts. It could be a few days before everything is fully restored, and we won't look to re-open channel access for the newly re-created channels until the restore is complete.