Posts by Paldiu

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

    So I've started a D&D campaign based loosely around the FromSoftware titles, HP Lovecraft's cosmic horror genre, and the book collections by author Raymond E. Feist.

    This campaign takes place in a world under the influence of the Formless Pantheon, a collective of deific beings which have no moral compass, no straight defined line between what's right and wrong. These entities are worshipped by the masses, and are responsible for the very foundation of civilization as it stands now. However, things are not as they seem. One of the five great cities, known as Ædelnith, recently has fallen victim to the unbridled power of a Formless God, and lies completely in ruin. With no city to now provide artistic works to the rest of the continent, the remaining four cities lie in high tensions, as their source for artistry has been taken from them. Yet beyond the trade feud, something more sinister awaits, lurking in the shadows until the opportune time to strike. Secrets better left untold hide the true nature of the Pantheon, and the actual course of events which destroyed the Great City of Ædelnith. Something terrible is coming, and it's only a matter of time before it arrives.

    You can find storyline resources here: https://drive.google.com/drive/folders/…MJ9VU0EV-JUCkow

    You can also find a chronological time-line of events that will be updated as sessions occur with new plot points and storied events, here: https://www.worldanvil.com/w/capriox-pald…apriox-timeline

      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.

      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.

    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.