Jump to content

[1.12.2]Guihandler never called after call player.openGui


tt36999

Recommended Posts

I'm working for my mod,and when i want to make a gui to my block i got this problem.

When i right my block , onBlockActived method was run without any error.but my gui handler never called

this is main file

    @Mod.Instance
    public static BrewingCraft instance; 

	@Mod.EventHandler
    public void init(FMLInitializationEvent event) {
        proxy.onInit(event);
    }

this is commonproxy(some potion,player event code in this file,i think it's no need to show them)

	@Override
    public void onInit(FMLInitializationEvent event) {
        NetworkRegistry.INSTANCE.registerGuiHandler(BrewingCraft.instance, new BRCGuiHandler());
    }

here is GuiHandler

public class BRCGuiHandler implements IGuiHandler {
    @Nullable
    @Override
    public Object getServerGuiElement(int ID, EntityPlayer player, World world, int x, int y, int z) {
        BrewingCraft.logger.info("Get server con " + ID);//never show in colsole
        switch (ID) {
            case 0:
                return new ContainerTestBlock(player.inventory, (TileEntityFluidContainer) world.getTileEntity(new BlockPos(x, y, z)));
        }
        BrewingCraft.logger.warn("[Warning] Can not get server gui container with id is " + ID);
        return null;
    }

    @Nullable
    @Override
    public Object getClientGuiElement(int ID, EntityPlayer player, World world, int x, int y, int z) {
        BrewingCraft.logger.info("Get client gui " + ID);//never show in colsole
        switch (ID) {
            case 0:
                return new GuiTestFluidContainer((ContainerBRC) getServerGuiElement(ID, player, world, x, y, z), player.inventory);
        }
        BrewingCraft.logger.warn("[Warning] Can not get client gui object with id is " + ID);
        return null;
    }

this is my block onBlockActive method

@Override
    public boolean onBlockActivated(World worldIn, BlockPos pos, IBlockState state, EntityPlayer playerIn, EnumHand hand, EnumFacing facing, float hitX, float hitY, float hitZ) {
        final IFluidHandler fluidHandler = getFluidHandler(worldIn, pos);
        if (fluidHandler != null) {
            ItemStack heldItem = playerIn.getHeldItem(hand);
            if (!CapabilityUtils.hasCapability(heldItem, CapabilityFluidHandler.FLUID_HANDLER_ITEM_CAPABILITY, null)) {
                if (!worldIn.isRemote) {
                    if (hasGui()) {
                        BrewingCraft.logger.info("Open Gui " + getGui().getId());//this code line show text in colsole
                        //BrewingCraft.openGui(playerIn, getGui(), worldIn, pos.getX(), pos.getY(), pos.getZ());//forget this is just a test code
                        playerIn.openGui(BrewingCraft.instance, getGui().getId(), worldIn, pos.getX(), pos.getY(), pos.getZ());
                    } else {
                        IFluidTankProperties[] properties = fluidHandler.getTankProperties();
                        StringBuilder builder = new StringBuilder();
                        for (IFluidTankProperties tankProperties : properties)
                            builder.append(tankProperties.getContents().getLocalizedName() + ":" + tankProperties.getContents().amount + "/" + tankProperties.getCapacity());
                        playerIn.sendStatusMessage(new TextComponentString(builder.toString()), false);
                    }
                }
                return true;
            }
            FluidUtil.interactWithFluidHandler(playerIn, hand, fluidHandler);
            return FluidUtil.getFluidHandler(playerIn.getHeldItem(hand)) != null;
        }
        return false;
    }

any one know how to fix this?maybe i make some mistake in my code

Edited by diesieben07
syntax highlighting
Link to comment
Share on other sites

10 hours ago, tt36999 said:

this is commonproxy

CommonProxy makes no sense. Proxies exist to separate sided-only code. If your code is common then it goes into your main mod file. In fact I am pretty sure that this is the root cause of your problem.

 

10 hours ago, tt36999 said:

builder.append(tankProperties.getContents().getLocalizedName() + ":" + tankProperties.getContents().amount + "/" + tankProperties.getCapacity());

You can't do this on a server. Translations are a client-side only thing.

Link to comment
Share on other sites

10 hours ago, V0idWa1k3r said:

CommonProxy makes no sense. Proxies exist to separate sided-only code. If your code is common then it goes into your main mod file. In fact I am pretty sure that this is the root cause of your problem

OK,I just don't like write all my code in main file , ClientProxy was extends from CommonProxy, I has a ServerProxy too, if one side need different code , i just override it from CommonProxy

 

10 hours ago, V0idWa1k3r said:

You can't do this on a server. Translations are a client-side only thing.

I removed it, and do this in client

Link to comment
Share on other sites

12 minutes ago, tt36999 said:

OK,I just don't like write all my code in main file

Then have it anywhere else, just don't have a CommonProxy.

 

12 minutes ago, tt36999 said:

ClientProxy was extends from CommonProxy, I has a ServerProxy too, if one side need different code , i just override it from CommonProxy

You don't understand my issue here. It's not that having a common ancestral class is a bad thing, it's that the whole concept of a CommonProxy makes no sense whatsoever. It's bad coding practice. A proxy can't be common by definition of what a proxy is. It's like if the String class in Java derived from a Number class. Technically a string is a bunch of chars which are just unsigned shorts which are numbers and technically there may be nothing wrong with the implementation but it makes no sense. A String isn't a Number. A proxy can't be common. 

And I think the fact that you even have something being done in a common proxy is the whole reason you are having this issue. If you didn't have a common proxy you would not put any code in it and thus you wouldn't have any issues.

Edited by V0idWa1k3r
Link to comment
Share on other sites

28 minutes ago, V0idWa1k3r said:

You don't understand my issue here. It's not that having a common ancestral class is a bad thing, it's that the whole concept of a CommonProxy makes no sense whatsoever. It's bad coding practice. A proxy can't be common by definition of what a proxy is. It's like if the String class in Java derived from a Number class. Technically a string is a bunch of chars which are just unsigned shorts which are numbers and technically there may be nothing wrong with the implementation but it makes no sense. A String isn't a Number. A proxy can't be common. 

And I think the fact that you even have something being done in a common proxy is the whole reason you are having this issue. If you didn't have a common proxy you would not put any code in it and thus you wouldn't have any issues.

I don't think is no sense, in my mod most situation client need more code than server, and server proxy even hasn't any code then common. so i just make common to do what serverproxy do, and client extened it , so i can override it.

for example if someone write code in proxy to getServerGuiElement and getClientGuiElement(i won't do that , just for example)

in common it can return a container for server , and in clientproxy it can use common get container and return gui element.

client proxy will become an extension of common, and sometime will different from common

Link to comment
Share on other sites

4 minutes ago, tt36999 said:

server proxy even hasn't any code then common. so i just make common to do what serverproxy do, and client extened it

This makes no sense. Again - server proxy does server-side only stuff. The things that would crash the client. Like accessing the DedicatedServer class which is marked as @SideOnly(Side.SERVER). You can't make a common proxy do what a server proxy does, that would crash the client, similar to how registering a model would crash a server. If your code doesn't crash either the server or the client then it's common code and it goes anywhere else but your proxy. Again - proxies are side-specific classes. There can't be a common proxy because there is no common side. You are either on the client or on the server.

 

6 minutes ago, tt36999 said:

so i can override it.

You don't need a common ancestral class to use override. An interface does the job just fine and is in fact a preferred method of using a proxy.

 

7 minutes ago, tt36999 said:

or example if someone write code in proxy to getServerGuiElement and getClientGuiElement(i won't do that , just for example)

in common it can return a container for server , and in clientproxy it can use common get container and return gui element.

Just... no. IGuiHandler exists for a reason, and your proxy isn't one of them. Proxies are for separating PHYSICAL sides. IGuiHandler separates the thing needed to have a GUI/Container pair on the LOGICAL sides. There is a huge difference.

 

8 minutes ago, tt36999 said:

client proxy will become an extension of common, and sometime will different from common

Then your server must also become an extension of the common by the same logic, because you need to run that common code on both physical sides, right? Then why use the proxy in the first place? It is exactly the one thing proxies were made not to do. If your code must be ran on both sides run it in any other class that has nothing to do with proxies.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Announcements



  • Recently Browsing

    • No registered users viewing this page.
  • Posts

    • They were already updated, and just to double check I even did a cleanup and fresh update from that same page. I'm quite sure drivers are not the problem here. 
    • i tried downloading the drivers but it says no AMD graphics hardware has been detected    
    • Update your AMD/ATI drivers - get the drivers from their website - do not update via system  
    • As the title says i keep on crashing on forge 1.20.1 even without any mods downloaded, i have the latest drivers (nvidia) and vanilla minecraft works perfectly fine for me logs: https://pastebin.com/5UR01yG9
    • Hello everyone, I'm making this post to seek help for my modded block, It's a special block called FrozenBlock supposed to take the place of an old block, then after a set amount of ticks, it's supposed to revert its Block State, Entity, data... to the old block like this :  The problem I have is that the system breaks when handling multi blocks (I tried some fix but none of them worked) :  The bug I have identified is that the function "setOldBlockFields" in the item's "setFrozenBlock" function gets called once for the 1st block of multiblock getting frozen (as it should), but gets called a second time BEFORE creating the first FrozenBlock with the data of the 1st block, hence giving the same data to the two FrozenBlock :   Old Block Fields set BlockState : Block{minecraft:black_bed}[facing=east,occupied=false,part=head] BlockEntity : net.minecraft.world.level.block.entity.BedBlockEntity@73681674 BlockEntityData : id:"minecraft:bed",x:3,y:-60,z:-6} Old Block Fields set BlockState : Block{minecraft:black_bed}[facing=east,occupied=false,part=foot] BlockEntity : net.minecraft.world.level.block.entity.BedBlockEntity@6d1aa3da BlockEntityData : {id:"minecraft:bed",x:2,y:-60,z:-6} Frozen Block Entity set BlockState : Block{minecraft:black_bed}[facing=east,occupied=false,part=foot] BlockPos{x=3, y=-60, z=-6} BlockEntity : net.minecraft.world.level.block.entity.BedBlockEntity@6d1aa3da BlockEntityData : {id:"minecraft:bed",x:2,y:-60,z:-6} Frozen Block Entity set BlockState : Block{minecraft:black_bed}[facing=east,occupied=false,part=foot] BlockPos{x=2, y=-60, z=-6} BlockEntity : net.minecraft.world.level.block.entity.BedBlockEntity@6d1aa3da BlockEntityData : {id:"minecraft:bed",x:2,y:-60,z:-6} here is the code inside my custom "freeze" item :    @Override     public @NotNull InteractionResult useOn(@NotNull UseOnContext pContext) {         if (!pContext.getLevel().isClientSide() && pContext.getHand() == InteractionHand.MAIN_HAND) {             BlockPos blockPos = pContext.getClickedPos();             BlockPos secondBlockPos = getMultiblockPos(blockPos, pContext.getLevel().getBlockState(blockPos));             if (secondBlockPos != null) {                 createFrozenBlock(pContext, secondBlockPos);             }             createFrozenBlock(pContext, blockPos);             return InteractionResult.SUCCESS;         }         return super.useOn(pContext);     }     public static void createFrozenBlock(UseOnContext pContext, BlockPos blockPos) {         BlockState oldState = pContext.getLevel().getBlockState(blockPos);         BlockEntity oldBlockEntity = oldState.hasBlockEntity() ? pContext.getLevel().getBlockEntity(blockPos) : null;         CompoundTag oldBlockEntityData = oldState.hasBlockEntity() ? oldBlockEntity.serializeNBT() : null;         if (oldBlockEntity != null) {             pContext.getLevel().removeBlockEntity(blockPos);         }         BlockState FrozenBlock = setFrozenBlock(oldState, oldBlockEntity, oldBlockEntityData);         pContext.getLevel().setBlockAndUpdate(blockPos, FrozenBlock);     }     public static BlockState setFrozenBlock(BlockState blockState, @Nullable BlockEntity blockEntity, @Nullable CompoundTag blockEntityData) {         BlockState FrozenBlock = BlockRegister.FROZEN_BLOCK.get().defaultBlockState();         ((FrozenBlock) FrozenBlock.getBlock()).setOldBlockFields(blockState, blockEntity, blockEntityData);         return FrozenBlock;     }  
  • Topics

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.