Closed DenyCrafty closed 6 months ago
just had a go at the alternative, you can grab the "artifact" from the actions build to give it a try (let me know if you need it for another version in 1.20.something)
couple months ago some ideas were thrown around in the discord, conclusion basically was: something with more controller convenience is needed
just had a go at the alternative, you can grab the "artifact" from the actions build to give it a try (let me know if you need it for another version in 1.20.something)
couple months ago some ideas were thrown around in the discord, conclusion basically was: something with more controller convenience is needed
If you do end up PRing this the instanceof
check should not be used to provide logic. Check out the ScreenProcessor
stuff, specifically the handleScreenVMouse
method.
How would I go about creating a ScreenProcessor that applies to all screens that have a recipe book? (CraftingScreen
, InventoryScreen
, FurnaceScreen
, BlastFurnaceScreen
, SmokerScreen
(last three can probably be taken from AbstractFurnaceScreen
) and possibly more)
What they have in common is the interface RecipeUpdateListener
and they all at some point inherit from RecipeBookMenu<C extends Container>
(not a Screen
yet)
mixin into RecipeBookMenu
then!
Is your feature request related to a problem? Please describe. Its annoying to hover over the arrow on the recipe book to go to the other pages. And its generally bad.
Describe the solution you'd like Ideally the crafting system from the legacy console editions ported in some way.
Describe alternatives you've considered If thats to much work maybe at least the function to scroll through the pages with R1/L1.