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

Recipe Support #7150

Open
wants to merge 41 commits into
base: dev/feature
Choose a base branch
from

Conversation

TheAbsolutionism
Copy link
Contributor

@TheAbsolutionism TheAbsolutionism commented Oct 16, 2024

Description

This PR aims to add support for recipes including:

  • BukkitClasses#Recipe
  • SkriptClasses#RecipeType
  • DefaultComparators#RecipeType->RecipeType
  • CondDiscoveredRecipes
  • CondRecipeExists
  • EffDiscoverRecipe
  • EffRemoveRecipe
  • EffResetRecipes
  • ExprAllRecipes
  • ExprGetRecipe
  • ExprRecipeCategory
  • ExprRecipeCookingTime
  • ExprRecipeExperience
  • ExprRecipeGroup
  • ExprRecipeIngredients
  • ExprRecipeKey
  • ExprRecipeKeyConverter
  • ExprRecipeResult
  • ExprRecipeType
  • SecRegisterRecipe
  • Utils#NamespacedUtils
  • Utils#RecipeUtils

Target Minecraft Versions: any
Requirements: none
Related Issues: #5261

@Fusezion

This comment was marked as resolved.

Copy link
Contributor

@Fusezion Fusezion left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So uuh thinking about moving this to a module?

@TheAbsolutionism
Copy link
Contributor Author

So uuh thinking about moving this to a module?

nada

src/main/java/ch/njol/skript/util/RecipeUtils.java Outdated Show resolved Hide resolved
@Efnilite Efnilite added the feature Pull request adding a new feature. label Oct 16, 2024
src/main/java/ch/njol/skript/util/RecipeUtils.java Outdated Show resolved Hide resolved
src/main/java/ch/njol/skript/util/RecipeUtils.java Outdated Show resolved Hide resolved
src/main/java/ch/njol/skript/util/RecipeUtils.java Outdated Show resolved Hide resolved
Copy link
Contributor

@Fusezion Fusezion left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I decided more changes were needed, we're aiming for 100

@Fusezion
Copy link
Contributor

I mentioned it to smurf once, but mentioning it in the pr itself will be good, what's the thought about a proper RecipeChoice implementation to have more support of ingredients.

If this goes through a custom ItemTypeChoice should be created to enable skript's item types correctly and not converting to an itemstack always.

This should be pretty safe due to the fact recipes and these can't be serialized by default

Copy link
Member

@Efnilite Efnilite left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

almost there

Copy link
Member

@sovdeeth sovdeeth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

partial review

@TheAbsolutionism
Copy link
Contributor Author

well i should be able to treat a mutable crafting recipe the same as a crafting recipe
hence they should have the same interface, and it would allow it to pass instanceof CraftingRecipe

So, I tried to have the subclasses extends their respective Bukkit recipe class, but unfortunately it wont let me.

@sovdeeth
Copy link
Member

well i should be able to treat a mutable crafting recipe the same as a crafting recipe
hence they should have the same interface, and it would allow it to pass instanceof CraftingRecipe

So, I tried to have the subclasses extends their respective Bukkit recipe class, but unfortunately it wont let me.

ah are they final?

@TheAbsolutionism
Copy link
Contributor Author

ah are they final?

It just says "Class can not extend multiple classes"

@sovdeeth
Copy link
Member

ah are they final?

It just says "Class can not extend multiple classes"

oh right the sub recipes aren't interfaces

src/main/resources/lang/default.lang Outdated Show resolved Hide resolved
providedName = (Expression<String>) exprs[1];
AtomicBoolean delayed = new AtomicBoolean(false);
Runnable afterLoading = () -> delayed.set(!getParser().getHasDelayBefore().isFalse());
trigger = loadCode(sectionNode, "register recipe", afterLoading, providedType.getEventClass());
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ideally you could check the trigger for the required things like result/ingredients and error during parse if they're missing entirely.
Unsure how doable that is.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, if it was possible, personally, I feel like it's not worth the effort. Presumably, I would only be able to check what expressions are used within the trigger. But there's no guarantee I could safely identify if the conditions required for those expressions are being met. Also, it would just make a whole mess within the init for the section. In my opinion atleast.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

well you wouldn't do it in the init of course
it'd be a helper method
and it wouldn't be a foolproof thing, just a first line of defence

Copy link
Member

@Efnilite Efnilite left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

on the way to most commented pr 💪

# Conflicts:
#	src/main/java/ch/njol/skript/Skript.java
#	src/main/resources/lang/default.lang
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature Pull request adding a new feature.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants