Solved Bucket et Liquide
-
Bonjour, j’ai créé un liquide dans mon mod mais je me suis heurté à trois problèmes :
1 ) Pour commencer : pour crafter un seau de ce liquide, on utilise un seau d’eau mais le problème, c’est que lors du craft cela laisse un seau vide dans la table de craft, ce que je ne veux pas. J’ai trouvé une très mauvaise solution : faire Items.water_bucket.setContainerItem(null) mais si d’autres mods utilisent un craft avec un seau d’eau où il faudrait laisser un seau vide dans la table de craft, ça irais pas. Donc il faudrait passer par un autre moyen qui s’appliquerait seulement à mon craft.
2 ) Je vaudrais que mon liquide a des propriétés proches de la lave mais sans bruler le joueur (ou plutôt lui faire mois de dégâts). Donc je voudrais mettre un material différent que lava mais je sais pas comment mettre le mème genre de caractéristique (ralentissement).
3 ) Si on pose mon liquide, je voudrais qu l’on ne puisse pas le reprendre avec un seau mais comme pour l’instant il a comme material Material.lava, ça me donne un seau de lave et ça récupère la source. J’ai réussi à faire un sorte que le seau prenne la source tout en restant un seau vide mais ce n’est pas encore ce que je veux.
Aidez-moi, s’il vous plait !
-
1)Pas trop bien compris, peux-tu illustrer avec du code, cela serait + compréhensible. Sinon tu peux te servir de l’interface IRecipe, qui te permet davantage de choses en rapport avec tes recettes.
2)Après poru ce genre de demande, c’est à toi de regarder ça dans la classe de ton liquide, dans la méthode qui gère les collisions avec les entity, tu l’override. Ainsi tu gères l’absence de dégât et le ralentissement que tu souhaites.
3)Après pour l’histoire du material, je n’ai jamais créer de liquide en 1.7 mais vois peut-etre pour en créer un…Après si tu ne souhaites pas qu’on puisse le retirer avec un seau vanilla, utilise l’event EntityInteractEvent et cancel le, seulement si le block visé est ton nouveau liquide.
Je me renseignerai + ce soir si j’ai le temps …
-
Merci de ta réponse !
1 ) Je ne sais pas comment utiliser IRecipe donc je vais un peut chercher.
2 ) Le problème c’est que de basse c’est le material qui met ce genre de propriété et non pas méthode qui gère les collisions avec les entités. Si je met le ralentissement dans cette méthode, si le joueur est au milieu d’un bloc de liquide, il vas être un peut ralenti mais si il est entre 4 block de liquide, il est en collision avec les 4 block donc vas être 4 fois plus ralenti.
3 ) Je suis en train de tester ça, je te dirais si ça marche.
-
Au fait autant pour moi c’est l’event PlayerUseItem, pas EntityInteractEvent…Rien à voir ^^’
-
@‘Plaigon’:
Au fait autant pour moi c’est l’event PlayerUseItem, pas EntityInteractEvent…Rien à voir ^^’
J’étais en train de tester avec PlayerInteractEvent mais PlayerUseItem, ça doit aussi fonctionner. Il y a FillBucketEvent qui est fait pour ça mais même si je met
java event.setResult(Event.Result.DENY);ou ```java
event.setCanceled(true);ça supprime comme même la source. -
En fait j’ai testé à l’instant aucun des 2 events ne peut te convenir étant donné que EntityInteractEvent est lorsqu’un joueur interagit avec une entity (ce qui n’est pas ton cas, puisque la lave reste un block), puis même chose pour l’event PlayerUseItemEvent, étant donné que celui-là il ne convient que pour les items où il faut maintenir le clic droit (food, potion, arc, etc…). J’ai bien testé avec ses 4 sous classes, aucune ne convient juste pour un onItemRightClick du seau.
-
t’es sûr que c’est pas un problème de synchronisation ?
-
@‘SCAREX’:
t’es sûr que c’est pas un problème de synchronisation ?
Comment puis-je savoir si c’est problème de synchronisation ?
-
Si tu mets un block à côté de ta source et que ta source ré-apparaît c’est qu’il y a un problème de synchronisation
-
Non, ce n’est pas un problème de synchronisation: le liquide disparait réellement.
[edit] :
Non, c’est bon pour le troisième problème, je n’avais pas vu que j’ai mis un world.setBlockToAir(pos) au mauvaise endroit ! -
Regarde le code plus précisément en faisant click droit “Open call hierarchy” sur la fonction qui vide le seau
-
Pour le premier problème, j’ai trouvé une solution toute simple : faire un extends de ShapedOreRecipe.
Voici le code:public class ShapedOreRecipeWithoutRemain extends ShapedOreRecipe { public ShapedOreRecipeWithoutRemain(Block result , Object[] recipe) { super(result, recipe); } public ShapedOreRecipeWithoutRemain(Item result , Object[] recipe) { super(result, recipe); } public ShapedOreRecipeWithoutRemain(ItemStack result , Object[] recipe) { super(result, recipe); } @Override public ItemStack[] getRemainingItems(InventoryCrafting inv) { return new ItemStack[inv.getSizeInventory()]; } }Il reste donc plus que le deuxième problème.
-
Pourquoi faire une autre classe et pas utiliser ShapedOreRecipes directement ?
Pour le deuxième problème, créée un Material en prenant exemple sur celui de la lave. -
C’est parce que ShapedOreRecipe laisse un seau vide dans la table de craft si on fait un craft avec un seau plain. Donc comme je veux faire un craft avec un seau d’eau qui donne un autre seau, je ne vaux pas qu’il rest un seau vide dans la table de craft et ```java
@Override
public ItemStack[] getRemainingItems(InventoryCrafting inv)
{
return new ItemStack[inv.getSizeInventory()];
}permet de ne rien laisser dans la table de craft.(A part les item qu'il y a en trop pour le craft comme une buche de bois si on en met 2 dans un slot) Pour le deuxième problème, ce sont les entités qui gèrent le déplacement et les dégats dans les liquides : dans onUpdate(), il vérifient si le block dans lequel il est à pour material material.lava et dans ce cas, l'entité est ralentie et est en feu. -
1. ça va être difficile. Le système de craft de Minecraft n’est pas du tout prévu pour ça.
2. LivingUpdateEvent -> si le bloc au coordonnée de ton entité est ton bloc tu ralenti l’entité.
-
@‘robin4002’:
1. ça va être difficile. Le système de craft de Minecraft n’est pas du tout prévu pour ça.
2. LivingUpdateEvent -> si le bloc au coordonnée de ton entité est ton bloc tu ralenti l’entité.
C’est une bonne idée pour mon deuxième problème d’utiliser LivingUpdateEvent, je vais tester ça. (Et j’ai déjà trouvé une solution, un peut plus haut pour le premier problème)
-
Pour le 1), ah oui autant pour moi.
Pour le 2), oui bonne idée. -
J’ai fait quelque chose avec LivingUpdateEvent mais avec beaucoup d’entités, ça fait vite du lag.
:::@SubscribeEvent public void onLivingUpdate(LivingUpdateEvent event) { EntityLivingBase entity = event.entityLiving; BlockPos pos = new BlockPos(entity); World world = entity.worldObj; boolean inTarmac = false; AxisAlignedBB bBox = entity.getEntityBoundingBox(); if (bBox == null) return; Iterable <blockpos>iterable = BlockPos.getAllInBox(new BlockPos(bBox.minX, bBox.minY, bBox.minZ), new BlockPos(bBox.maxX, bBox.maxY, bBox.maxZ)); Iterator <blockpos>iterator = iterable.iterator(); while (iterator.hasNext()) { BlockPos testPos = iterator.next(); System.out.println("Test…" + testPos); if (world.getBlockState(testPos).getBlock() == BlockMod.tarmacLiquid) { inTarmac = true; break; } } if (inTarmac) { entity.setFire(1); entity.motionX *= 0.2f; entity.motionY *= 0.5f; entity.motionZ *= 0.2f; } }:::
Si quelqu’un a un moyen plus simple et moins couteux en ressources, je suis preneur !</blockpos></blockpos>
-
Pourquoi tout ça ?
Un simple :
if(world.getBlockState(new BlockPos(entity.posX, entity.posY, entity.posZ).getBlock() == BlockMod.tarmacLiquid)
suffit. -
J’ai fait ce truc compliqué pour détecter tous les blocks en collision avec l’entité. Si je met
if(world.getBlockState(new BlockPos(entity.posX, entity.posY, entity.posZ).getBlock() == BlockMod.tarmacLiquid)
ça va juste détecter le block au pieds de l’entité. Donc je sais pas si c’est vraiment mieux.
