-
-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
(1.20.1) Adds Capability for Mods to Register Custom Brewing Fuels #10123
base: 1.20.1
Are you sure you want to change the base?
Conversation
Added a constructor that takes in a block entity type. This allows mods to create their own hanging sign block entities without needing to implement their own rendering methods for the GUI, use mixins, or attempt to hardcode the getter methods. See net.minecraft.client.player$openTextEdit(net.minecraft.world.level.block.entity.SignBlockEntity, boolean) for the reason this would be useful - to render the GUI for a hanging sign, the block entity needs to extend HangingSignBlockEntity.
Partially done.
…m/Thomas1034/MinecraftForge into 1.20.1-extensible-hanging-sign-be
1.20.1 - Import Changes
Also removed extra line in the event class.
Fixed accidental comment out
Why won't GitHub work right?
(1.20.1) Adds Capability for Mods to Register Custom Brewing
|
||
public class RegisterBrewingFuelEvent extends net.minecraftforge.eventbus.api.Event | ||
{ | ||
|
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.
Our new code style is to have braces on the same line, so please do that.
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.
Understood. I was wondering if the "how to contribute to forge" document I found might be a little out of date... guess so. It's here if you want to take a look.
import net.minecraft.world.item.alchemy.PotionUtils; | ||
|
||
public class BrewingStandMenu extends AbstractContainerMenu { | ||
+ private static final net.minecraftforge.common.BrewingFuelValues BREWING_FUELS = net.minecraftforge.common.ForgeHooks.onBrewingFuelRegisterEvent(); |
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 fires the event during the static initializer of the brewing stand menu, this is not a good place for that. A better place would be to make it part of the registry events, Or perhaps instead of making it a custom registry implementation. It could be data driven and use the syncing mechanics of the custom data registries?
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'll look into those and see if I can find a better way. One thing, though: you mentioned on Discord that using tags would not be the best idea - wouldn't making it data driven have the same problems with vanilla server/Forge 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.
Quite possibly, it would need testing and a way to verify that connecting to vanilla servers behaves fine.
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'm having trouble figuring out how to use the custom data registries. Are there any existing examples I could take a look at?
Since I've been so far unable to figure that part out, I've been working on a different approach. I reworked the brewing fuel values class to pattern it off of the BrewingRecipeRegistry
class; thus, instead of having its own event, mods can add values to a static map in the FMLCommonSetupEvent
. This version does not require adding an event, requires only minimal changes to other Forge classes, and matches the existing way of adding behaviors to the brewing stand.
import net.minecraft.world.level.block.state.BlockState; | ||
|
||
public class BrewingStandBlockEntity extends BaseContainerBlockEntity implements WorldlyContainer { | ||
+ private static final net.minecraftforge.common.BrewingFuelValues BREWING_FUELS = net.minecraftforge.common.ForgeHooks.onBrewingFuelRegisterEvent(); |
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 again has the static initializer issue. But also you're firing the event twice, once here and once in the menu. Better is to find a way to fire it once and use it in both places.
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 resolved this by making BrewingFuelValues
work in a static way, like how BrewingRecipeRegistry
does. This should make things simpler for both players and maintenance.
|
||
public BrewingFuelValues() | ||
{ | ||
this.fuelTimes = new Object2IntOpenHashMap<>(); |
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.
As this takes no values from the constructor it can be done in the field initializer.
*/ | ||
public int get(Item fuel) | ||
{ | ||
return this.fuelTimes.getOrDefault(fuel, VANILLA_FUEL_TIME); |
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 would make any item not registered return the default. I dont think this is good api...
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 idea was that items tagged as brewing stand fuel would be whatever the default is, and can be overriden via this method.
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.
Yes, but that is not what this method does, thats what the add(Item) overload does.
Change this to getOrDefault(fule, 0)
and get rid of hasFuel
in favor of get(item) != 0
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.
Understood, I'll fix that. Thank you for your input.
Also drastically simplified the way it worked, and removed the (now unnecessary) event and hook.
Updated to address concerns.
Update ConstructorThrowTest.java (Oops)
I've updated the pull request to address the concerns mentioned above. |
In the previous commit, patches were not generated correctly; apparently, it took in excess of five minutes for Git to realize the patch files had changed after the task had finished, so the previous commit did not include them.
Fixed Patches
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.
Please update the PR description to account for the changes made in recent commits.
I have updated the description as Jonathing requested. |
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 love this PR. Incredibly clear, efficient, and does what it needs to do well. I have a few nitpicks, but after that I think it's good for merge. I will handle backports for relevant versions.
- if (p_155289_.f_58979_ <= 0 && itemstack.m_150930_(Items.f_42593_)) { | ||
- p_155289_.f_58979_ = 20; | ||
+ if (p_155289_.f_58979_ <= 0 && (itemstack.m_150930_(Items.f_42593_) || net.minecraftforge.common.BrewingFuelRegistry.get(itemstack.m_41720_()) != 0)) { | ||
+ p_155289_.f_58979_ = net.minecraftforge.common.BrewingFuelRegistry.get(itemstack.m_41720_()); |
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.
You should move BrewingFuelRegistry.get()
to its own variable. This will avoid calling it twice, along with the parameters which also include method calls.
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've fixed that. I'm not sure why I didn't have it do that originally.
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.
Please add a way to clarify in this file that you can only add to this once FMLCommonSetup
has been fired.
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've updated the comments to indicate that it should only be manipulated during the FMLCommonSetupEvent
.
Updated comments and moved get() into variable
It is currently impossible to make brewing stands accept alternate fuels in 1.20.1. This pull request fixes that problem. It adds a new class,
BrewingFuelRegistry
, which allows mods to associate an item with a brewing stand fuel value. Brewing fuels - like brewing recipes - can be added to the registry during theFMLCommonSetupEvent
event.I have also confirmed that this works with hoppers; they can correctly insert new fuels.
A test mod is included, verifying that both custom items and vanilla items can be added as fuels.
Please let me know if there are any problems I should address with this pull request.