Porte avec un modèle custom
-
Salut à vous, j’essai de faire une porte avec un modèle custom mais j’ai un problème.
C’est la première fois que je fais des modèles en fait, mais c’est pas ça le problème.
Ma porte comprend 4 blocs, du coup est-ce que je dois faire 4 modèles différents (un pour chaque bloc de 16x16) ?
Et aussi j’aimerais faire une porte qui se déplace sur le côté, est-ce possible?
Voici une image de mon modèle si ça peut vous aider à comprendre:
http://prntscr.com/enrllv
À droite c’est où est-ce que la porte va être située une fois fermée.EDIT: au passage, je viens d’essayer de créer un bloc avec un modèle custom, est-ce qu’il faut absolument que le block soit un TileEntity? Ça peut pas être un simple bloc? :x
Merci à vous!
-
Salut,
Pour un TESR il faut obligatoirement un tile entity.Si tu ne veux pas de tile entity, il faut passé par un rendu ISRBH : https://www.minecraftforgefrance.fr/showthread.php?tid=205 (qui ne te permettra pas d’utiliser un modèle techne, il faut faire le modèle directement dans le code).
Ensuite pour le fonctionnement même de ta porte, la façon dont elle est va demander une logique de fonctionnement complexe.
Minecraft n’est pas prévu pour avoir des blocs plus grand que 1x1x1, la porte par exemple utilise deux blocs.
Le mieux dans ton cas sera donc d’avoir 4 blocs pour représenter la porte. Il faut que lorsqu’un des 4 blocs est détruit, les 3 soient détruit avec (tu peux regarder le code de la porte pour voir comment faire).
Ensuite, il faudrait utiliser 5 metadata différent. 4 premiers metadata pour les 4 différents bloc (pour pouvoir les différencier) et 1 metadata différent pour l’un des deux blocs pour savoir si la porte est ouverte ou pas (par exemple le bloc en bas à gauche sur ton image).
Ton bloc en bas à gauche aura donc une collision null si son metadata est celui que tu as défini pour représenter l’état ouvert. Pour le bloc en haut à gauche, pas besoin de faire un metadata supplémentaire, vérifie simplement le metadata de world.getMetadata(x, y -1, z) pour savoir s’il faut lui mettre une collision null ou pas.
Pour le code du rendu, même principe que pour la collision pour savoir comment faire le rendu.Si tu veux en plus avoir 4 directions pour ta porte, il faut prévois des metadata supplémentaires pour indiquer la direction. (et je ne suis pas sûr que les 16 metadata que permet minecraft suffira :/).
-
Salut, les 16 méta data peuvent suffire pour ta porte : tu en à besoin de 4 par direction : deux pour dire que la porte est ouverte ou fermée( comme l’a expliqué Robin) , une qui va regarder la block à sa gauche et une pour dire de regarder le block en dessous. Si le block du dessous est le block qui porte l’info ouvert/fermé c’est qu’il est en haut à gauche sinon, il est en haut à droite et va chercher l’info ouvert/fermé en x-1, y-1. Et tu fais ça pour toutes les directions.
-
Vous oubliez qu’il semble vouloir un block qui a une animation d’ouverture.
-
Merci de vos réponses
En vrai c’est chaud, mais pour les metadatas 16 devrait suffirent comme le dit LeBossMax2, 1-4 pour le metadata du bloc, 5-9 pour la direction (état ouvert), 10-14 pour la direction (état fermé) et on vérifie le metadata du bloc coin gauche en bas pour vérifier l’état et la direction -
Non, ça ne va pas. Tu vas vite rencontrer un problème avec cette méthode.
5 à 9 pour la direction de quel bloc ?Depuis n’importe quel bloc tu dois être capable de trouver les 3 autres blocs associés à la porte.
Or en fonction de la direction, les autres blocs ne seront pas au même endroit.La gauche d’un bloc, ça va être soit x + 1, soit x - 1 soit z + 1 soit z - 1 en fonction de si ta porte pointe le nord, le sud, l’est ou l’ouest.
Ah et si en effet tu veux animer l’ouverture de la porte, TESR obligatoire.
-
@‘robin4002’:
Non, ça ne va pas. Tu vas vite rencontrer un problème avec cette méthode.
5 à 9 pour la direction de quel bloc ?Depuis n’importe quel bloc tu dois être capable de trouver les 3 autres blocs associés à la porte.
Or en fonction de la direction, les autres blocs ne seront pas au même endroit.La gauche d’un bloc, ça va être soit x + 1, soit x - 1 soit z + 1 soit z - 1 en fonction de si ta porte pointe le nord, le sud, l’est ou l’ouest.
Ah et si en effet tu veux animer l’ouverture de la porte, TESR obligatoire.
Du coup si on oublie l’animation de la porte et que je veux seulement deux direction (nord sud ou bien est ouest), c’est possible ? En plus pas besoin de metadata pour l’ouverture, quand tu fais clique droit sur la porte tu peux déplacer le bloc sur le bloc à sa droite/ gauche en fonction de la direction non? Sinon je fais un bloc pour la porte ouverte et un bloc pour la porte fermée et si quelqu’un fait clic droit sur la porte fermée le bloc disparaît et le bloc porte ouverte apparaît à côté en fonction de la direction encore une fois
-
Pour les 4 directions * 4 blocs * 2 états ça donne 32 metadata, il faut 2 blocs différents.
Avec 2 directions on passe à 16, donc passe sur un bloc.Après au prix de quelques vérifications de plus, il y a moyen de faire rentrer le premier cas dans 4*3+4 = 16 metadatas de la façon suivante :
4 metadatas pour le bloc en bas à droite
4 metadatas pour le bloc en haut à droite
4 metadatas pour les blocs de gauche (il faudrait check le bloc à droite pour savoir si c’est le bloc du bas où celui du haut)
4 metadatas pour les blocs de gauche à l’état ouvert (les blocs de droite devront regarder le metadata des blocs à gauche pour savoir si c’est ouvert ou pas)Un peu plus complexe à gérer niveau code, mais moins gourmand en metadata.
-
@‘robin4002’:
Pour les 4 directions * 4 blocs * 2 états ça donne 32 metadata, il faut 2 blocs différents.
Avec 2 directions on passe à 16, donc passe sur un bloc.Après au prix de quelques vérifications de plus, il y a moyen de faire rentrer le premier cas dans 4*3+4 = 16 metadatas de la façon suivante :
4 metadatas pour le bloc en bas à droite
4 metadatas pour le bloc en haut à droite
4 metadatas pour les blocs de gauche (il faudrait check le bloc à droite pour savoir si c’est le bloc du bas où celui du haut)
4 metadatas pour les blocs de gauche à l’état ouvert (les blocs de droite devront regarder le metadata des blocs à gauche pour savoir si c’est ouvert ou pas)Un peu plus complexe à gérer niveau code, mais moins gourmand en metadata.
Puisque les portes pourront seulement être ouvertes par un joueur avec le clic droit, je peux faire le truc de deux blocs dont j’ai parlé non?
1 bloc avec 8 metadata (direction, ouvert/fermé, haut/bas) (partie de gauche), un autre avec 8 metadata (direction, ouvert/fermé, haut/bas), et si on clic sur un bloc et que la porte est ouverte alors on la met à ferme en changeant le metadata et le collision box, on vérifie à droite ou à gauche en fonction de la position et on met le bloc à ouvert/fermé.
-
Même dans le cas où ça aurait été géré par redstone, ça n’empèche pas de passer par deux blocs.
-
@‘robin4002’:
Même dans le cas où ça aurait été géré par redstone, ça n’empèche pas de passer par deux blocs.
Ok, c’est juste que depuis le début vous parler d’un seul blocs avec plein de metadata alors j’ai conclu qu’on pouvait pas utiliser plusieurs blocs ?
-
On peut faire les deux, soit utiliser plein de meta data (ou même avoir une variable dans un tile entity si on passe par un TESR), ou utiliser un block pour chaque partie (ce qui est plus simple je pense)
-
Rester sur un bloc à l’avantage d’éviter d’utiliser plusieurs id de bloc (qui existe toujours en interne).
Après il y en a 4096 au total, donc ça fait de la marge. -
Très bien merci à vous pour votre aide
