-
Notifications
You must be signed in to change notification settings - Fork 204
Update to MUI 3.0.6 and generify recipe transfers from JEI #2900
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
base: master
Are you sure you want to change the base?
Conversation
… entries that had their key or value GC'd unlike the WeakHashMap
ALongStringOfNumbers
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are two mixins that can be removed when updating MUI2, BigIntAdapter, and TextWidget.
One thing that your new system does not handle that the old system handled was the recipe category Uid. This was used to prevent recipes from being transfered into any GUI. For example, to prevent machine recipes from being transferred into the crafting station, or prevent pages like the material tree page from being transferred. The system should optionally take in one of JEI's Uids, or just allow all transfers if not specified. (Although I would still want to exclude pages like the material tree or ore page from being transferred somehow).
| public class GregTechGuiScreen extends ModularScreen implements RecipeViewerRecipeTransferHandler { | ||
|
|
||
| // Stores lists of higher priority recipe receivers to the left of the tree | ||
| @SideOnly(Side.CLIENT) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The class is already annotated side only client, do we need to annotate this field as well?
| if (!recipeLayout.getRecipeCategory().getUid().equals(VanillaRecipeCategoryUid.CRAFTING)) { | ||
| JustEnoughItemsModule.transferHelper.createInternalError(); | ||
| } else if (simulate) { | ||
| // TODO: highlight missing items in recipe viewer |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this missing items from the players inventory, the crafting station inventory, or both? Because one of the possible error returns you list in IRecipeTransferReciever seems to do what this todo mentions. Can we just use that error here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
missing items in the crafting station's inventory or connected inventories. we would need to iterate the recipe ingredients to see if we have them to return a missing item error
| if (!recipeLayout.getRecipeCategory().getUid().equals(VanillaRecipeCategoryUid.CRAFTING)) { | ||
| JustEnoughItemsModule.transferHelper.createInternalError(); | ||
| } else if (simulate) { | ||
| // TODO: highlight missing items in recipe viewer |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
missing items in the crafting station's inventory or connected inventories. we would need to iterate the recipe ingredients to see if we have them to return a missing item error
| public @Nullable IRecipeTransferError receiveRecipe(@NotNull IRecipeLayout recipeLayout, boolean maxTransfer, | ||
| boolean simulate) { | ||
| if (!recipeLayout.getRecipeCategory().getUid().equals(VanillaRecipeCategoryUid.CRAFTING)) { | ||
| JustEnoughItemsModule.transferHelper.createInternalError(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this needs to be returned
| for (Map<String, IRecipeTransferReceiver> subMap : registeredRecipeTransferReceivers.values()) { | ||
| if (subMap.containsKey(key)) { | ||
| throw new IllegalArgumentException( | ||
| "Tried to register a recipe transfer receiver to a key that's already used!"); | ||
| } | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
perhaps we could have a set of names to check against faster instead of iterating the all the maps in priority?
| private static final Int2ObjectMap<Map<String, IRecipeTransferReceiver>> registeredRecipeTransferReceivers = new Int2ObjectAVLTreeMap<>( | ||
| IntComparators.OPPOSITE_COMPARATOR); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i feel like there could be a better way of doing this instead of a nested map, perhaps a combining the string key and priority in an inner class or a Map<String, SortedSet<IRecipeTransferReceiver>> if you add priority methods to the receiver interface
What
Title.
Implementation Details
A widget or sync handler that wants to receive a recipe from JEI now registers itself to our
GregTechGuiScreen. Unfortunately the map has to be static as there is no way to get the screen from a sync handler.Outcome
JEI transfers are easier now and a couple things are fixed by MUI 3.0.6.
Additional Information
Should multiple receivers be allowed to exist on the panel? Or should it just be one.