Yaptapia

Why you shouldn’t take Yatopia’s claims at face value

This list aims at collecting concrete evidence of larger missteps of the Yatopia project and its members. While every developer will at some point make an unforgiving mistake or give an unflattering comment, the points below should depict a clear regularity and severity to their mistakes.

Yatopia Is No More

On the 19th of June, Yatopia was announced to be discontinued. While this is an unfortunate end to the project, I respect the decision to do so. This page will now serve as a reminder to everyone blindly jumping on the next “high performance” server fork without doing their own research.

A good example of a new fork you should not use is SugarcaneMC, already showing most of the same issues Yatopia has had, but amplified to be worse from the very beginning.¹

Disclaimer

Please do not harass Yatopia project members or users, that is far from the intent of this document. Its purpose is not to personally attack the team — I am sure they are nice people and they do not deserve to get unnecessarily spammed — but to warn users. Kindly make them aware of the shortcomings of Yatopia and potentially suggest they switch to Paper instead; do not do that on the Yatopia Discord either unless it naturally comes up in conversation.

Server Integrity

• Constant influx of non-trivial issues: They regularly have to remove (other people’s as well as their own) patches they include without understanding the code’s implications or potential risks, or simply because they are unable to update the code — at worst even causing irreversible world/userdata corruption.
  • Fully reverted “lithium-gen” patch because of a block issue (unfixed; the original commit’s description named this as the cause of the block issue, but was later force pushed off the main branch).
  • Fully reverted “Lithium-CompactSineLUT” patch because of a block issue (unfixed with the revert later force pushed off the main branch).
  • Fully reverted “Port-Cadmium” patch because of a block issue (unfixed and later reverted).
  • Fully reverted “Port-LazyDFU” patch (see points below).
  • Fully reverted “lithium-AI” patch because of mob AI issues.
  • Fully reverted “Port-hydrogen” patch because of block-state and plugin compatibility issues.
  • Fully reverted “Add-JsonList-save-timings” patch because of a Timings issue (unfixed).
  • Fully reverted “New-Network-System” and “Port-krypton” patches because of major networking issues.
  • Fully reverted “Improve-task-performance” patch because of chunk generation issues with specific custom world generators.
  • Fully reverted “Use-offline-uuids-if-we-need-to”, “Add-a-special-case-for-floodgate-and-offline-uuids”, and “ProxyForwardDataEvent” patches because of UUID corruption.
  • Mostly reverted “Port-krypton” patch because of networking issues.
• Not properly reviewing pull requests: If not evident enough from the examples above, they do not properly review their pull requests and ported patches, despite multiple people looking at them. This includes even the simpler ones with obvious errors made by someone exclusively using the GH web editor (which could have easily been checked for syntax errors with an online tool or their IDE instead of throttling their CI with test commits).
• Not putting enough thought into the patches they pull: They unnecessarily ported the Fabric mod LazyDFU to absolutely no effect; LazyDFU’s idea originated from a Paper patch having the same result, which they had already included before (they removed the patch only after Tux, LazyDFU’s developer, told them how unnecessary the port was).
• Inadequate testing: Despite Yatopia very proudly talking of their testing methods, their “Tester Team” solely relies on simply starting a server running dev builds and checking whether or not it obviously breaks. As evident by the regular patch reverts and reoccurring issues, this is far from being a sufficient testing method. Additionally, their “benchmarks” only consist of contextually driven Spark reports or millisecond-per-tick comparisons. These are fine if done in a perfectly replicable environment or used as anecdotal evidence, but are an insufficient performance metric if used on their own all the time.
  • See Starlight Technical Details for an example of actual benchmarks using proper profilers, direct method cost comparison, and more controlled in-game testing environments (additionally used and presented after the fully controlled metrics).
• Unmaintainability: Aside from the constant patch reverts showing a lack of understanding of the code they pull, Yatoclip is another major example of Yatopia’s unmaintainability. They created Yatoclip, a version of paperclip to put most of the actual patch work to the people using Yatopia instead of their CI and had to revert it because they did not know how to update it after an upstream build script change — it was only fixed months later.
  • Yatopia’s faulty build system fully shaded all used Maven plugins and dependencies, which they did not realize or fix for months.
  • They copy-pasted code from Toothpick in its entirety, but did not care to follow its updates or how it operates, resulting in them missing the reasonably easy fix for the dependency problem.
  • Their CI was broken for multiple weeks, with a large number of unsuccessful attempts at fixing it.
  • They almost completely removed all of Yatoclip and their own (and copied) build system, as well as the ability to have multiple upstreams properly separated and automated while trying to fix a block issue (which first appeared about a month earlier and has been taunting the project since, with the devs unable to find its actual cause), making Purpur their only direct upstream.
    • The corresponding pr was closed a few days later after a small number of people reported still experiencing the issue, silently removing the PR description.
    • The issue was “fixed” later, blaming an older, unrelated Tuinity patch, despite the issue exclusively occurring on Yatopia with not a single confirmed report of it on Tuinity or Purpur.
    • The only report (see the Tuinity Discord) they have continued using as their only piece of evidence (see their Discord for context) is very clearly manually constructed and not at all in line with the issue Yatopia has had; every single screenshot on their issue tracker as well as Discord suggests that their issue is due to palette corruption, meaning one block-state will always be the same “wrong” block-state — not shuffled to multiple different types as seen in the fabricated screenshot.
    • Yatopia is yet to provide any evidence of where the issue came from other than “We restarted 1000+ times and it was fixed, so it must be this patch” or even when exactly the issue started happening in the first place.
