TotalFreedomMod Issues

    Okay, so towards the development team, there have been so many complaints on how "TFM" is coming along slowly, how we haven't integrated or fixed a bug. Let's mention what's going on.

    IMO, I don't believe TFM's codebase was ever designed to become this big. Back in 4.3, TFM didn't seem like it was designed for anything but a basic ranking with commands system. 5.0 came out and it revamped a lot of TFM, but revamping also came with bloating. With all due respect to Prozza and Madgeek, TFM has become more and more bloated over the years, hell bridges, services, etc. are annoying to work with. At one point, TFM even forced you to put extra plugins on the server to work with. From a developer standpoint, and no, I'm not new to this, I've worked with professionals and have been studying Computer Science on my own for the past 6 years of my life (turning 18 this year.. not a college student yet), TFM is extremely annoying to work with, especially with the poor naming conventions and lazy coding. I'm not going to come out and blame any current or past developers, but it's honestly because people don't feel the need to put effort into such a disorganized codebase. Over the years, TFM has been disregarding features and leaving them in the codebase. I don't even think we use Discord module anymore, yet it's still in there. It's constantly annoying when people bicker about us not adding things, but how about you go ahead and work with TFM's codebase, and then judge us? Here's some issues we've seen:

    • Bloated
    • TFGL (Why does this even exist? Idiotic.)
    • Unused code
    • Outdated Security Practices
    • Disorganized
    • Some commands are written poorly to the point where runtime can be slowed done. I.e. we have a literal command that loops through EVERY entity in the world.

    Oh, and let's not forget the fact that we have forks of plugins that depend on TFM, meaning if we were to fix TFM issues, we'd have to deal with the annoying factor of going through and hunting down every plugin that uses this. Keep in mind that as new developers come, like I, we have no idea what the fuck the point is of forks.

    And no, we're not adding NM support to TFM. If we were to ever switch to permissions, it would be a general API usage of Vault. But that doesn't clear up the issue. When dealing with permissions in Plex, we came across one security risk- BukkitTelnet. BukkitTelnet itself is extremely bloated, but that's besides the point. The way it is written currently, every sender from Bukkit Telnet is a CONSOLE sender. Most plugins check whether a command sender is a player, else they are console. If we were to switch to BukkitTelnet, any person using it would be able to use console commands. BukkitTelnet is in need of a rewrite, but in all honesty, we need to deprecate the whole telnet protocol and drop remote console usage (Sorry Video).

    This is funny to me because I'm in charge of you folks and I have never once said that NM will never be implemented. In fact, if this is how you feel, then I think there are better opportunities for you elsewhere that don't include developing for totalfreedom. If you decide that you'd like to contribute your own work on your own time, that is fine, but do not for a second think that you will keep rank by avoiding the explicitly defined workflow.

    ↩  Paldiu pardon me, I'm not a developer so I know I'm not fully qualified to say this but, from an outsiders perspective, it seems to me like part of the issue with the slow dev turnout and all that is due to the inefficiency of your "explicitly defined workflow". So perhaps that is another issue which you as the ELD should look at, it's your job to ensure the dev team Is able to get things done and from the sounds of it, that is not happening. I know I have no authority, but I do know that psychologically you are more likely to put the blame on someone else rather than yourself, and so it may be in your best interest to reflect upon your own systems, especially if your own team felt so strongly about this to have to make this post.

    ↩  Paldiu Whilst that is technically a good reason to remove their ranks, I think it is worth hearing them out first before pulling rank, considering the majority of them agree with this post (these topics aren't new). Threatening them will result in resignations (my prediction) which will ultimately slow down the already extremely slow development, tenfold.

    ↩  Paldiu

    The thing about the "do what I say or leave" strategy is that it doesn't work when you need the developers to help you out. Because we seriously need the developers.

    You're dealing with volunteers here, they have no reason to stay and keep helping this server out other than the goodness of their own heart. You are far from in a position to turn around and tell the development team to do what you want them to do or leave, because then they will leave.

    Quote

    ↩  Paldiu I’m in charge of you folks

    Thing about leadership is, you can't just bark out orders and expect everyone to follow. That's not how any of this works. In situations like this thread you need to work with your team to compromise on the issues they've raised.. not just tell them to shut up or leave.

    With that type of attitude you're not gonna be in charge of anything because either your developers are all gonna walk, or you'll lose your position as executive for failing to lead the development of the server properly.

    Patrolling the Mojave almost makes you wish for a nuclear winter.

    ↩  erin To add onto this, many have been complaining about the recent focuses on Plex development recently. The original reason Packs, Super, and I began Plex was due to how horribly TFM had come. We started this rewrite back around 2020 but only began to focus further on it during the past few months. It does the core main features of TFM, written better with a more readable codebase. For example, when going to add something with Plex, or fixing, it takes like usually 1-2 files to change. For TFM, yes I will be overexaggerating, but you have to go through like 10 classes then wait for maven's slow building (well, imo, its slow for me compared to gradle), then upload it to the server, then restart the server, wait for every plugin to load, then join the hub and connect to the server. And if the bug isnt fixed, repeat. For Plex, it's much easier because you know your way around better. Ayunami and Allink, new Plex contributors, they've adapted quickly to contributing to it, for example. While Plex isn't for TF, it'll better help TF in the long run as a replacement because it already has UUID support, permissions support, etc. Our HTTPD works better, looks nicer too lol, and is formatted better. We practice asynchronous threading when needed so the main thread isn't blocked by any sort of large code block or sequencing. I know Video has made his own fork for the UUID issue, but I see that still hasn't been merged unless it has been and I haven't noticed.

    edit: No, Plex isn't continuing because of TFM's poor codebase, it's continuing because it's a fun side project and is designed to help every and anyone easily who wishes to work on Plex. For example, I believe it was XenVoltz who had an issue with Plex because of a bug with Vault. I went in and removed the requirement of Vault within an hour and made it optional, and the issue was fixed quickly with a new jar automatically released because of the automatic building system Telesphoreo setup through Jenkins.

    I've already said that the involved people need to have a serious meeting about their issues or it's likely we'll go nowhere.

    ↩  taah The "problem" with Plex is that, as you said, it's your own project, not TF's. We have no obligation to adopt it, especially as there are unresolved personal issues between Ryan and some of Plex's developers.

    I'm not invalidating your points about TFM's terrible practices from older development stages.

    TotalFreedom's Executive Community & Marketing Manager

    ↩  Tizz

    While that has been stafed multiple times, it was also in the plans I believe the eventually get rid of TFM anyways. Without a similar plugin, TF isn't hiw it is. I understand your viewpoint but while Plex isn't a TF project, I 100% guarantee you that it is licensed and forever open sourced. For our Plexus organization, we're taking a professional standpoint and not letting personal grudges affect the development. If we were to let personal grudges affect us, that would put all this to waste:

    Months of Plex contributions and development, removing it will be disappointing and unfair for others

    Jenkins, the website, the workflows, every sort of system Packs has set up to make sure Plex is working.

    The fact that while not completed, our Guilds module for Plex works better than TF Guilds, which is also pretty bloated. I've also made Guilds loading and saving asynchronous so that helps with any sort of blocking on the main thread in case someone decides to load 100000 rows of data.

    I understand there is no obligation, but besides Ryan, Paldiu and Steven have mentioned giving Plex a change considering they've seen development amongst it. As steven puts it, there is no for sure, but as we finish up the TFM module, they have given a chance for a possibility of allowing Plex testing on the development server to see how well it will work on TF.

    Quote

    ↩  Tizz taah The “problem” with Plex is that, as you said, it’s your own project, not TF’s. We have no obligation to adopt it, especially as there are unresolved personal issues between Ryan and some of Plex’s developers.

    If you are referring to TFPatches this is being transferred to Ryan.

    Quote

    ↩  taah While that has been stafed multiple times, it was also in the plans I believe the eventually get rid of TFM anyways. Without a similar plugin, TF isn’t hiw it is. I understand your viewpoint but while Plex isn’t a TF project, I 100% guarantee you that it is licensed and forever open sourced. For our Plexus organization, we’re taking a professional standpoint and not letting personal grudges affect the development. If we were to let personal grudges affect us, that would put all this to waste:

    This entirely. Having it be under TF was a mistake we initially made. Plex is now entirely its own organization and has no relation to TF which is for the better. There is zero benefit to ending Plex development. We have sunk an insane amount of hours, effort, and money that it would be a huge waste for me to "ragequit" or delete the projects. With that being said, for additional protection, I've mirrored the entire Plexus organization as well at https://git.plex.us.org/plexus-mirror. I just thought I'd clarify that Plex development is not predicated on what happens on TF.

    Quote

    ↩  RedEastWood Maybe we should drop our ego and switch to Plex. It’s time.

    Based.

    Now I'd like to talk about two things.
    Firstly, I feel like TFMs codebase has gotten extremely bloated and unmaintainable. It's really hard, especially for a theoretical new developer, to dive into the current mess the codebase is in. TFM truly is so big that changing one thing can have consequences on five different other things. This is the reality for most huge projects, but they also don't demand such rapid progress like TF does.

    Secondly, this post serves as my resignation from Developer. I made this decision a while ago, but my rank wasn't removed, nor a post explaining why was made. The reason I have chosen to resign is due to the TotalFreedom General License. I don't agree with the license and won't write any more code under that license. I effectively can't distribute the code that I write the way I want without someone else's permission. I wasn't reading the fine print when I signed back up for developer, nor had I really given a thought to it. I attempted to compromise by working on other projects (e.g. Scissors, the bridges, etc), but working on TFM (which is licensed under TFGL) is a requirement. It is my deepest regrets that it must end this way, but there is nothing else I can do other than simply not write any code under that license. Note that there is Section 3 of TFGL which states the following:

    Quote
    1. Submission of Contributions
      Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions.

    Unfortunately this is too vague and Prozza takes quite a while to write back. Also, Ryan said he wouldn't accept code not licensed under TFGL for TFM so that seals the deal.

    My resignation does not mean Plex development will stop. The Plexus organization will still continue as it is entirely separate from TF.

    ↩  darwin While what Paldiu said wasn't right of him to, comments like this aren't the best in these situation because we want an equal amount of respect towards everyone regardless. I've known Paldiu for a long time, I know he is simply following Ryan's rules and tasks. I'm aware that Paldiu also has issues with TFM (or at least, thought he did? unsure)

    You folks seem to misunderstand my post. Firstly, the workflow is set up by Ryan and perpetuated by myself. I do not agree with the workflow, but I also don't agree with the developers under my supervision decidedly not implementing features that are slated for implementation. A big problem is that it seems as if I am solely responsible for the backlog and the hesitant behaviors of the developers but that simply is not true. When I took over there was a years worth of backlogged tickets and no developers. We now have a development team actively working on the implementations defined on the Jira, but due to the instability of TFMs code base and the absolute shitpile of disorganized, "I'm just gonna drop this in", actions that have built up over the course of the project changing hands, it's a disaster to work with and implementing / removing functionality is something that requires much more debugging and overall feature tweaking than any project actually written up correctly. I'm not going to sit here and hold hands but I'm also not going to sit here and watch the development team do whatever they feel like; ultimately if they fail to do what's asked then i fail as a lead, especially when the workflow is set upon me by Ryan and Steven.

    ↩  DragonSlayer2189 you don't know me very well. When I am truly at fault I take the blame. But in this situation, this workflow is set by Ryan and I have no control over it. Do not for a second think that all of this hindrance is because of some course of action I am taking, as I assure you it is most certainly not. Refer to the post above.

    haha mans making demands as if the team wont just walk away

    paldiu this is not a hill you should die on if they leave the only people who suffer is us

    Quote

    ↩  Paldiu Firstly, the workflow is set up by Ryan and perpetuated by myself.

    holy throw under the bus i was under the impression of two things
    1) ryan isn’t involved with tf right now
    2) executives are assigned by ryan and makes their own decisions about things like the eao doesn’t ask ryans approval for accepting admin apps, if it’s like this why do we have a eld

    that being said im probably wrong about a lotta stuff here as i don’t keep up with the dev side of things as i am smooth brain but like there is no leverage in saying ‘do exactly what i tell you or lose your block game rank that would go as paid work if done elsewhere’

    52-CEF3-CF-C4-FF-4798-8469-4-BDCA5-D35247.jpg

    ↩  Luke I have asked Ryan to change the workflow multiple times. He's the one in charge of the AMG team as well as it's associated repos. It was Ryan who set the workflow up alongside the testing schematic and all that other shit. If you really think that the workflow is an issue, talk to him because I have no authority to modify that. I'm not making demands, I'm simply stating that there is expected work to be done and the fact that it isn't is not acceptable by any means. As a developer you agreed to these terms when applying, implicating that active development must be done on tf projects to retain the rank. I apologize for sounding crass or rude but I'm frankly sick of all the issues being related to workflow and myself being scrutinized for that. If it were up to me, we wouldn't be using it.