[BUG] Escaliers de verre font du xRay

blixow14

Blackbalrog ce que tu proposes ne peut pas marcher justement parce que ça vient de la 1.7.10, or la version est la 1.12.2.
Et retirer un Override ne régle pas les problèmes, car justement les overrides permettent d’appeler la méthodes de la classe. Pour faire simple comme tu ne comprends pas avec des mots techniques, c’est comme si tu disais : Cette méthode utiliser dans la classe , je vais signaler que je m’en sert, donc je mets un @Override pour cela (à noter que tu dois soit extends à une classe, soit implémenté quelque chose pour que tu puisses faire un Override, parce que justement tu appelles la méthode de la classe). Voilà j’espère tu as compris le principe.

Blackbalrog

Haaa ok là j’ai compris ^^’ merci honnêtement j’ai demander à plein de gens personne n’a su me le dire avec des mot simple mais là j’ai compris merci. Et hop sa part sur mon discord là où je note tous pour pas oublié ^^'.

robin4002

@blixow14 a dit dans [BUG] Escaliers de verre font du xRay :

les overrides permettent d’appeler la méthodes de la classe. Pour faire simple comme tu ne comprends pas avec des mots techniques, c’est comme si tu disais : Cette méthode utiliser dans la classe , je vais signaler que je m’en sert, donc je mets un @Override pour cela (à noter que tu dois soit extends à une classe, soit implémenté quelque chose pour que tu puisses faire un Override, parce que justement tu appelles la méthode de la classe). Voilà j’espère tu as compris le principe.

Non, pas exactement.
D’un point de vue fonctionnel @Override ne fait rien. Ils ne sont pas garder après compilation.
@Override sert simplement à s’assurer qu’une méthode identique (même nom, même signature) existe dans la classe mère ou plus haut dans l’héritage.
Cela permet d’éviter les erreurs de méthode non surchargé (et donc jamais appelé) car elles n’ont pas la bonne signature.
Et dans le cas de Minecraft c’est d’autant plus important que les mises à jour ont tendances à changer le nom et les signatures des méthodes. Sans @Override suite à un changement de version, tu auras juste une méthode non appelée et donc un comportement inattendu en jeu. Avec un @Override tu auras une erreur de compilation, donc avant même de lancer ton jeu tu verra qu’il y a un problème et sur quelle méthode le problème est.

blixow14

Il a demandé une explication simple x) donc bon, car la pas sur qu’il comprenne.

blixow14

Bref, je pense qu’on s’est tout de même bien écarté du sujet de base qui est le problème d’xray du block.

Flow Arg

Et ben et ben, ça à discuté à ce que je vois ^^.

Bonjour @robin4002 , j’ai regardé la fonction shouldSideBeRendered (je pense que tu pensais à cette méthode). J’ai cherché sur le net (pas de javaDoc sur cette méthode puisqu’elle est dépréciée, pas non plus de renseignements sur quelle méthode utiliser a la place ) et je n’ai rien trouvé d’intéressant. De même, que je mette true ou false (c’est un boolean), je n’ai rien de concluant, au contraire, ça empire les choses. Peux tu éclairer ma lanterne ? Merci d’avance .

Flow

robin4002

Je viens de garder en détails, les deux méthodes que tu as surchargé (getBlockLayer et isFullCube) ne sert à rien, les fonctions dans BlockStairs renvoie déjà sur false pour le second et pour le premier il prend la valeur du bloc envoyé en argument (donc celui du verre dans ton cas).

La seule méthode qu’il y a dans la classe du verre (enfin dans une de ces classes parentes) c’est celle-ci :

    @SideOnly(Side.CLIENT)
    public boolean shouldSideBeRendered(IBlockState blockState, IBlockAccess blockAccess, BlockPos pos, EnumFacing side)
    {
        IBlockState iblockstate = blockAccess.getBlockState(pos.offset(side));
        Block block = iblockstate.getBlock();

        if (this == Blocks.GLASS || this == Blocks.STAINED_GLASS)
        {
            if (blockState != iblockstate)
            {
                return true;
            }

            if (block == this)
            {
                return false;
            }
        }

        return !this.ignoreSimilarity && block == this ? false : super.shouldSideBeRendered(blockState, blockAccess, pos, side);
    }

Sachant que dans le cas du verre ignoreSimilarity est sur false, donc il te faudrait quelque chose comme ça :

    @SideOnly(Side.CLIENT)
    public boolean shouldSideBeRendered(IBlockState blockState, IBlockAccess blockAccess, BlockPos pos, EnumFacing side)
    {
        IBlockState iblockstate = blockAccess.getBlockState(pos.offset(side));
        Block block = iblockstate.getBlock();

        if (blockState != iblockstate)
        {
            return true;
        }

        if (block == this)
        {
            return false;
        }

        return block == this ? false : super.shouldSideBeRendered(blockState, blockAccess, pos, side);
    }

Flow Arg

Merci beaucoup de cette réponse détaillée !
Je regarde ça ce soir et je te redis .

Flow Arg

@robin4002 C’est malheuresement un échec. Même soucis .

robin4002

Étrange, je ne vois pas quoi d’autre pourrait causer ce problème

Flow Arg

Moi non plus, on ne peut pas dire qu’on aura essayer peu de chose ^^. C’est bizarre .