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.
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 8from 8default:paper, and a recipe to convert back eachehlphabet:blockinto adefault:paper: withmoreblocksredefinitions, the “back to the raw material” craft is pumped up, meaning you can go throughehlphabet:blockto 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.