I'm creating a server-side mod that would allow one to use the command /craft and the crafting gui opens.

In old versions (1.12.2) it would be done with this code.

EntityPlayerMP player = someMethod(args)
player.displayGui(new BlockWorkbench.InterfaceCraftingTable(player.world, player.getPosition()));

In 1.18.2, I can cause the crafting gui/menu to open for a brief second with this code.

if (commandContext.getSource().getEntity() instanceof Player) {
		ServerPlayer player = (ServerPlayer)commandContext.getSource().getEntity();
		player.sendMessage(new TextComponent("Opening Crafting table"), player.getUUID());

		CraftingTableBlock craftingTableBlock = new CraftingTableBlock(BlockBehaviour.Properties.of(Material.WOOD).strength(2.5F).sound(SoundType.WOOD));
		player.openMenu(craftingTableBlock.getMenuProvider(craftingTableBlock.defaultBlockState(), player.getLevel(), player.blockPosition()));
		return Command.SINGLE_SUCCESS;
}

How do i stop it from closing? I'm probably calling the wrong methods.

The crafting table doesn't have an internal inventory.

Instead the server keeps track of whether the block is still valid and returns the crafting inventory to the player when it is not.

Unlike for example the furnace where the items are assigned to its internal inventory.

 

That is why it is closing your screen,.The block does not exist at the position you specified.

See for example:

https://forums.minecraftforge.net/topic/114789-best-way-to-create-a-custom-crafting-table-in-119/?do=findComment&comment=508881

Quote

CraftingTableBlock craftingTableBlock = new CraftingTableBlock(BlockBehaviour.Properties.of(Material.WOOD).strength(2.5F).sound(SoundType.WOOD));

By the way, it wouldn't suprise if doing things like that causes memory leaks and other issues in modern minecraft versions due to the way "intrinsic holders" work.

You shouldn't be creating objects that are mean to go in registries unless you actually intend to register them.

Edited January 19, 20232 yr by warjort

5 hours ago, warjort said:

By the way, it wouldn't suprise if doing things like that causes memory leaks and other issues in modern minecraft versions due to the way "intrinsic holders" work.

You shouldn't be creating objects that are mean to go in registries unless you actually intend to register them.

Ok, I kinda new that wouldn't be ideal 😥

 

6 hours ago, warjort said:

The crafting table doesn't have an internal inventory.

Instead the server keeps track of whether the block is still valid and returns the crafting inventory to the player when it is not.

Unlike for example the furnace where the items are assigned to its internal inventory.

 

That is why it is closing your screen, The block does not exist at the position you specified.

See for example:

https://forums.minecraftforge.net/topic/114789-best-way-to-create-a-custom-crafting-table-in-119/?do=findComment&comment=508881

Thanks so much! I will try and implement that and will get back to you

I have extended the crafting menu

public class VirtualCraftingMenu extends CraftingMenu {

    private final ContainerLevelAccess access;

    public VirtualCraftingMenu(int p_39356_, Inventory p_39357_, ContainerLevelAccess p_39358_) {
        super(p_39356_, p_39357_, p_39358_);
        this.access = p_39358_;
    }

    public VirtualCraftingMenu(int p_39353_, Inventory p_39354_) {
        this(p_39353_, p_39354_, ContainerLevelAccess.NULL);
    }

    // Override to return your menu type that identifies the screen to use
    @Override
    public MenuType<?> getType() {
        return MenuType.CRAFTING;
    }

    // Override to identify the block instance (used to force the user out of the screen if the block is destroyed)
    @Override
    public boolean stillValid(Player p_39368_) {
        //return stillValid(this.access, p_39368_, MY_CRAFTING_BLOCK.get());
    	return true;
    }
}

How would i now open it with player.openMenu() it is asking for a MenuProvider.

https://docs.minecraftforge.net/en/latest/gui/menus/#opening-a-menu

Using this code:

player.openMenu(getMenuProvider(player.level, player.blockPosition()));

public MenuProvider getMenuProvider(Level p_52241_, BlockPos p_52242_) {
		return new SimpleMenuProvider((p_52229_, p_52230_, p_52231_) -> {
		return new VirtualCraftingMenu(p_52229_, p_52230_);
		}, CONTAINER_TITLE);
 }

I get the crafting gui to fully open stay open, but putting items into the crafting gid will not show an output item

Using:

NetworkHooks.openGui(Splayer, new SimpleMenuProvider(
    				  (containerId, playerInventory, player) -> new VirtualCraftingMenu(containerId, playerInventory),
    				  CONTAINER_TITLE
    				));

to open the menu results in the same problem

People that only post snippets of code and then say "it doesn't work" will usually just be ignored.

That is unless the bug is trivially obvious from the small amount of code posted.

This is especially if they spent less than 15 minutes trying to debug it for themselves.

You need to put your code on github where we can see all relevant code in context and try it for ourselves if needed.

 

On the trivially obvious:

Quote

// Override to return your menu type that identifies the screen to use

@Override public MenuType<?> getType() {

return MenuType.CRAFTING;

}

That is the vanilla MenuType pointing at the vanilla CraftingMenu, not your overridden menu.

You need your own MenuType that creates your implementation with a screen registered against it

https://docs.minecraftforge.net/en/latest/gui/screens/#registering-an-abstractcontainerscreen

You should be able to reuse the vanilla CraftingScreen for that?

 

I suggest you read the whole of those links I posted above.

And try implementing your own simple test menu and screen from scratch to get a better understanding how the menu system works.

50 minutes ago, warjort said:

People that only post snippets of code and then say "it doesn't work" will usually just be ignored.

That is unless the bug is trivially obvious from the small amount of code posted.

This is especially if they spent less than 15 minutes trying to debug it for themselves.

You need to put your code on github where we can see all relevant code in context and try it for ourselves if needed.

 

On the trivially obvious:

That is the vanilla MenuType pointing at the vanilla CraftingMenu, not your overridden menu.

You need your own MenuType that creates your implementation with a screen registered against it

https://docs.minecraftforge.net/en/latest/gui/screens/#registering-an-abstractcontainerscreen

You should be able to reuse the vanilla CraftingScreen for that?

 

I suggest you read the whole of those links I posted above.

And try implementing your own simple test menu and screen from scratch to get a better understanding how the menu system works.

Understood.

Just to clarify, the client doesn't need to be modded?

I just want to have a vanilla client use the crafting gui without a physical table, or mods.

The vanilla crafting menu needs to be associated with a physical block and that is what will be used in a vanilla client.

Short of major hacks to do something like rewrite the network packets to pretend your menu is the vanilla menu to clients I don't know how you achieve what you are trying to do?