GeckoLib 4.5 Changes

Updating to GeckoLib 4.5

GeckoLib 4.5 was a moderately sized update to the library, mostly focused on moving to a Multiloader setup, but additionally focusing on further optimizing the runtime efficiency of the library, and streamlining the developer-facing API to make it even easier and more intuitive to use.

NOTE: GeckoLib 4.5 is for Minecraft 1.20.5 and above. Some of its changes will be backported to 1.20.1, but the Multiloader deployment and other major features will not be.

From a developer's perspective, there shouldn't be a lot to change with exception to a few renamed methods or classes. Depending on the contents of your mod however, you might find some additional changes to account for. The below summary is not a comprehensive rundown of every change made, but it should cover most use-cases.

Table of Contents

• Multiloader
• Error Logging
• GeckoLib Examples
• Molang/McLib
• RenderProvider

Multiloader

The primary goal of 4.5 was to move the entire library to Multiloader. This is a long-requested change from developers, and additionally will help us maintain the mod with consistency. I'll spare you most of the details of the move here, but suffice to say that virtually the entirety of the mod was moved to multiloader, including all of its event and networking handling.

This means that from a developer point-of-view, you should be able to achieve virtually anything you want to in your common module without need for specialty GeckoLib handling in any platform module!

Error Logging

With GeckoLib 4.5 comes a whole host of improved error logging, particularly in file/resource loading.

Now, when an error is found in loading, GeckoLib will tell you exactly which file is responsible, and will drill down into the details, including which animation the error is in and the line it comes from and why, or if your file is just in the wrong directory.

This should significantly improve debugging on those more abstract resource file issues.

GeckoLib Examples

Historically, GeckoLib has bundled a suite of examples into itself for developers to refer to, and for GeckoLib itself to test on in development. This has proved to have a few fairly major flaws however, which I wanted to rectify as part of the move to Multiloader:

1. It doesn't account for testing of maven issues, artifact problems, or other platform/gradle issues that arise in dev
2. It doubles the size of the resultant mod with assets and code that will never be seen or used
3. It deliberately injected the examples into dev-space, requiring some users to need to disable them manually in order to work without them.
4. It requires additional handling & specialty work in GeckoLib itself, for something that it doesn't even need to care about in production.

To this end, I have fully stripped all of the examples from GeckoLib's primary artifacts, and have instead moved them to their own repository, which includes a branch for each major platform, as well as a multiloader deployment. This allows us to properly exemplify usage of GeckoLib without additional mess, and makes it easier for you to see how it works

Molang/McLib

Since the beginning, GeckoLib has relied on (and subsequently bundled) a fork of McLib to handle its json mathematical expression parsing and by extension; its Molang handling.

This has worked ok, however it has proved to be somewhat problematic in a few key areas:

1. It has caused users on some platforms (Forge) to need to manually depend on that library if they wanted to work with that area of the mod themselves
2. It was virtually unworkable in terms of modifications for GeckoLib's usage and improvements
3. It wasn't well designed for things like Molang to begin with

In 4.5, I completely rewrote the mathematical parsing for GeckoLib, heavily optimizing it (most computations are now done in a single pass instead of 10+), and building it for Molang extensibility and developer usage.

From a user perspective, there should be very little difference, however I will still note a few things of interest:

• MathBuilder was renamed to MathParser with the original MolangParser being collapsed down into it
• IValue was functionally renamed to MathValue
• All functions are now memoized except where the values it contains cannot be memoized (Molang queries, etc)

Over time I plan to add more Molang queries and functions to GeckoLib, so for those who are interested in those, stay tuned!

RenderProvider

RenderProvider was GeckoLib 4's equivalent to Forge's IClientItemExtensions, allowing GeckoLib to do dynamic armor and item rendering right in the item class, providing a powerful and easy to use interface for GeckoLib handling.

It has been further improved in GeckoLib 4.5, with the following changes:

• It is now multiloader, and can be used on any platform, including native support for Sinytra Connector
• createGeoRenderer (formerly createRenderer) is now properly typed. No more Consumer<Object>!
• The need for makeRenderer and getRenderProvider in your item class has been eliminated. Now you can just override createGeoRenderer as before, and the rest is handled automagically for you!
• Most of the interface has had its names cleaned up to be more clear:
  • RenderProvider -> GeoRenderProvider
  • createRenderer -> createGeoRenderer
  • RenderProvider#getRenderer -> GeoRenderProvider#getGeoItemRenderer
  • RenderProvider#getHumanoidArmorModel -> GeoRenderProvider#getGeoArmorRenderer
  • RenderProvider#getGenericArmorModel removed as it wasn't used for anything useful (confusingly)
• The entire interface should now function even for non-GeckoLib rendering. Meaning you can use GeckoLib on platforms like Fabric to do nicer & more powerful armor/item rendering even if you don't want to use GeckoLib models
• The prepForRender call is no longer needed on GeoArmorRenderer, GeckoLib handles this automatically for you

Closing Words

Overall, GeckoLib 4.5 represents a sizeable cleanup of the library once again, but hopefully shouldn't impact you as a user too much beyond a few renames

Enjoy!