Posts by Paldiu

    I feel it is rather redundant to have a server specifically for the void when we can just add it into the TotalFreedomMod using that fancy world generation system I came up with specifically for suggestions like these.

    The issue I was trying to avoid and am still trying to manage is the fact that our Freedom server worlds are problematic and difficult to fix without basically starting a brand new Freedom server and scrapping the current one...

    The issue with the freedom worlds are both our and minecrafts fault. On one hand, our world generation AND the worlds themselves are hard-coded. Video had created an implementation that changes it to be dynamic. The other hand is that mc world gen is ridiculously massive and as a result the more chunks loaded in and then saved to region files the more space they take up, in sizes of upwards of gigabytes. It's a hit or miss situation here; there's nothing we can do ourselves to abate the world sizes short of completely regenerating all the world folders.

    This forum entry will detail the necessary requirements, prerequisites, and provide a template for, developer applications.


    In order to be considered for the developer role, you must meet the following criteria:

    1. You must have contributed to the TotalFreedomMod repository, and had your changes approved and merged. (This can be achieved by contacting myself or another developer and requesting a JIRA ticket to work on.)
    2. You are not and have never been a security risk due to past occurrences of 'rogue' activity.
    3. You have a moderate understanding of the Java Development Kit.
    4. You have a moderate understanding of an Integrated Development Environment. (IntelliJ IDEA is the standard.)
    5. Your forum account is at least 30 days old.
    6. You have spent at least a week on the server.
    7. You are at least somewhat familiar with TotalFreedomMod and its functionality.
    8. You have a discord account and are present within the discord community.
    9. You have an active GitHub account.

    Once you feel that you are eligible and meet the above criteria, you may apply with the following template:


    1. What is your Minecraft username:
    2. What is your Discord handle and discriminator:
    3. What is your GitHub username:
    4. How long have you been working with Java and/or Minecraft:
    5. Provide a link to the approved and merged commit to TFM:
    6. What is your development environment:
    7. Do you meet the forum and server requirements listed above:
    8. If you have a portfolio, you may provide it now (this may be left blank):
    9. Please explain why you would like to be a developer for the TotalFreedom community:
    10. Please explain why you think you should be selected for the team:
    11. If you have any further questions and/or statements, you may list them here:

    Applications should be filed in the "Developer Applications" board.


    I am looking forward to any new developers who are willing to try their hand at participating in the behind-the-scenes work.

    This forum entry will detail the necessary testing requirements and protocols to follow in order to qualify a release candidate for a full release.


    It is important to note that these guidelines MUST be followed to push any projects labeled as Release Candidate to RELEASE status. Failure to comply with these guidelines will result in either


    1. Project is rolled back, and access is restricted to publish any further releases.
    2. Temporary sanction from the development team (repeated offenses / major security flaw or issue)


    Testing Requirements & Protocols:


    In order for a release candidate to be considered for a release, the following criteria must be met:


    1. Release Candidate must be tested thoroughly with 24 - 36 hours of logged testing time. This is split into two sections: ACTIVE and IDLE. There must be at least 12 hours of active testing (in game tests), and 12 hours of idle testing (server running with no hindrance) minimum to satisfy this time requirement.
    2. If this candidate is marked as EXPEDITED (project patches a major exploit or other pressing issue), the candidate must be tested for a minimum of 12 hours, with a full report detailing the findings of said testing.
    3. If any severe issues, bugs, or exploits are discovered, any logged testing hours (and reports if eligible), must be concluded and subsequentially discarded
    4. Every time an issue is discovered, and the logged hours (and reports if eligible) are discarded, a new release candidate must be published with the appropriate fix and the testing procedures must be reconducted.
    5. If a release candidate otherwise fails to meet quality specifications, for reasons not otherwise specified, any logged testing hours (and reports if eligible) must be concluded and subsequentially discarded.
    6. When a release is published, the full testing log must be published with a detailed list of changes in a forum post, by the publishing author. If a report was also completed, the report must also be included. Both the tracked testing time and the reports if eligible must be included in PLAIN TEXT and not in the form of any media or attachment. These may be enclosed in spoilers, to reduce the visual length of the post.
    7. If a release is pushed to the live server and a severe issue, bug, or exploit is found during live time, the live server must be reverted to the previous release, the release with the discovered issue must be discarded, a new release candidate must be published with the appropriate fix, and the testing procedures must be reconducted.

    When logging testing time, the following format must be used:


    MM/DD/YYYY @ HH:MM UTC (START / END)


    The hours and minutes should be in 24 hour time.

    Here is an example of this format:


    Testing Time Log:


    ACTIVE:

    01/01/1961 @ 18:39 UTC (START)

    01/01/1961 @ 22:20 UTC (END)

    01/02/1961 @ 15:08 UTC (START)

    01/02/1961 @ 21:37 UTC (END)

    01/03/1961 @ 14:34 UTC (START)

    01/03/1961 @ 19:55 UTC (END)


    IDLE:

    01/01/1961 @ 18:39 UTC (START)

    01/02/1961 @ 22:20 UTC (END)


    Note: Logged testing hours that occur during another user's logged testing hours do contribute towards the overall hourly requirement, provided that all users currently testing are not testing repetitively.


    The goals with these guidelines are to ensure that not only are the releases we are pushing are validated as working, but evidence is provided, and transparency is shown when publishing the releases in the form of forum posts, to provide the community with a much clearer presentation of what is happening behind the scenes, alongside a sense of security knowing there is evidence proving that the projects have been verified as tested and working.

    Though voting isn’t allowed, I still have a concern. There’s already a huge delay in development due to the huge backlog - if you were to become admin wouldn’t this lead to further delays?

    No; there's nothing short of a miracle that can save the backlog. In this situation, this is helpful to me because I can't even access half the things on the Live server so any debugging or bug identification needs to be done by cloning live and running it to dev then adding myself to admin and doing a bunch of extra steps when I could just be admin here and check things out on the live server.


    In terms of development; things are progressing as fast as they feasibly can with only two active developers (Video and I, sometimes Taah & Allink). We should be on track for the next release; if 2022.06 was not released yet then that's my fault and I'll have that released today. Otherwise, this won't affect development pace, or if it does the change would be negligible.

    1. Paldiu
    2. Sib Nutsch / Miaxis#0001
    3. Yes
    4. Super Admin from 2011 - 2012
      Senior Admin from 2012 - 2014 (Two year split for inactivity)
      Senior Admin from 2016 - 2019 (Maybe 2020, not sure)
    5. Removed for inactivity; I cannot remember if a post was made or not, but I think that I had left around the same time I ended up taking on two jobs and workings around 80 hours a week.
    6. Every day for at least 1-2 hours a day
    7. I have read and also agree to the terms and conditions, server rules, and staffing procedures and protocols.
    8. I have no family members who play on this server.

    this is actually the entire reason for my complete overhaul of the server plugins, especially TFM. I'm not trying to attract or inspire newcomers, I'm trying to provide our current community the tools they so desperately seek to acquire.

    bungeecord is what I'd consider to be "legacy code".

    Velocity is much more modernized and better written to match the times.

    Since md5 cba to revisit old functions and systems to see if improvements can be made, I vouch in favor of Velocity

    When i do my renders, i use WAV due to the lossless quality but i also have some very particular speficiations for the files:

    24 bit depth interpolation @ 512-point sinc (sine cardinal) sample rate


    It produces ultimately a pure lossless file with the highest possible quality. You could use 128 or 256 point sinc since the difference in quality between the three are almost imperceptible through most playback systems, but as far as FLAC goes I do not have those options and thus cannot have full control over the quality of my work.


    Converting WAV to FLAC can also cause issues if there's conflicting bit depth (unsupported) or sample rate (unsupported), and you end up losing something somewhere along the way.


    However FLAC and WAV are always better than MP3 or any other form of audio data encapsulation.

    It's really important to note a key difference between WAV and FLAC here:


    FLAC is much smaller and gives exceptional audio quality, but bit depth and sample rate is limited, which affects the overall quality of frequencies and the amount of total unison able to be rendered. For instance, if the bit depth and sample rate are too low, the track is rendered with a crackling sound which permeates through the background and interrupts the quality of listening.


    WAV is much larger as the file is generally uncompressed, but due to that it produces pure lossless audio. It's also much more dynamic, allowing for easy editing and tweaking of the audio, and provides an unlimited bit depth and sample rate so there's no concern for oversampling when rendering the file.

    After reading through this again, I've realized a "gotcha". If you intend to free yourself from the shackles of TFGL, you can't use any code from TFM at all. If you intend to split the functionality between a core plugin with extensions, you won't be able to just rip TFM code and organize it without using TFM's license.


    What actually is the plan then? Are you going to rewrite everything from scratch, and if so, what's the timeline for this? It took two years for Plex to get to v1.0 so how long are you actually planning on this taking?

    Plex is a fully realized rewrite of tfm, at its core.

    while we will be utilizing 100% unique and original code, we won't be working on nearly the same scale as Plex, since a majority of features are being offloaded to other plugins. I don't anticipate this taking 2 years, but to say a couple months would be egregious. I anticipate this taking a good bit of time, but regardless of how long it takes I intend on seeing it to completion.

    Howdy folks! The time has finally come.


    With TFM 2022.08 we will be implementing what we can that hasn't been targeted in TFM 2022.07, and this will be the final release for what will now be considered a Legacy plugin. In turn, we will be breaking TFM down and replacing features with pre existing software, and for anything else that isn't provided elsewhere will be implemented into a core and extension system; the reason behind this change is due in part to TFM containing too much legacy code that cannot be changed, alongside the TFGL restrictions and the fact that TFM is so resource intensive on its own (due to the plugin constantly accessing and calling methods and fields across a large spectrum of processes) that it has become not only difficult to work with as a developer but also brings out numerous performance issues which are highlighted by the single threaded server system that paper so ungraciously provides.


    What does this mean? TFM will not change in spirit, but in actual process and end user target things will be much easier to understand and work on, alongside being much faster and reliable. Not only that, but the core-extension concept will allow us to split what we have to custom build ourselves into sections which will not only be much more manageable but also will not cause the entire server to fail if one feature breaks, which is the case for TFM currently.


    As it stands, 2022.08 will continue as an LTS release (garnering bugfixes and patches alike as needed), until it can be officially retired and replaced by the new project. There is no name assigned as of this moment, however it will not be related to TFM to remain ambiguous from the legacy plugin, and to also avoid licensing under TFGL. From here on out, TFGL will be retired and either GPL or MIT will be used instead.


    We want to give our developers as much freedom as possible in regards to development and creation; as it currently stands that is not the case. We also want to ensure our community is satisfied with the performance and stability of the server, and it is believed that this is a necessary step to bring a much more adaptable and solidified plugin structure to TF that will enhance player AND developer experiences.


    Thanks much folks, here's to hoping we have a successful turnout for these changes. 🍻