I don't see that many people are using Starlight on modern versions anymore. As such, I don't see any reason to continue to maintain the mod versions, given that they do have real mod conflict issues with other mods. Starlight is also not neccessary to use on 1.20.x anyways.
Starlight may make a return in a future project of mine, but for now I am ceasing to upload new mod versions and commit updates to the github. If you want Starlight on the server, you will need to use Paper or one of its derivatives.
People have reached out to me indicating they want Starlight as a mod for whatever reason. While I personally disagree that it is still needed, I can also see that people still want it. Rather than leaving this mod in a state where people will either ship it in their mod OR upload forked versions, I will post updates to the mod but change the project descriptions to indicate that people really shouldn't be using it. I'd rather that if people are getting Starlight, it is the properly maintained version.
As some of you may know, Mojang wrote a faster light engine for 1.20. The improvements come from implementing two core ideas from Starlight:
- The light engine should propagate levels, rather than updates.
- The sky light engine should have dedicated logic to light chunks
Vanilla used to operate off of one queue, an update queue, but now operates off of an increase queue and decrease queue, like Starlight. Also like Starlight, the propagation of these levels has been optimized by the following:
- Storing whether the origin of a level change is a special shape block (reduces block reads by 2x)
- Storing a set of directions to propagate to, used to avoid propagations in directions known not to be useful (i.e where the propagation originated from)
- Using a simple deque for updates so that additions/removals are as fast as possible. Previously, vanilla used a linked hash set.
The full details of why propagation vs updates are faster is laid out in the Starlight technical details.
Vanilla does miss a lot of optimisations that Starlight does here, to the point where Vanilla is still 2x slower, but it is fast enough.
Vanilla used to sky light chunks with the light section initialisation, but that logic was too abstract and thus was very slow. Vanilla now sky lights chunks using a technique similar (the difference is in how the height map is generated) to Starlight 1.16/1.17. However, comparisons of the 1.20 Vanilla implementation and Starlight's 1.20 implementation aren't clear on which implementation is currently faster, but they do show that lighting chunks is far faster than it needs to be so it doesn't matter (anything << 1% of time to generate chunks doesn't matter).
I would say that usage on the client is obsoleted, minus the possibility of the light section management being a problem.
Currently, Starlight's light section management is depended on for both Paper's rewrite of the chunk system (people in the modding space call this "TACS") and Folia's additional changes to that system. In Starlight, light sections are tied directly to ChunkAccess objects.
The light section management prevents most bugs (including performance ones) involving missing/absent light sections, as Starlight assumes that no updates are possible unless the chunk exists. This is why there are basically zero performance or bug related issues with the light section management in Starlight. Note that Vanilla did not change their light engine section management to adhere to Starlight's design, so this difference still exists.
This difference in light section management allows my rewrite of the chunk system (which is designed as a solid base for Folia to build on, which adds regionized multithreading to the dedicated server) to greatly simplify and optimize its chunk unload/load logic as it no longer needs to consider any light engine state as there is no light engine state.
The "stateless" property of Starlight allows the chunk system to run light updates / generation in parallel provided the scheduling is done right, see patch "Increase parallelism for neighbour writing chunk statuses" in 1.19 Folia. This is critical to allowing the chunk system to scale beyond 10 worker threads, which as you may imagine is not critical to clients but rather important for dedicated servers with more players to stress chunk generation.
With all that in mind, Starlight is still important for Paper & Folia and as such I will continue to maintain it. However, since it is not important for the client anymore, I will not be posting any updates to the mod version. I will maintain the fabric version on github solely for the purpose of assisting with updating Starlight, as is with DataConverter (as a sidenote, DataConverter is not obsoleted by the recent performance changes to DFU).
Mojang improved upon their own light engine using the same performance critical designs from Starlight. As a result, they have closed the performance gap, obsoleting Starlight on the client side. I am not longer posting updates to the mod on CF and Modrinth.
Mojang still has not improved the performance critical designs for things that exclusively mattered to
the dedicated server, so Starlight will live on in Paper & Folia. As such, Starlight will still be
maintained on GitHub for Fabric to assist in updating Paper & Folia.
People have reached out to me indicating they want Starlight as a mod for whatever reason. While I personally disagree that it is still needed, I can also see that people still want it. Rather than leaving this mod in a state where people will either ship it in their mod OR upload forked versions, I will post updates to the mod but change the project descriptions to indicate that people really shouldn't be using it. I'd rather that if people are getting Starlight, it is the properly maintained version.
A question though: What about Fabric servers that don't want any "bug fixes" from dedicated server software like Paper? More often than not, Paper's "fixes" just borks vanilla mechanics.