Pick me because why not
because you didn't do what i told you to do!
this is extremely damaging to my superiority complex and in my establishment that is EXTREMELY important >:(
you taking the piss cause I didn't add rock? Get over it loser 🙄
Posts by Paldiu
-
-
Pick me because why not
-
Application accepted under the Emergency Approval Policy.
-
This application is approved under the Emergency Approval Policy.
-
This application is approved under the Emergency Approval Policy.
-
I would like to counter that by saying that video allink and I are all currently actively contributing to our new project.
On paper, it's a great plan if you guys can manage to get it done, but I'll believe it when I see it. I have respect for what the devs here are doing but I still don't think anyone is going to make it over the million zillion hurdles you need to get a custom plugin that is solid enough to serve a tech-savvy community with picky and stubborn upper management. TF has been waiting on a new custom plugin for years and the fact that it still hasn't been implemented makes me believe it just isn't a viable plan.
While I agree that we've been waiting for years, I've only just been able to start working on said project. Previously all my time was spent fixing and improving TFM. It was only until recently (maybe a month or so) that I was able to begin work on FNS. You can check out the repository on https://github.com/AtlasMediaGroup/Freedom-Network-Suite to see our current progress.
At this time the project is over 50% complete; if I was able to start work on this sooner, I would have. -
Dude as an exec you were the problem I mentioned in the server-management section. You refused to do your job, you sat and just bitched about literally everything, and you refused to listen when legit like nobody else wanted your idea and still tried to press it as if it’d change anything
Since you're now bringing this up, I actually started to suggest the anarchy idea after everything else I wanted done with freedom was turned down by Ryan or someone else. Anyone else who was there knows it'd be a lie to say anarchy was the only potential solution I suggested - I brought up many different things that could be done to make the server more interesting. I talked with Steven about bringing a cracked system back that could host both premium and cracked players. I suggested we switch to standard permissions. I offered to do the work on that myself if it was needed, because I was someone who had the motivation to actually do it (at the time.) I suggested we experiment with datapacks and new gamemode ideas. The number one point I actually brought up with the executives then were that my hands were tied, and something needed to be done about the game server before I could begin marketing - I literally couldn't do the rest of my job properly with the lifeless state of the freedom server. Nobody can.
At a certain point the response to every single one of those changes I suggested was that it "wasn't my job," and that by making those points I "wasn't doing my job," but that is a completely nonsensical argument. For as much as everyone here hated the lack of actual action from me, that same lack of action has honestly been present ever since I left. People don't complain about it as much because it's under the guise of someone whose job is to pretend community events and small changes and steps taken to market a server that is currently a dysfunctional creative freebuild are actually going to cause any significant growth. The server is still just as dead as it was the entire time I was there.
The reason I literally did nothing but suggest these changes is because I knew nothing was going to get done anyway unless changes were made to the in-game experience. And honestly, everything that has happened since I left has proven that point. Tizz has honestly made just as much progress as I had as marketing manager, but that's something nobody here wants to talk about because I was up front and took the shit for getting nothing done while he has just accepted that his hands are tied and taken steps to obscure the fact that nothing is still getting done. In this thread everyone is complaining about how the server is still sluggish and boring, and that nobody has any motivation to do anything.
I am done talking about anarchy, and I am done suggesting any more changes. I am done trying to give you guys ideas. I am done trying to help. I am a fool for believing that at some point people would listen.
To be quite honest, more than half of the points you've made are irrelevant with the changes video and I are making across the board. You say we don't have the developer manpower to accomplish a new custom plugin in a way that TF needs it to be done, and I would like to counter that by saying that video allink and I are all currently actively contributing to our new project. I have all the time in the world now that I work mornings exclusively, ND most of my time at home is spent working on FNS. There's a lot of BTS stuff going on and I don't expect you to know that but at the same time it's very bold and aggregious of you to make such broad assumptions based on information from a couple years ago. While I agree with some of the things you're saying most of it is currently unfounded at this current time.
-
In light of recent occurrences, and also considering the unpredictable nature of our work, it is expected that circumstances may arise which necessitate a more agile and less restrictive process for the approval of developer applications. As a result, I have established an Emergency Approval Policy to ensure that we can readily accept developers in a situation where development effort is sorely needed.
Emergency conditions are defined as crises, emergencies, or any unforeseeable, unexpected, or extremely undesirable circumstances that substantially disrupt normal operations. These conditions may necessitate an immediate increase in developer manpower or a sudden need for specific skill sets not currently available within the team.
During these times, the regular application requirements are adjusted as follows:
- Previous occurrences of 'rogue' activity will be assessed on a case-by-case basis. If the applicant is of master builder rank, admin, or higher, this requirement is waived.
- Applicants should have a basic understanding of the Bukkit API and the Java Development Kit. We will provide on-the-job learning, if necessary.
- Discord and GitHub account requirements remain due to their importance for communication and collaboration.
- Previous members of the development team who are in good standing will be readded upon request.
The revised application template is as follows:
What is your Minecraft username:
What is your Discord handle and discriminator:
What is your GitHub username:
What is your development environment:
Describe your experience with Java and/or Minecraft:
Please link your portfolio here, if applicable:
Please note, applicants accepted under this policy will be under probation for a period of 30 days, where their contributions and conduct will be closely monitored. This is to ensure that even in emergency situations, we maintain the integrity and safety of our community and the project.
Applications can be filed in this board and can follow the same title format, with the addition of "[E]" as the prefix.
-
that's a name I haven't seen for a while. Welcome back.
-
I would also like to make the argument that both DiscordSRV and EXDiscord are written using JDA, while the Discord implementation that I've got on the RELEASE-2023.03 branch is written with D4J.
In most cases, JDA is a fine product and works as intended without issue. However, due to the nature of how MC functions on a performance level, I argue that D4J would be a better option for us. The discord bot I've written for TFM (which is 100% operational) uses this API instead of JDA and I would highly recommend that we keep this even if it's a project maintained exclusively by myself (which is fine by me, I can even release it on spigot if that makes you feel better). Some minor tweaks to it can make it run exclusively standalone, so that isn't a concern either.
I could write an entire essay on why D4J is a better option for us than JDA alternatives, but I don't think that's necessary. Though, if it is, I will be more than happy to explain exactly why we should use this over the alternatives.If we can make it it's own stand alone plugin that live on our Github and is maintained and maintainable (Ideally even with tests though that seems to be a novel thing in MC Dev) I'm happy to use basically whatever, I just don't want any special sauce and it needs to be that we could swap it out for DiscordSRV / similar if we had to in the future.
That's fine, we can do that. I can also make sure to fully document the entire project to ensure maintainability.
-
Unfortunately due to the things we currently have in the discord bot and how it communicates with our plugin, a "standard plugin" is not in the realm of possibility. Even if we migrated our admin chat to Network Manager, we will still need to implement our own discord impl to communicate those messages to our discord server. The OTS plugins do not support that kind of communication and only skims readable messages.
The only way we can get away with using something like EXDiscord or DiscordSRV is if we reduce certain functionalities
Network Manager have their own plugin for admin / staff chats so DiscordSRV / Essentials Disocrd / Similar would be absolutely fine at that point, it's been tested on the hub and in our plots dev server. The current limitation is TFM.
I would also like to make the argument that both DiscordSRV and EXDiscord are written using JDA, while the Discord implementation that I've got on the RELEASE-2023.03 branch is written with D4J.
In most cases, JDA is a fine product and works as intended without issue. However, due to the nature of how MC functions on a performance level, I argue that D4J would be a better option for us. The discord bot I've written for TFM (which is 100% operational) uses this API instead of JDA and I would highly recommend that we keep this even if it's a project maintained exclusively by myself (which is fine by me, I can even release it on spigot if that makes you feel better). Some minor tweaks to it can make it run exclusively standalone, so that isn't a concern either.
I could write an entire essay on why D4J is a better option for us than JDA alternatives, but I don't think that's necessary. Though, if it is, I will be more than happy to explain exactly why we should use this over the alternatives. -
So once we are able to move to a standard plugin this will be mostly native anyway, you can post your long message and it gets pretty aggressively truncated in server so it's not super spammy.
Unfortunately due to the things we currently have in the discord bot and how it communicates with our plugin, a "standard plugin" is not in the realm of possibility. Even if we migrated our admin chat to Network Manager, we will still need to implement our own discord impl to communicate those messages to our discord server. The OTS plugins do not support that kind of communication and only skims readable messages.
The only way we can get away with using something like EXDiscord or DiscordSRV is if we reduce certain functionalities.
-
There is no "bug" with dot-edit messages. This feature is as intended.
There are no feasible reasons in which we should be including a filter for individuals so they don't have to dot-edit their messages; it's not that much work to do that, and it would be more work on the development side to implement such a feature.I understand the idea and the thought behind it but ultimately, it would be a waste of developer focus when there's plenty of other feature requests that have already been made that would be better off being implemented first.
-
I posted a logo concept ages ago, if someone finds it post it here.
-
Yooooooooo i bet half these people don't remember you bro but I do. If you get your activity requirement met I'll vouch + rec. Glad to see you back, suprmn.
I remember when I was ecd and you were my assistant. That was like 8 years ago. Crazy! -
-
Are there some modifications I can't do with plugins such as ItemizerX without being opped?
This will have to be examined when we drop the RC onto the dev server for testing.
-
Display More
[...] manipulating NBT data beyond the allowed scope [...]. We've already circumvented this by taking away a large portion of these privileges
I'm not sure I agree with revoking the ability to mess around with NBT. Frankly, I believe this will harm the community more than it will help it because a large portion of this community focuses on the idea of custom or unique items, usually created by messing around with NBT beyond what is normally possibly within the limits of the game.
This will ideally prevent things like the armor stand bugs, the sign bugs, the item frame bugs, the painting bugs, the entity nbt bugs, etc...
You see, that's what makes TF so unique though. The unrestricted ability to mess around with items to do things that were never intended by Mojang and would have been blocked by other servers is one of the things that makes TF feel more free than a generic creative server. I don't think it's wise to take away this freedom to push Minecraft to its limits.
Here's an explanation of why we need to wipe flatlands for 1.19.3 and why the world sizes increased: With 1.19, Mojang introduced a negative y value for their world generation. First, let's imagine how java processes an integer. Integers by default can take up to 32 bits of space. We can divide this into 8 numbers, appearing as such: 0000 0000 0000 0000. The number 1, for example, is 0000 0000 0000 0001. This can be stored negligibly as 1 bit as it only needs the 1, as all the prefixed 0s are unneeded. Through something called the Most Significant Bit (MSB), we determine how much storage is necessary to store that particular value. With the number 1, our most significant bit is 1. This means we can store a that number as a singular bit in our storage files. However, when you introduce the negative number, our MSB changes. -1 is represented as 1000 0000 0000 0001. This means our MSB is the first 1 in the sequence, which means we need to store all the bits to memory.
Now, in the context of our world files, this means that for every single y increment of -1 that the world generates, it stores the 32 bits of data in comparison to its minimum. Across thousands of chunks with around 25 million blocks squared across the map (might be larger, either way not good), not including our Y coordinate, this is exponentially larger than previously where integers were strictly positive. This means that world sizes nearly double due to the new Y value rules, and this causes major issues especially with larger world files. For comparison, our flatlands file is around 300GB. If we update to 1.19, it will increase to about 534GB. The total amount of storage space all of the worlds occupy is about 580 gb, currently. If we update without wiping, this will increase to over 1TB of space, which is absolutely outrageous.
TL;DR: If we were to upgrade to 1.19.3 with the current worlds we have now, the size of the worlds would grow to a point where it would be beyond our control due to the differences in how Minecraft stores world data in 1.18+.
"Beyond the allowed scope" is meant for code restriction not the default numbers that minecraft typically allows; there's a limit to the amount of data we can assign especially to numerical objects such as longs and integers. If users make items that then result minecraft exceeding its bounds then it will crash the server. My intention is not to take away the ability to freely modify and manipulate NBT data, but rather prevent things that could crash the server or otherwise impact the performance or experiences of others in a negative way. I completely agree that free expression through NBT manipulation is one of the things that sets TF apart, and I only want to make sure that we can grant these features to our community without risk of exploitation.
-
Hello again TotalFreedom community! We've been hard at work behind the scenes trying to improve our systems in a way that is more in line with current standards. As you all know, we are using an 11-year-old plugin called "TotalFreedomMod". In the past, this was a plugin engineering marvel, because of the things which it accomplished.
Recently, it has become very clear to us on the development team that pursuing the "True OP" prospect is no longer a viable option.Consider the following bullet points:
- True OP is dangerous as it gives people unadulterated administrative access to root processes such as manipulating NBT data beyond the allowed scope, or utilizing native commands or features that otherwise should not be available to the regular player.- We've already circumvented this by taking away a large portion of these privileges, which arguably also removes the idea of "True OP" as you now are imposed restrictions, with still a hierarchy of individuals overseeing your actions.
- Effectively, in the current day and age, we can have the same exact setup without all the game-breaking bugs, simply by converting our systems to permissions.
As a result, we've decided, to migrate TFM entirely to a permissions-based system. What does this mean?
For starters, there is no more "True OP". As previously stated, this system is full of issues, some minor and some severe, but are issues none-the-less. Instead, we are using permissions, which are registered against the Bukkit permissions system and as a result are compatible with any off-the-shelf permission management plugins.
Don't worry though! For you as a user, everything should remain exactly the same, albeit some features will no longer be accessible. This will ideally prevent things like the armor stand bugs, the sign bugs, the item frame bugs, the painting bugs, the entity nbt bugs, etc...This may interfere with the player's ability to create hacked / death / troll potions. On one side, this is good, but on the other, it may be an issue for some of the more beneficial hacked potions that players tend to use. If this is the case, we will find a way to implement those features back (with restrictions).
Additionally, we have redesigned our discord implementation. It is functionally identical to our current one, however it uses a completely different backend api to accomplish the same tasks. It is also now a completely separate plugin, although it still depends on TFM as we provide some context to the plugin that otherwise would require a lot more development effort to reasonably accomplish. This was done exclusively to improve our implementation's performance, alongside some additional security features which JDA (our current implementation) does not provide.
We have also migrated the shop out to a separate plugin dependent on TFM, though it is deprecated and slated for complete removal in the future.
We have also spent time on introducing some QoL changes across the board. Since there's quite a bit to cover on this topic, we will be including the feature changes on our release notes, which will be appended to the end of this forum post when the release candidate is cut.
Another thing I would like to bring to our attention is our worlds, and why we need to drop them before we can upgrade to 1.19.
I have explained this in the freedom server before, but I will explain it here, so it is accessible to everyone.
Here's an explanation of why we need to wipe flatlands for 1.19.3 and why the world sizes increased: With 1.19, Mojang introduced a negative y value for their world generation. First, let's imagine how java processes an integer. Integers by default can take up to 32 bits of space. We can divide this into 8 numbers, appearing as such: 0000 0000 0000 0000. The number 1, for example, is 0000 0000 0000 0001. This can be stored negligibly as 1 bit as it only needs the 1, as all the prefixed 0s are unneeded. Through something called the Most Significant Bit (MSB), we determine how much storage is necessary to store that particular value. With the number 1, our most significant bit is 1. This means we can store a that number as a singular bit in our storage files. However, when you introduce the negative number, our MSB changes. -1 is represented as 1000 0000 0000 0001. This means our MSB is the first 1 in the sequence, which means we need to store all the bits to memory.
Now, in the context of our world files, this means that for every single y increment of -1 that the world generates, it stores the 32 bits of data in comparison to its minimum. Across thousands of chunks with around 25 million blocks squared across the map (might be larger, either way not good), not including our Y coordinate, this is exponentially larger than previously where integers were strictly positive. This means that world sizes nearly double due to the new Y value rules, and this causes major issues especially with larger world files. For comparison, our flatlands file is around 300GB. If we update to 1.19, it will increase to about 534GB. The total amount of storage space all of the worlds occupy is about 580 gb, currently. If we update without wiping, this will increase to over 1TB of space, which is absolutely outrageous.
Without a doubt, this is a critical issue and we must wipe our worlds before we can officially update our network to be 1.19.3 across the board.
I hope this provides valuable insight to the current state of development. If you have any questions please feel free to comment on this post, or dm me [on here or discord].
-
don't recognize you but welcome back!
