Posts by Allink

  • An open discussion on what it is like to be staff on TF nowadays

    I find it even funnier when those banned from freedom-01 chime in, as well.

  • An open discussion on what it is like to be staff on TF nowadays

    Quote from Tizz
    Quote from zekurt

    Perhaps pay your fucking devs?

    For not doing what it's asked to do and resigning when there are complaints they're not following the plan? We're stuck on 1.17, have to stop developing TFM and get rid of all-OP model because of them. Kudos to the remaining 2 (iirc) but we're basically stuck on all levels despite a clear plan of action and priorities.

    With all due respect, Tizz, expecting a volunteer team to complete the ~153 issues on Jira relating mostly to the poor design choices of TFM is absolutely unrealistic. And we're not "stuck on 1.17" and "getting rid of the all-OP model" "because of them".


    I don't know why exactly you think that we're the reason the server is stuck on 1.17.1. I've had PRs open to update TFM to 1.19(.x) since June of last year. My first one was to update TFM to 1.19. My second was to update it to 1.19.3 (and later 1.19.4). The only reason the server is not on 1.19/1.20 is because this pull request is merged, and there's a few plugins that are probably still running with versions from 2021.


    The only thing keeping the server from being on the latest version of Minecraft, bar wiping the world, is for the plugins to be updated, and for the Scissors jar to be replaced with the latest version of Minecraft. That's it. The 1.19.4 PR will run perfectly fine on Minecraft versions above 1.19. The only thing that changed anywhere near TFM was the Scissors API package. That's the only code-related change my PRs make.


    As developers, it's pretty hard to keep TF on the latest version of Minecraft given that we are unable to actually fucking update the plugins we develop/use on the server.


    The reason All-OP, True OP, or whatever you want to call it is being dropped is because it is fundamentally insecure. We have to block commands (which absolutely is not a good permission management solution) and maintain forks of plugins just for them to not give every permission away to OPs. Permission nodes are the future of TF, and have been for the past 7 years.


    It's the same thing with TFM. I guess the developers over the years complained enough about the state of TFM for it to finally to be dropped.

    Quote from zekurt

    This wouldn't be a problem if this server contracted a single professional instead of various unpaid volunteer amateurs over 10 years.

    I totally agree. Maybe if the people who wrote the base of what TFM is today somewhat knew how to write code that didn't crash when the direction of the wind in Bosnia changed, we wouldn't be in this position.

  • An open discussion on what it is like to be staff on TF nowadays

    Quote from Panther

    I am done talking about anarchy, and I am done suggesting any more changes. I am done trying to give you guys ideas. I am done trying to help. I am a fool for believing that at some point people would listen.

    Even if you have good ideas (which I personally don't believe you have many of), if you act like a pretentious jerk while attempting to inform people about it, don't be surprised when nobody pays any attention to those ideas, and are instead focusing on the way you behave.

  • I have a very intriguing question.

    Where's the evidence supporting your claim that these people "disappeared off the face of the internet and moved to an account, mostly because of TF"?

  • PluralKit bot - Suggestion

    Quote from FrutiKitty

    IIRC I heard that it was possible for people to retrieve people's personal info such as disc. password through something in the bot.

    Even if Discord did indeed store plaintext passwords (which they 100% do not), it's just not possible to magically retrieve someone's Discord password (or the hash of their password) with anything short of a phishing attack or Discord zero day. I doubt PluralKit would have anything to do this, unless PluralKit was compromised and has some sort of Discord OAuth integration and that theoretical zero day requires some sort of OAuth access token in order to retrieve the user's password.

  • An open discussion on what it is like to be staff on TF nowadays

    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.


    Of course, that's now all basically irrelevant now that Paldiu has started the development of FNS, however I hope that the "it sort of works, so why change it?" attitude will never be repeated to such a degree with the warning of my lengthy paragraph above. Let's hope FNS is finished quite soon, so we can finally kick TFM into the bowels of hell, and let it burn there for all eternity.


    This entire server smells heavily of slow stagnation. The current stagnant status of TF will eventually lead to its downfall, whether you believe it or not. The server bills are paid, sure, but there aren't any features actually being added, besides the occasional bug or exploit fix. The server never changes. For some people, that's probably fine, but I enjoy change in my servers. If you eat the same food, made by the same cook, every day, for every meal, then eventually you'll get sick of that food. I'm sure the players can relate to this sentiment, as the server has been stuck on 1.17.1 for an eternity now. 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. I became a developer while the server was on 1.17.1 in May of 2022, and the server is still on 1.17.1 over a year later. And TFM is able to run natively on 1.19.4, without any issues. It has been successfully deployed on IPTFreedom, a server ran by one of our community members, without any issues. And by the way, the 1.19.3 PR still works.

    I personally think operators moaning about TF not being on 1.19.4 is annoying, but it's a valid gripe to have with the way the server is currently being handed.


    This isn't the fault of one singular developer, or even Ryan. There are much more greener pastures than attempting to fix the shitcode that is TFM. But, nonetheless, PRs not being merged in months isn't particularly good for the state of the server, either way.


    It would also be much easier if developers without admin had access to some sort of logging, so they can read exceptions & what players are running to generate those exceptions, instead of having to rely on kind administrators to forward the stacktraces to them. I understand that the confidentiality of admin chat is a big concern there, but I don't think it would be particularly difficult to quickly add support to BukkitTelnet for allowing developers to remotely access the server's console, without the ability to run commands or view admin chat. If administration actually wants me to implement this, please don't hesitate to let me know to implement 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.


    Also, if you're wondering why I haven't brought any of this up in development discussion or anywhere similar, it's because I think this is pretty obvious to anyone who's been spectating the development cycle of TF. But I don't know, maybe it isn't and I should've brought it up. Sorry if that's the case.