Data-Driven Rituals

[PssbleTrngle]

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

[PssbleTrngle]

I've just seen that ritual ingredients can be changed using crafttweaker

[PssbleTrngle]

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

[Mrbysco]

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

[PssbleTrngle]

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

[PssbleTrngle]

And of course, the stone positions would also have to be reflected in the json file, which is definitely possible

[Mrbysco]

the stone positions is the sole reason I decided against making it json based, as the more data the bigger the syncing packets

[PssbleTrngle]

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" 
}

[Mrbysco]

The default locations it sets based on level are already kind of a template

[PssbleTrngle]

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"
}

[PssbleTrngle]

And then either use the block positions based on the level or an additional template property

[PssbleTrngle]

By the way, is there an actual reason why the ritual ingredients are defined as ItemStacks and not Ingredients? Because I would probably change that in that implementation too

[Mrbysco]

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

[PssbleTrngle]

It' coming along nicely, but required a lot of changes in the entire project

[PssbleTrngle]

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.

Looks like this:

[PssbleTrngle]

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?

[Mrbysco]

Haven't really found the time yet, it also doesn't help the Pr is huge