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

(1.20.1) Adds Capability for Mods to Register Custom Brewing Fuels #10123

Open
wants to merge 24 commits into
base: 1.20.1
Choose a base branch
from

Conversation

Thomas1034
Copy link

@Thomas1034 Thomas1034 commented Oct 10, 2024

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 the FMLCommonSetupEvent 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.

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.
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
@autoforge autoforge bot added Triage This request requires the active attention of the Triage Team. Requires labelling or reviews. 1.20 Feature This request implements a new feature. New Event This request implements a new event. labels Oct 10, 2024
@autoforge autoforge bot requested a review from a team October 10, 2024 02:17

public class RegisterBrewingFuelEvent extends net.minecraftforge.eventbus.api.Event
{

Copy link
Member

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.

Copy link
Author

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();
Copy link
Member

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?

Copy link
Author

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?

Copy link
Member

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.

Copy link
Author

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();
Copy link
Member

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.

Copy link
Author

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<>();
Copy link
Member

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);
Copy link
Member

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...

Copy link
Contributor

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.

Copy link
Member

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

Copy link
Author

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.
Update ConstructorThrowTest.java (Oops)
@Thomas1034
Copy link
Author

I've updated the pull request to address the concerns mentioned above.

@Jonathing Jonathing requested a review from LexManos October 14, 2024 00:28
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.
Copy link
Member

@Jonathing Jonathing left a 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.

@Thomas1034
Copy link
Author

I have updated the description as Jonathing requested.

Copy link
Member

@Jonathing Jonathing left a 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.

Comment on lines 7 to 10
- 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_());
Copy link
Member

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.

Copy link
Author

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.

Copy link
Member

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.

Copy link
Author

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.

@Jonathing Jonathing added Assigned This request has been assigned to a core developer. Will not go stale. and removed Triage This request requires the active attention of the Triage Team. Requires labelling or reviews. labels Nov 2, 2024
@Jonathing Jonathing self-requested a review November 6, 2024 20:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1.20 Assigned This request has been assigned to a core developer. Will not go stale. Feature This request implements a new feature. New Event This request implements a new event.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants