Data-Driven Rituals
PssbleTrngle opened this issue ยท 16 comments
I know this is a big change to implement, but it really is a bummer that ritual recipes are not yet data-driven in any way.
Even only being allowed to change the ingredients would be a great feature for modpack developing.
I am willing to implement this an open a PR if I manage to make it work, if this is a feature you consider
Ok nevermind, it seems like you are replacing rituals with a registry-based approach which makes this a lot harder/not as reasonable to implement
It's still a possibility and I've dabbled in the past to see if I should make it a custom recipe type but I originally decided against it due to standing stone positions. But I've since realized that there's defaults in place based on the level supplied so that makes it do-able
I think I will try to seperate the "recipe" of a ritual and it's execution + stone position checking tomorrow and report back if with a hopefully working pull_request.
Something like this is what I am thinking about:
{
"type": "rootsclassic:ritual",
"level": 2,
"red": 0.85,
"green": 0.3,
"blue": 0.2,
"ingredients": [...],
"incenses": [...],
"result": {
"item": "minecraft:command_block"
}
}
{
"type": "rootsclassic:ritual",
"level": 2,
"red": 0.85,
"green": 0.3,
"blue": 0.2,
"ingredients": [...],
"incenses": [...],
"effect": "rootsclassic:cause_rain"
}
And then either use the block positions based on the level or an additional template property
By the way, is there an actual reason why the ritual ingredients are defined as ItemStack
s and not Ingredients
? Because I would probably change that in that implementation too
I've implemented it partially in a fork, where I am now able to add new crafting rituals (with the default stone positions).
To really make this work though, the existing rituals would have to be moved to json files as well, which would require a seperation between the actual effect of a ritual and it's recipe.
I think it would be reasonable to keep the "effect" of a ritual as RegistryObjects, then a ritual json could either specify an effect ID, or a result item
And of course, the stone positions would also have to be reflected in the json file, which is definitely possible
the stone positions is the sole reason I decided against making it json based, as the more data the bigger the syncing packets
Maybe instead of storing the stone positions in the json file, there could be "templates" for them that are referenced in the code, so you would just do something like
{
"type": "rootsclassic:ritual",
...
"stone_positions": "crafting"
}
Maybe a leftover from the ways of the past. I know for mortar recipes there was some justification as certain items apply certain properties meaning they shouldn't be part of the regular recipes
I thought the JEI recipes for non-crafting rituals looked a bit weird because there is no output, so I came up with the idea to add a little info text below that says what the ritual is about in that case.
I'll push the changes to the 1.19 PR and if you think it makes sense I can apply them to the 1.18 PR too.
Hey, I was just wondering if you were are waiting for me to do something or if you have just not found the time yet?