Enchantment Upgrade Reachitecture

[Azzyypaaras]

Rewrites enchantment upgrade recipes to actually function in 1.21.1, and also just generally be less goofy? Some flexibility is sacrificed in favor of a much more robust system that shouldn't implode every major version bump - or you know, any time PissJS sneezes.

Comes with a side of RecipeScaling.java.exe.sex (free, download now no virus!!!)

This is, as of now, a Draft because there are some unanswered questions.

1. I want feedback for the new internals before I go and rewrite the rest of the two billion ench upgrade jsons.
2. The recipe displays are an elephant in the room, as I frankly have no idea how they should be formatted given the changes.
3. bwaaaaaaa

[Noaaan]

Overall this rework looks much better than the former system. To address your points:

1. Rewriting the recipes is redundant, as they should be generated once we merge in datagen. It might make sense to merge that in first, as the method/builder for it needs to be updated regardless.

2. There are a couple of ways to do this. Both REI and EMI can give you recipe access during building, so you could keep the old view intact and just generate multiple recipe views per recipe.

   An alternative is something akin to Alloy Forgery, where you view one recipe but you can cycle between the upgrades. Manually toggling between levels in that regard has drawbacks though (I.E. viewing the recipe of Sharpness 3 is harder, since it would open the recipe for Sharpness in general). You could make it automatically cycle, but that might be more noisy.

[Azzyypaaras]

While Datagen will be a nice thing in the future, I am not sure if holding our breath for it is exactly a great idea currently. The main dev for it (Electro) has gone quiet for a bit; given the way she tends to cycle through things it is unlikely we will see her again for some time. I would rather set them up manually and get this merged instead of waiting overlong.

As for the recipe display thing. I will give look at switching recipe views on a timer. It would match the behavior of a preexisting feature that does something similar - the titty barrel.

[Noaaan]

The future is now, as datagen is about ready for merge. Turns out it was almost finished, so you should save some headaches on not stumbling into comma errors with it 🙂

[Azzyypaaras]

Draft time is joever, it is now ready-ish to merge.

The internals are all functional, but the rest of the recipes do have to be readded. Evidently this will ultimately be done via datagen and as such is... outside the scope of this PR?

[Azzyypaaras]

Oh, oh that is a funny merge. Hm. I am not updating the datagen for this :3

[DaFuqs]

• Having one recipe.json per enchant is nice in a way that it's less likely to break
• The XP scaling is quite a bit harder to understand compared to the previous "always indexed" method. It certainly is more dynamic, so its more difficult to write recipes for without throughoutly studying the docs. Not a dealbreaker, but also a so/so change
• After trying it out not a fan of the current EMI/REI displays. They need some improvements, still
  • the cycling makes it hard to see what exactly you need (especially since there is no way to pause them atm). Personally I'd favor one entry per level more
  • they list the level, but not the enchant (which you can only see by hovering the enchanted book). We could add that info below the recipe to make it quick to see
  • pressing "r" when hovering over enchanted books does not show the recipes anymore
• the spectrum:enchanter_upgrading modonomicon book pages are broken (see Clover's Favor entry for reference)

[Azzyypaaras]

the spectrum:enchanter_upgrading modonomicon book pages are broken (see Clover's Favor entry for reference)

WAIT THOSE EXIST

[DaFuqs]

yes, those exist

[Azzyypaaras]

Also but after looking at how things used to be a bit more I just have to completely disagree. 100 pages of recipes is entirely unnavigable

[Azzyypaaras]

yes, those exist

Done in by modonomicon's shit logging 😔

[DaFuqs]

Depends on how you use the recipe viewer.

My usual user story would be: "I want to be able to see how I can get a sharpness 3 book"

Pull request version:
Pressing "u" on the Sharpness 3 book in EMI leads me to the recipe entry that cycles through all sharpness upgrades (as soon as pressing "u" is fixed").
Now I have to wait for the cycle to show me the level2->3 entry and I would have to look quick enough to see how much pigment I need. Then repeat the same for level 1->2. And a final time catch the timing to press "u" when I see the "sharpness 1" book to see how I can craft that.

Current Version:
Pressing "u" on the Sharpness 3 book in EMI leads me to the recipe entry for Sharpness 2->3. I can note how many Pigment that needs and press "u" on the Sharpness 2 book to lead me to the recipe for Sharpness2->1. Repeat another time to show the display how to craft a sharpness book.

Especially for people that are a bit slower, not having to catch the right timings might be a big deal.

[Azzyypaaras]

That is a fair view. I did mention I wanted to integrate a way to pause cycling.

There is a small issue where uh, I am 99% sure only EMI has the internals to support that. REI has quickly proven to be a lot less flexible

[DaFuqs]

You know, we look at many things daily and wonder why they are written that cursed and it certainly could be improved.

Sadly most things have a reason why they were written as cursed as they are. This is the "why" for the enchant upgrade recipes (pain)

[Azzyypaaras]

Hmph, that is true. At the same time though we are coming up with the question of maintainability vs ideals and... frankly maintainability wins out here imho.

I can see the case for how things were, but I believe that with some work most of the issues at hand can be suitably addressed. May require I do something funny with the recipe viewers tho.

[DaFuqs]

Yeah, I am sure we can come up with a nice way to handle the recipe viewers with the new way the recipes are implemented. It certainly is a big improvement once that is done.

[Azzyypaaras]

Perhaps I should look into the button idea again...

[DaFuqs]

The UX with the button variant is really nice. I like it a lot!

A few things are still broken (all tested with EMI):

1. the recipe view lists the pigment stacks always in the amount of the first level

• Big Catch 1->2 shows 8 stacks of 4 pigment each, mentions (32x)
• Big Catch 2->3 shows 8 stacks of 4 pigment each, mentions (128x)

2. Recipe lookup using "r" or "u" hotkeys in recipe viewers is still broken

• "r" on a level 1 book brings up the crafting recipe ✅
• "r" on a level 2 book does nothing 🅾
• "r" on a level 3 book brings up the crafting recipe for level 1->2??? 🅾
• "r" on any level above that does nothing 🅾

3. The indexed scaling mode does not generate recipes, if the enchant has more levels (for example by using a data pack) than there are indexes (kinda expected, so not really a bug)
4. I bumped the level of Big Catch up to 8 and changed item_scaling and xp_scaling to 8, but the recipe was still capped at level 3.

• instead of being fetched from the enchants max level, this is controlled by the level_cap entry in the recipe.json. But why?

5. Using a data pack to increase an enchants max level, Recipes using non-indexed scaling will end up requiring more Pigment than the Enchanter can hold. Do we want to catch this case somehow?

6. I got this funky result:
   

using this json

{
  "type": "spectrum:enchantment_upgrade",
  "bulk_item": {
    "item": "spectrum:light_blue_pigment"
  },
  "enchantment": "spectrum:big_catch",
  "item_scaling": {
    "type": "spectrum:doubling",
    "scaling_factor": 2.2,
    "scaling_value": 4
  },
  "level_cap": 3,
  "required_advancement": "spectrum:unlocks/enchantments/big_catch",
  "xp_scaling": {
    "type": "spectrum:doubling",
    "scaling_value": 200
  }
}

7. the used codec does allow negative values
   

8. The Modonomicon page does not actually list the enchant
   

[imreallybadatnames]

Steve Jobs died of Ligma.