[BUG] Escaliers de verre font du xRay

Blackbalrog

Au pire tiens car c’est vrai que t’as class tout en haut es bizard

je te fais un mini tuto
déjà tu créé un package que tu appel comme tu veux c’est dedans qu’on va plus ou moins tous mettre (Les Class)

Ensuite dans se package tu va créé une Class BlockMod ensuite tu créé un Objet.

Donc:

public static Block stair;

ensuite dessous tu créé une méthode donc:

public static void init()
{
}

et une 2ème méthode:

public static void registerBlock()
{
}

ensuite dans init tu cales les paramètre de ton Objet:

stair = new Stairs(BlockMod.block_stair, 0).setBlockName("stair").setCreativeTab(CreativeTabs.tabblock).setHardness(5.0F);

ensuite tu passe t’as souris sur Stairs et tu créé une nouvelle Class qui doit se trouver dans le package que tu as créé
ensuite tu fais un exporte de BlockStairs ensuite tu passe souris sur Stairs et tu fais add constructor …

ensuite dans registerBlock tu cales:

GameRegistry.registerBlock(stair, stair.getUnlocalizedName().substring(5));

ensuite tu vas dans ta Class principal et tu vas dans PreInit et dedans tu marque:

BlockMod.init;
BlockMod.registerBlock

Et ensuite dans la Class Stairs
dessous le constructor tu créé cette méthodes

public boolean isOpaqueCube()
{
return false;
}

Avant qu’on me dise que ça marche pas je précise que se code viens de la 1 7 10 donc je ne sais pas si sa peux marcher en 1.12.2

blixow14

Ah oui, alors désolé d’avoir cru que c’était pour moi ^^'. Je crois pas qu’il y ait besoin d’une autre fonction, je pense que ça vient de la façon très bizarre qu’il a eu de faire son block. Il doit dégager ces 2 classes puis en créer une seule l’extends à BlockStairs et ajouter son implements. Après il ajoute le block à L’ArrayList et met les fonctions que je lui ai dit de mettre.

robin4002

@Blackbalrog le problème c’est pas que ça fonctionne au non, c’est que tu répands des mauvaises pratiques en disant d’enlever @Override sans même savoir ce qu’il fait. Et ça cela m’agace beaucoup.

Blackbalrog

Non j’ai jamais su à quoi il servait car les explication avec des mot technique c’est pas mon truc à chaque fois j y comprend rien

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 .