• Missing fixes handed on a silver plate: They accepted a PR to copy-paste a log4j class, excluding a very valid warning instead of searching for solutions online or even reading the Stack Overflow thread provided in the original issue, containing the proper one line fix.

Yatopia Developers

• Yatopia’s contributors are known to post unconvincing evidence of their advantages. “Benchmarks” they provide only consist of vague, contextually driven millisecond-per-tick and ticks-per-second comparisons.
• The performance boost they pride themselves with mostly comes from inherently unsafe patches (see above, their issue tracker, and the number of patches they have to revert after issues come up) and otherwise the actually stable fork Tuinity, made by someone with proper knowledge of concurrency safe handling, testing, and benchmarking.
• They lack basic knowledge of the server’s interior workings, such as the existence of block palettes, and fall back to wild guessing when it comes to issue debugging (see their Discord for context).
• In a Yatopia fork (actually marked as “experimental”, but still of importance) by Jettison Jerry, Yatopia’s lead developer, you can find more examples of bad decision-making:
  • It contains an Airplane patch specifically and clearly marked as badly designed.
  • It contains a supposedly concurrent implementation of a FastUtil collection (see here for one of the originals), which — evident to any developer knowing how FastUtil works — completely nullifies any performance gain the library usually provides. In Titanium’s blog, he states these were provided jediminer543 and that he learned a lot from him; in reality, both are unable to find these obvious flaws of their own and copied code.
  • It contains a patch from Patina to prevent plugins from detecting Yatopia when checking for its Config class (with the patch otherwise only containing insignificant changes).
• 2 Yatopia team members (more seriously than jokingly) discussed hackily bypassing plugins’ server software checks in Yatopia (see their Discord for context).

Other

• Developers from Paper, Tuinity, Purpur, Airplane, as well as large plugin projects like EssentialsX are strongly and explicitly advising against using Yatopia.

Expected Counterarguments

This lists arguments Yatopia members might respond with or actually have responded with in the past.

• “We are stable now” - The regular reverts and issues in the main branch suggest otherwise.
• “It’s not ‘unmaintainable’” - Dropping entire patches as well as the self-made patch system instead of fixing them suggests otherwise.
• “You are nitpicking” - This list only contains the most obvious and severe errors and issues. A hypercritical list would be much longer and take apart the unsafe patches (including patches during development).
• “Just let people use what they want” - Every user has the right to be informed about the stability of the software they are using as well as the fact its project members are spreading blatant misinformation.
• “This is Paper throwing unnecessary hate at Yatopia” - I do not represent Paper with this list, and both I and Paper specifically condemn harassing other projects/project members. They do, however, care about users running stable software.
• “Link X you provided is a petty example and I can counter that” - If any point is proven to be incorrect, I will immediately change or remove it. However, unless a majority of this page can be well disputed with more than just circumstantial evidence, its arguments still stand.

Closing Note

It is important to note that all of this has nothing to do with the personality of the Yatopia members mentioned, and I am sure Titanium and the others are good people, not driven by malice, but by naivety.

No developer working with such complex software is free of making mistakes. It does, however, become clear that these are not just mistakes (accidents), but clear-cut errors (lack of expertise) if they happen on a regular basis. Even this would not be as much of a problem if the members of Yatopia did not advertise their fork as an all-in-one solution that delivers the best performance possible. Instead, they should drop their euphemistic use of the phrases “borrowing code” and “best in class performance” and clearly state that their fork is experimentally driven and that they can at no point make promises to the stability and actual performance of their own patches.

As is, more and more people blindly start believing Yatopia is the solution to all their performance problems and that the (properly stable) benefits stem from Yatopia, when they actually come from the forks they are based on, fully disregarding the very real chance of instability. Nonetheless, to end on a somewhat positive note; Yatopia is better than closed-source server forks found on MCM, but still is not much more than a few inexperienced people copy-pasting code and experimenting with their own, unsafe patches.

Yatopia Yearbook

¹ Even tho out of scope, here’s a few points on SugarcaneMC for the record’s sake: While being very clear it is “not production ready”, they needlessly and prematurely announced themselves, including a questionable feature of “togglable gpu acceleration” — both due to the goal itself and the future implementation, given the developers’ experience in development. All of this despite being a mere subset of Yatopia patches, still including patches prone to concurrency issues and soft memory leaking. Lastly, add miscommunication within the team and a big spoon of randomness on top of the lacking expertise, and you have successfully crafted Sugarcane (see here, here, here, here, here (copied from main by hand, but without an already made commit fixing all the typos), or here). </sub>