The approach to TotalFreedomMod development

Please Note: The TotalFreedom Forum has now been put into a read-only mode. Total Freedom has now closed down and will not be returning in any way, shape or form. It has been a pleasure to lead this community and I wish you all the best for your futures.

    What direction do you think is best for the server and its future? 16

    1. Solution #1 (14) 88%
    2. Solution #2 (1) 6%
    3. Solution #3 (Explain why) (1) 6%

    I am creating this thread to gauge community input on where the direction of the TotalFreedomMod's development should go. From where I see things, there are two directions in which I believe we could go. However, I'm curious to know what your thoughts are as well.

    • Improving the current experience by fixing bugs, improving overall maintainability, and expanding upon existing features.
      Contrary to what Ryan says, my demoralization isn't from the player count. It's from my inability to be able to make changes that would help the plugin in multiple ways. This inability is primarily because from my eyes, the direction development is going favors features over maintainability. While this approach doesn't add much in terms of features, it greatly improves how things are set up in the sense that future additions/changes will be much easier to implement and implementations will be vastly easier to work with.

    • Adding more features.
      This may give players more things to do and may help to motivate more developers, but implementing them now when the codebase in the TotalFreedomMod is messy can lead to serious problems and may even make some things nearly impossible to pull off. Adding more features is great, but you need a solid foundation to implement it right. In my opinion, we don't have that at the moment.

    • Other.
      A direction not expressed in this post but something you yourself have come up with.

    image.png

    I'll reference what I've said to you and in my developer resignation thread:
    "the master plan was to stop TFMs 2020.x.x releases and essentially create a stop gap between TFM and Plex. TFM 6.0 (which AMG never merged by the way) was supposed to be the start of a major cleanup and debloat of TFM. essentially, 6.0 would fix a lot of the long standing bugs and freeze ALL features. then the plan was to start a prototype of Plex with its new way of organizing code and see if the community wanted development of Plex to continue. that way, both outcomes win. If yes, then TFM get retired and and Plex becomes the new TFM and then we start extensively testing it and really making it "drop in". if the community didn't want Plex, then that sucks but at least it was coding experience and some of the code could potentially make it into TFM. but if the community said no then remember that TFM 6.0 would exist. so even though TFM has underlying issues, when i resumed TFM development, i wouldn't be swamped fixing gazillions of bugs (they would've been fixed / i would've been better prepared to fix them). and of course as you know the plan was to have two separate dev teams (the plex team which we had) and then the TFM dev team which fixed super critical issues and handled normal plugin updates so that the server wouldn't entirely be locked in one state"
    and
    "The November update was underwhelming (and ultimately never actually got deployed unfortunately). I was planning for a mid November update which fixed a bunch of bugs within TFM and would have made things better. The plan was that after the mid November update was done, to start getting rid of a bunch of obseleted and useless features in TFM. I was going to skip December for an update since that's holidays and time you should be spending with family (or, well, at least not hooked to a computer screen imo). TFM would have been cleaned up for the January update to tide us over until Plex which would have been done by mid 2021. Making threads to intentionally piss me off is a douche move, especially when I'm actually active and working on Plex and TFM at the same time as a one man job. If I was inactive or not doing anything, then I do think bitching about it would have been perfectly justified. But I was actively working on everything and making those kind of threads drains me and adds to how already burned out I am. I was planning on appointing (or having the community vote on) taah and super for being devs if they wanted when Plex was done. I don't know (or really care) who becomes the new Dev / Lead Dev and what their direction for the server is. Anyways even though I may have had the shortest run of an executive position in the history of TF, I'm fine being an admin because it's a fun way to relax and chill with people."

    This is the plan you should have followed

    I made some comments earlier this year about what I think should be done with TFM. It's bit more of a radical idea, but to me, it's the best path forward in regard to not only maintaing the quality of the main permissions system of TF, but also a faster way to implement new features. The features could be hooked into a standard permissions sytem rather than having to work with TFM.

    Quote

    ↩  Panther I get that people like the idea of being opped and having every permission until it is blocked, but frankly, there are plenty of servers that aren't "freedom" or "free op" servers that trust their users with many more permissions than we do with users on TotalFreedom. With an actual permissions plugin, we don't have to bend over every single time we want to implement a plugin like PlotSquared or CoreProtect or WorldGuard into the server. The truth is that it is running based on workarounds, and even then there are still quirks, like players being able to block each others' commands because they are given access to all the plot flags. And don't even get started on what would happen if we decided to re-introduce paid ranks...last time that happened I figured out a way to give myself store credit, which worked since I was automatically given every permission to the payment plugin. There are also permissions that straight up don't work or are impossible to implement without a permissions plugin, and some of them could definitely come in handy for tightening security on the Total Freedom game server.

    I know that it's been traditional on TotalFreedom to defend the idea of "op" and "freedom" at all costs, but I think if this server actually wants to become a competent server network (which it is obviously trying to, by connecting the SMP, hub, and possibly more servers via BungeeCord,) it's going to need to move on to a permissions system that isn't full of holes. Permissions errors are going to become a bigger issue if the playerbase grows and more people are trying to screw around on the server with permissions. It is so much easier to manage these stupid permissions errors in a matter of a five-second command in game rather than a suggestion that could take god knows how long to get approved.

    To me, the "freedom" server is a far cry from actual freedom right now and would need changes that would strike many as drastic or harmful to the server to restore that freedom. The best path forward would be to create an anarchy server where this freedom is restored and we can start fresh without having to work around the regulations we have set up on the "freedom" server to best suit the community. As for the freedom server, a standard permission system would be much easier than trying to maintain the "Free OP" façade it still has now.

    ↩  Panther I somewhat agree but I think the biggest thing holding TF back is all the exploits and how much stuff is blocked due to exploits. Switching to a permission system would make the initial setup easier, but wouldn't fix any of the exploits. I've said this many times as well but the TF- plugins have other modifications besides the permissions. Some of them like disabling disguises and the granular control over essentials cannot be done with permissions alone

    ↩  Telesphoreo Those patches could be moved to a separate plugin, and in many cases the patches become easier due to the playerbase switching from real OP to having the same amount or slightly more permissions but not technically being OP. You mentioned disguises though, and I can't really argue there since we still have the disguise plugin because the trial version only works for opped players, which isn't an issue with TFM as it is now.

    I think my issue is I disagree with the assumption made in the second option. Most of the issues we're fixing were because features were never properly tested and were patching those. The vast majority of tfm code isn't being touched in the bug / improvements being made because it hasn't needed to...

    Its also worth noting the majority of releases of tfm since I've taken ownership have been heavily bug fixes and under the hood improvement. So I get shit from people on here because their suggestions aren't getting done, and then they leave...

    The bottom line is we can't have one or the other, and we currently lean far too much towards bug fixing over new features. Solving technical debt is great but if that's the Dev teams full time role we will have an efficient plugin that has no features players want.

    Wild1145

    Network Owner at TotalFreedom

    Managing Director at ATLAS Media Group Ltd.

    Founder & Owner at MastodonApp.UK

    Symbols:

    • < : Less important
    • Quote

      : More important

    • = : Equal to
    • , : And
    • Quote
    • << : same as >>

    Right now (at least in my opinion):

    • New features < existing features
    • New features = compatibility issues, bugs
    • Compatibility issues, bugs << dev team
    • dev team >> existing features, compatibility issues, bugs
    • Players >> new features
    • New features = ignored
    • Players = leave


    Solution 1 for reasons above, i believe fixing the overall stability (Patching bugs, fixing permission errors, etc.)
    Would be the best approach first, so we can actually go about adding new features for OPs in the future without the stability issues and bugs, If we even go about adding new features to TFM.
    So i propose the solution of Bug fixes and maintainability, And THEN we look into adding new features, pretty much summing up what i have said above. The downsides of this solution are:

    .We would need make sure all new features would have no issues with maintainability (More work on the devs)

    .More work on the devs in general to add new features

    The Upsides to this solution are (In my opinion)

    .The current playerbase may be satisfied with some of these extra features and bug fixes

    .Less work for the devs in the future UNLESS more features get added in the future, or more bugs show up.

    That is my opinion on the toping for now, could change in the future.