Posts by taah

  • Senior Admin Application - Telesphoreo

    oh but finally, i'd like to vouch. i've known packs for years, more than anyone here probably. there has never been any sort of period of time where i've doubted him, his skills, his rules, him himself, or him as a leader. when it comes to plex, he's shown such great leadership and provided us great resources. he's matured more and more over time and despite the differences between him and the ownership, he's shown a lot of changes and he continues to change himself and make himself the best person he can possibly be.

  • Senior Admin Application - Telesphoreo

    ↩ @'glaucus atlanticus' this was about a year ago maybe, that whole issue. i think the main thing was we were really busy with plex as it was barely into beta and we added documentation shortly after. the main issues at the time were obviously ego (not even packs only, i reacted the same way), but also because a simple google search would've helped more to compile the plugin. since then, we've made amends with red and apologized for the immature actions we committed towards him, as it was wrong of us

  • TotalFreedomMod Issues

    ↩  Tizz


    I really think the developers we currently have are more knowledged with Minecraft server development therefore it should be community -> ELD OR owner approved, if one approves then yes, if BOTH deny then no, -> developers


    The issue with having the suggestion go through the owner first is because with all due respect to Wild, he's sometimes on his own page.

  • TF Bot Remake

    ↩  Noah A few suggestions here.

    1. For your index.js, line 25 should be simplified to (message.channel.id != config.channelid)
    2. I believe you should convert to lower case to ensure it works regardless. I don't use switch statements much in JS so they may automatically compare it ignoring case, unsure.
    3. The spacing may have been for readability but it is pretty excessive

    Other than that, it looks pretty well done, nice work.

  • TotalFreedomMod Issues

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

  • TotalFreedomMod Issues

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

  • TotalFreedomMod Issues

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

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