[Feature] Datapack-driven "Custom" Crystallrieum Buds

[eehunter]

I've been thinking about how to implement this for a while, and I'm now working on a KubeJS plugin for Spectrum that will do so, but I figured I should also add it as a suggestion for the base mod. I was thinking that there should be a way to make custom buds for various resources via datapacks. Of course, using datapacks to add custom blocks is effectively impossible, which led me to think of a couple different ways to do it. One would be a block with an integer property that could be assigned to specific resources by a datapack. Another would be a bud with a custom BlockEntity that would track what resource it was assigned to and display the appropriate texture. This, of course, would be trickier to implement due to the dynamic texture loading, but should still be doable, and would be a more "proper" way to go about doing it, since it wouldn't put an arbitrary cap on the number of resources that could be used.

[DaFuqs]

Ideally, a small mod that adds the resource buds will be the most effective and also performant.

Of course not every modpack maker is able to do basic coding, so having it via KubeJS may be an option. Is there something that can't be done with KubeJS, already? Adding blocks, drops and all that should be easy, though a bit tedious.

[eehunter]

It can certainly be done with KubeJS. The method I was thinking of implementing in my plugin would simply be a shorthand. The unfortunate side effect is that it would either require excessive numbers of blockstates to be registered (and thus be programmatically inefficient) or require the use of startup scripts, which have to be basically identical on both the client and server in order to function (so harder to update if changes need to be made on a private server with a lot of people). The more I consider it, the more I suspect the latter would still likely be the best option. Though it might still be a good idea for the Crystallerieum to support different blockstates for buds, if it doesn't already? Like having the bud/cluster be registered as a single block with three different blockstates?

[eehunter]

I think I might just add a startup script function that adds "small_bud", "large_bud", "cluster", and "pure" variants of an arbitrary resource, and then a similar shortcut for adding Crystallrieum and Cinderhearth recipes.

[eehunter]

I haven't made too much progress on making this datapack/KubeJS driven, but Spectral Utilities now has helper functions that, once I'm finished working on them, will allow one to register a new crystallarieum recipe with as few as three lines of code. One line creates a CrystallarieumMaterial object, which in turn registers any blocks and items necessary for the recipe. The other two generate the block (and item) models, and the loot tables, respectively. Textures are also needed, of course. But once this is done, adapting it to a KubeJS plugin should be pretty easy. Though unfortunately this system I've designed is reliant on certain features specific to the Kotlin language for its sleek design, and will look incredibly clunky if used in Java. This mainly means that the "three lines" required would each be extremely long if written in Java.

Edit: Make that four lines, I forgot about the recipe generator.

[DaFuqs]

I looked at this one again.

Since blocks have to be loaded at startup and datapacks are only evaluated at world load, a datapack solution will not work.

Adding a specific field in the mod config file works, since that can be read at startup. But if client<=>server config differ, that would inevitably break, too.

KubeJS definitely seems like a viable approach. (Do they sync server=>client? I do not think they can, since that is handled on join)