Disabled recipes no longer count towards recipe limit

[uecasm]

Closes discord thought

Changes proposed in this pull request

• Disabling a built-in recipe causes it to no longer count against the building's recipe limit.
  • e.g. a level 1 Cookery currently has 22 crafterrecipes, but a limit of 10. If you disable all the built-in recipes it will be back to 0/10 and you will be able to teach 10 other recipes.
• But you cannot enable a built-in recipe if you're already at or above the limit.
  • which does mean that if you disable any recipe in the level 1 Cookery you won't be able to enable it again until you disable enough other recipes to bring it down to 9/10 or below. Or upgrade the hut/do research to increase the limit.
  • doing a research or upgrade that unlocks a new recipe is permitted to exceed the limit, as before.

Testing

• Yes I tested this before submitting it.
• I also did a multiplayer test.

Review please (should port)

This is overall intended as a rebalance to make crafterrecipes (especially from datapacks) less likely to completely "starve out" a low-level crafter and make it impossible to teach additional recipes. But the player is still forced to pick and choose, apart from automatic additions.

[Thodor12]

An overall thought about our code, in how far do we want to rely solely on client side validations to ensure everything is valid.

I'm always used that (outside of here) that you want to double up client and server side validations.

[uecasm]

That's true, usually you should. I kinda deliberately didn't here because the consequences aren't all that bad (it just means the pre-PR behaviour still holds).

In order to actually exploit that you'd have to be running a modified client jar that omitted the check or that forged the packet. Which is not super hard to do with an addon. But why bother?

Now if it was a permissions check or something more serious, you absolutely want that on both sides.

[Raycoms]

Could we have an extra flag for "pre-set recipes" and make them not count to the limit just?

[uecasm]

There kind of already is a preset flag (if it has a recipe id then it's a preset recipe). That's easy on client side since it has the recipe definition but on server side it only has a token so would have to enumerate and look up all the recipes instead of just doing a quick size calculation, so it will have perf consequences.

And I'm not sure that the presets shouldn't count towards the limit, though; they're still something that they can craft so it makes sense that they count -- when not disabled.

[Raycoms]

I think, I would store on the serverside some additional information together (e.g. if preset) and then not count these towards the limit. So, we can have it fast on both sides. What do you think @someaddons ?