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

Fluid crafts | Draft #1396

Draft
wants to merge 5 commits into
base: 1.20.1
Choose a base branch
from

Conversation

NicholasBaldwinSE
Copy link
Contributor

What

This PR adds a Vanilla-styled recipe type that allows draining of fluids from a container with a fluid handling capability.

Implementation Details

2 main classes, both made for the main recipe, with 2 tweaked files for testing. The names of the classes are definitely subject to change and probably should be more generic, as these are a bit strangely named I'll admit. Currently, can only handle fluid of one type and amount (but as a byproduct if multiple inputs are defined with tanks, it would drain the same amount from them all I believe).

There is also a temporary tweak in VanillaRecipeHelper that makes the character l be replaced with the Bronze Drum, mostly for testing. Note: This currently only works with the bronze drum, as I couldn't think of a way to make it more generic (Consider this a TODO of this draft).

Outcome

Adds a recipe type that allows for fluid aware crafting recipes.

Additional Information

This doesn't count buckets as "Holding fluids". It probably could given some tweaking, but I don't really know if it particularly matters all that much. Probably up for discussion. There was also lots of copy-pasting quite a bit of boilerplate for the builder and in the vanilla recipe helper (might be worth shifting stuff around in there to make it neater). The actual check and draining seem to work fine, and the serialization and networking appear to work correctly, but I'll defer the better specifics to others.

Potential Compatibility Issues

For basically every FluidStack, I defaulted to using LDLib's as it seemed to be the preferred method. However, lots of the current methods used want or return Forge FluidStacks, so long -> int casts are common and could cause issues down the line for containers that are used that actually need the extra space of a long. Implementing helper functions that better handle these cases could probably help with this culling of precision in the future, if it's needed (though in its current form, like one recipe uses this and it sticks around till you make an LV machine that makes the recipe either so my blood, sweat, and tears went towards like 5 extra minutes of convenience at most already).

I also forgot to ran spotless before this. I'll run it again in a bit to fix any complaints it might have. Same with culling imports, eventually.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant