[1.12.2]Guihandler never called after call player.openGui

[tt36999]

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 October 31, 2018 by diesieben07
syntax highlighting

[V0idWa1k3r]

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.

[tt36999]

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

[V0idWa1k3r]

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 October 31, 2018 by V0idWa1k3r

[tt36999]

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

[V0idWa1k3r]

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.

[tt36999]

OK,I don't want debate this with you, maybe you are right or maybe my, i will try your proposal and remove the common, i hope this can fix my issue.