Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide some way to select which recipes should be overloaded #172

Open
Oblomov opened this issue Jan 5, 2021 · 5 comments
Open

Provide some way to select which recipes should be overloaded #172

Oblomov opened this issue Jan 5, 2021 · 5 comments
Labels

Comments

@Oblomov
Copy link
Contributor

Oblomov commented Jan 5, 2021

With the changes introduced by #169 we have a very powerful mechanism to manipulate existing recipes. One could argue that this is a bit too powerful, since the mechanism currently is applied to all recipes that provide a specific items. This can be somewhat game-breaking for items that can be converted back into their raw material, as exemplified by the case (that was also causing a crash) presented in #170: there's a recipe to produce ehlphabet:block 8 from 8 default:paper, and a recipe to convert back each ehlphabet:block into a default:paper: with moreblocks redefinitions, the “back to the raw material” craft is pumped up, meaning you can go through ehlphabet:block to produce extra paper.

Considering that we may want to expose the “production increasing” function as an API, we should consider a way to make it possible to be more restrictive on when the amount change should be put in effect. The specific example can be avoided by skipping shapeless recipes (since the recipes we intend to override are shaped anyway), but a more general (and robust) mechanism should be devised for API purposes.

@BuckarooBanzay
Copy link
Member

One could argue that this is a bit too powerful, since the mechanism currently is applied to all recipes that provide a specific items.

This messes with a lot of mods, just fyi, here farming for example:

yield was 4 before, 12 afterwards

Instead of a blacklist, can't you just do a inclusion/whitelist to include only those that need to be redefined?

@Oblomov
Copy link
Contributor Author

Oblomov commented Jan 8, 2021

Well, the whole point of the change that introduced this issue was to not having to keep the recipes up-to-date whenever they changed in MTG. Whitelisting kind of defeats that. Ideally we'd want some way to know where a recipe comes from, so that e.g. we only override the ones defined in default, but that's not easy. I'm open to suggestions on the best way to balance the things.

(As an aside, I'm not sure I would consider the pumping-up of the farming recipe a bug, since it is in the same spirit as the override of the papyrus recipe from MTG, but of course that's subjective.)

@Calinou
Copy link
Member

Calinou commented Jan 8, 2021

We can probably remove the crafting recipe overrides we currently have in More Blocks. Now that Minetest Game balancing is more fair, it doesn't make as much sense to have built-in recipe overrides.

@Oblomov
Copy link
Contributor Author

Oblomov commented Jan 8, 2021

Hm I can see the point for the signs (the 4 was probably inherited from a time where the default recipe was for a single sign) and for the rails, but the paper from papyrus one is still 4 vs 1. And it's also the one creating problems with the other mods.

@fluxionary
Copy link

#191 entirely removes the recipe overrides. such a feature is not within the bailiwick of this mod(pack).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants