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

IResultFactory or extendable recipe factories #4328

Closed
BlayTheNinth opened this issue Aug 20, 2017 · 3 comments
Closed

IResultFactory or extendable recipe factories #4328

BlayTheNinth opened this issue Aug 20, 2017 · 3 comments
Labels
Stale This request hasn't had an update from the author in a long time.

Comments

@BlayTheNinth
Copy link
Contributor

Currently it seems like the only way of defining a custom result is either making one file for each option and putting excluding conditions in each, or creating your own recipe factory. Problem with the recipe factory is that the existing factories are defined either as lambdas or methods, and are therefore not extendable (meaning you would have to duplicate the entire code even if all you wanted to change is how the result is parsed).

An easy solution would be moving them into an extendable class with a protected parseResult(JsonObject json, JsonContext context) modders can override in a subclass. A possibly more clean solution would be to provide an IResultFactory that works similar to all the other factories.

As for my use case: my mod Ex Compressum supports multiple Ex Nihilo variants at the same time, which means some of the recipes have to automatically adjust based on what variant is being used. Multiple files with forge:mod_loaded each would work, but wouldn't be very elegant and would exclude the possibility of a mod adding support from their side. Another use case would be recipes that adjust based on configurations or other external factors.

Mockup recipe factory using Solution 1 (extendable default recipe factories):

public class NihiloRecipeFactory extends ShapelessOreRecipe {
    @Override
    public ItemStack parseResult(JsonObject json, JsonContext context) {
        return ExNihiloProvider.getNihiloItem(json.get("value").getAsString());
    }
}

Mockup recipe using Solution 2 (IResultFactory):

{
  "type": "forge:ore_shapeless",
  "result": {
    "type": "excompressum:nihilo_result_item",
    "value": "DUST",
    "count": 9
  },
  "ingredients": [
    {
      "item": "excompressum:compressed_block",
      "data": 0
    }
  ],
  "conditions": [
    {
      "type": "excompressum:has_nihilo_item",
      "value": "DUST"
    }
  ]
}

I can PR either solution once I know which would be preferred.

@loordgek
Copy link

i vote for the IResultFactory

@stale
Copy link

stale bot commented Feb 19, 2018

This issue has been automatically marked as stale because it has not had activity in a long time. If this issue is still relevant and should remain open, please reply with a short explanation (e.g. "I have checked the code and this issue is still relevant because ___." or "Here's a screenshot of this issue on the latest version"). Thank you for your contributions!

@stale stale bot added the Stale This request hasn't had an update from the author in a long time. label Feb 19, 2018
@stale
Copy link

stale bot commented Mar 5, 2018

This issue has been automatically closed because it has not had activity in a long time. Please feel free to reopen it or create a new issue.

@stale stale bot closed this as completed Mar 5, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Stale This request hasn't had an update from the author in a long time.
Projects
None yet
Development

No branches or pull requests

2 participants