Posts by taah

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.

      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.

      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.

    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).

    It's not about credit or discredit, it's about copyright of TFM.

    Looking at Plex's source code, it looks like a bunch of copy-pasted source code from TFM and Aero (utility plugin). You just put it under a different license and pretended it's yours.

    You can't simpy do that. You have to remove all parts which infringe on the TFM license (as per the TFM repository) and the Aero License (as per the Aero repository) or otherwise comply to the license requirements.