LambDynamicLights v4.5.0 got released with NeoForge support!
Since my last blog post (which has been a while, almost a year!), LambDynamicLights has gotten consistent and regular updates to ensure its availability on new Minecraft updates. The mod has also gotten some backports to 1.20.1! Though, not many of those updates warranted a long-form post.
Until now, LambDynamicLights v4.5.0 has been released with NeoForge support!
Banner made by
Akarys, my wonderful partner.
This is quite the milestone, especially as I've spent these last few months working towards this goal.
For ease of use, both Fabric and NeoForge are supported using the same JAR! So no way to get the wrong JAR! ;)
What's Next?
Well, given the date, I think the first priority is going to be to port the mod to The Copper Age drop.
Then, despite the numerous additions, there is still much to do!
I have some things to look into next, no promises, as it's all still in the investigation stage:
- more optimizations, like culling to avoid computing dynamic light sources that are not visible;
- a system to support negative lighting after a request;
- maybe a proper API to make particles light up (the mod already uses the feature, but I haven't had time to properly design an API around this).
Outside the mod itself, I will also look into Ars Nouveau, as the mod has used its own stripped-down version of the old LambDynamicLights' lighting engine. My goal will be to improve compatibility and integration, I've already started work on it.
I also have a Throne page now. If you want to support me and allow me to continue to provide quality updates to LambDynamicLights and my other mods, I would appreciate it!
Why now? And why not earlier?
Initially, LambDynamicLights has gotten some forks, which, at first, only focused on porting the mod to Forge/NeoForge. Back then, it was just Forge, and I've focused my efforts on Fabric, especially due to preferring the platform. When we were actually building OptiFine alternatives, the platform of choice was Fabric, especially since Forge still had OptiFine despite its issues.
However, this changed last year as I've gotten huge delays to update the mod (see my LambDynamicLights v3 blog post for reference). The forks had started moving forward without upstream and making Fabric ports. One publishing to Fabric only weeks away from the official LambDynamicLights v3 update. As I was reevaluating my approach to how I license my mods, this has blindsided me, as I planned to give out permission to continue updating the NeoForge fork. Of course, this has broken the hope I had and forced me to change how I approach the multiplatform problem.
My issue with the forks that updated before upstream is that they have not made any attempts at helping me port the upstream mod; instead short-circuiting it entirely, and they've done a bad job: I've witnessed quite a share of bugs unique to these forks.
This has also put LambDynamicLights v3 in a difficult spot: the API had to evolve, it was stuck with a very bad design, and it prevented the internals of the mod from properly improving. I've tried very hard to not break the API contract within the same Minecraft version, which is (or should be) a common philosophy in loaders/APIs. But those forks have essentially forced me to make breaking API changes that would be incompatible with them. I am sorry to API users who've had to deal with this mess.
Someone approached me to make a NeoForge-only fork, which I've appreciated, though it has ceased updating, and I can't blame that. This has led me to actually look into properly making the API JAR usable directly on NeoForge, to make sure the fork would keep the same API contract. It was easy since the API JAR already was not dependent on any loader-specific features, and used Yumi Commons' events for the few events it has. The Fabric-style entrypoint is also easy to re-create on NeoForge.
Ever since, I've spent a lot of time working on new tools to ensure the mod would work properly on NeoForge using Sinytra Connector as well, going as far as abstracting as much as possible some loader-specific features and making a new entrypoint system inspired by Fabric while working with NeoForge mods, allowing NeoForge mods to interoperate with LambDynamicLights using the new API.
However, even with the API JAR now properly multiloader, this has not led the previous forks to seek a solution or to resolve the API disparity. This has led to a big mess on NeoForge, with mods looking into dynamic lighting getting hit by a wall where the most feature-complete and optimized option is not native to their platform, and the forks being severely behind with a diverging API.
I think true multiloader support is one that also has in mind Sinytra Connector and actually looks into how to make an API multiloader if it provides one. Though Sinytra Connector is only the cherry on top, in LambDynamicLights' case the whole cake was still missing on NeoForge. For example, LambDynamicLights could not be easily searched for in launchers when targeting NeoForge, and websites do not give me the ability to properly mark a loader-specific dependency.
Now my efforts into building the tooling I sought have paid off; all the libraries I've been using are now working on NeoForge natively as well. LambDynamicLights on NeoForge is finally feasible without sacrificing my development ergonomics. It is clear that there is a demand, and it would be stupid now that I have the tooling to let the situation fester any longer.
tl;dr I first had no interest, then NeoForge dynamic lighting became a mess, and I have the tooling now.
Downloads
1.21.8
1.21.5
1.21.1
Closing Words
Thank you for your support and have fun! I am really excited to see how the mod will be integrated on NeoForge!
