Make sure you're doing the following

• You're using the latest build for your server version
• This isn't an issue caused by another plugin
• You've checked for duplicate issues
• You didn't use /reload

Describe the question
I am searching for a way to trick the client/player that he has right clicked on a chest, even when he did not. I am using Optifine Textures. Optifine detects whether you opened a certain container (example, filters it by name) and if it matches the one in configuration, it will open a chest inventory with a speciffic design. Now... Chests are a bit ugly and I am using a Crates plugin that allows me to make any block behave as a crate. If I right click it with a key, the crate will open (double chest GUI). The thing is that the OptiFine does not load it's textures unless it is sure that the player right clicked a real double chest and not opened one by bukkit's API.

I tried using OpenWindow packet already, even if it loads the double chest inventory, the textures don't. Is there some packet that could help me do this?

API method(s) used
PacketType.Play.Server.OPEN_WINDOW, but still nope

Expected behavior
Not expected, just curious, a question.

Code
It's not actually. I edited the Title in the PacketType.Play.Server.OPEN_WINDOW and it does what it says, but still, no textures.

Additional context
I am aware this is apparently an OptiFine issue, and it's already reported on their github, but I am wondering if there's is a way around it :)

Can you post a screenshot of what it looks like?

Of what exactly, I'm sorry. A code? A GUI?

@wellnesscookie due to limitations of Minecraft, Optifine had to implement their own system to make their custom texture system work.

Due to the fact it is all client side calculations and doesn't rely
This is done in the snippets provided below.

PlayerControllerOF.java

public class PlayerControllerOF extends PlayerControllerMP {

    ...

    public boolean onPlayerRightClick(EntityPlayerSP p_178890_1, WorldClient p_178890_2, ItemStack p_178890_3, BlockPos p_178890_4, EnumFacing p_178890_5, Vec3 p_178890_6)
    {
        this.acting = true;
        this.lastClickBlockPos = p_178890_4;
        boolean flag = super.onPlayerRightClick(p_178890_1, p_178890_2, p_178890_3, p_178890_4, p_178890_5, p_178890_6);
        this.acting = false;
        return flag;
    }

CustomGuis.java

public class CustomGuis {

    ...

    GuiScreen guiscreen = mc.currentScreen;
    BlockPos blockpos = playerControllerOF.getLastClickBlockPos();

    if (blockpos != null) {
        if (guiscreen instanceof GuiChest)
        {
            return getTexturePos(CustomGuiProperties.EnumContainer.CHEST, blockpos, iblockaccess, loc, guiscreen);
        }
    }

As you can see said classes call for the value of Minecraft.currentScreen# that is only set when the client dependently handles the opening of a chest. This can be seen in the code snippet below.

EntityPlayerSP.java

public class EntityPlayerSP extends AbstractClientPlayer {

    ...

    public void displayGUIChest(IInventory chestInventory) {
        String s = chestInventory instanceof IInteractionObject ? ((IInteractionObject)chestInventory).getGuiID() : "minecraft:container";

        if ("minecraft:chest".equals(s)) {
            this.mc.displayGuiScreen(new GuiChest(this.inventory, chestInventory));
        }

This action isn't called with the client receives the packet such as how ProtocolLib works or any packet library for that matter.

This can be confirmed by looking at EntityPlayerMP.displayGUIChest#, as it lacks any setting of the Minecraft.currentScreen# field.

I hope this shared some insight in why this bug happens (I may be 100% wrong with all of this), it could be patched out using the same override system Optifine uses for PlayerControllerOF.java however I very much doubt they would push the patch for every version of Minecraft that Optifine supports.