The Aurora Server Software

What is Aurora?

Aurora is like my dear child.
After reading this entry, I ask you not to compare it to any high-performance forks out there.
I do not want it advertised anywhere by anyone, this fork does not promise uncompromised performance, it has its own set of rules to work properly and any patches that come from other forks have been carefully reviewed, modified, and tested before making integrating them into the project.
Still, even if I don't want it to be talked about, or to have anyone other than me to use it, I still want to leave some sort of registry about its creation, its current purpose and the funny stories that came of its development.

Motivation

This project is quite strange, I usually hate development, I don't work on development in general unless I need to, or find something interesting to take part on.
However, I cannot describe the enjoyment I felt while developing this software, it is genuinely hard to explain.

It started with two purposes:

1. Learn about how paper forks are made, so I can properly handle Jellyfish, a fork for lobbies.
2. Add some customizations that would usually require NMS handling by plugins, which is highly volatile.

After starting it, I questioned if it would be possible to scratch some additional performance, and what would be the limit before everything starts to break apart.
Since I was new to forking Paper, I started by taking some patches from Leaf, those that looked benign, to not break the game too much.

On its first versions, from 1.21.4 to 1.21.6 the project was relatively stable, but with its own set of problems, like a longstanding bug on asynchronous chunk sending, which lasted until I dropped the Leaf version of the patch and made my own, which allowed me to fully understand the logic and finally fix it for good.

The first Aurora build I considered stable was 1.21.8, when most of the patches were now mostly written, or at least, touched by me in some way.
And as of writing this, the first build I consider fully production-ready is 1.21.11, with the support from @Mylcah, who helped me test it actively with more people than I can in my group of friends.

Performance

Even if it started, and is still built as a performance fork, I do not describing it as such as it does more than that.
Some features, like asynchronous pathfinding are no longer as worthwhile as they used to be when they were first conceived in 1.17. Still, I keep them mostly because I like them, rather than providing a significant performance impact.

I also stopped taking benchmarks, as any test I can do will be considered circumstantial evidence or a forced scenario.
Besides Parallel World Ticking, which does provide a huge performance boost, most features are impossible to properly (and honestly) benchmark. All servers are different, both in design and playerbase, a server can hold 80 people if they all just build, or at most 2 people, if they do a bunch of redstone contraptions.

As mentioned before, while I do consider Aurora stable and production-ready on its latest release, it was designed for my server, and only with my server in mind, therefore I cannot sincerely say it will be stable for you or anyone, and similar to Fish or Folia, it does have its own set of rules to work, plugin compatibility is 99% at most.

Design

Aurora was designed specifically for my server, as such it provides API that only makes sense for me to use and features that were easier to handle inside the server software rather than with a plugin.

As it was originally an experiment to scratch some performance, it contains some asynchronous features which may or may not have a significant performance impact. Except for Fish's Parallel World Ticking, that feature is insane.
Aurora is not full of micro-optimization patches as it can easily make it extremely hard to track down errors and therefore, maintain it. At the moment of writing this, it only contains 80 feature patches, where 80% of them range from 1 to 4 lines changes. The only reason those changes are feature patches and not file patches, is because that way is easier for me to see how many changes I did, and because I can add patch notes in the header.

As for API, it contains new methods to monitor the mspt per world when Parallel World Ticking is enabled, using PurpurBars which is a plugin I maintain.
It also contains a status API, where a "status" corresponds as the last element the player was in contact with, which makes it easier for me to apply/remove or add custom effects to players depending on the status, similar to Genshin Impact reactions.

It also contains some gameplay mechanics like crushing stones into gravel, an idea I took from YouHaveTrouble's ideas to improve Minecraft. To make this a more reliable source of gravel, anvils do not take damage if they crushed the block below.

It also contains some configurations that are not present in other forks, like modifying the anvil damage probability, the critical damage modifier when hitting a mob, the duration and delay between rain and storm (I have awful luck here, where I can easily get two full rainy days, one sunny, and then loop back at least twice... and never again when I finally get a trident!).

Management

Since it was designed for my server, any feature that I do not use will just be dropped if it becomes a burden to maintain.
Aurora is technically on maintenance mode, more features are unlikely to be added unless I need them, I already achieved peak performance for my needs without jumping into Folia, or completely breaking the game; and have already implemented the features and API I needed, therefore I only need to keep them updated.