Jump to content

ChampionAsh5357

Members
  • Posts

    3284
  • Joined

  • Last visited

  • Days Won

    62

Everything posted by ChampionAsh5357

  1. If you want to do showModel, then you would call the parent (e.g. bipedHead, bipedBody whatever they are called) and then showModel. If I'm not mistaken, this will show the default armor overlay as well. So the incorrect textures may have something to do with that afterwards.
  2. So you're trying to access a RiverBiome, for example, while the surface of the biome being built. If the biome hasn't been built before, and the method is just getting called, the biome would be generated before or after your custom one. So, you're trying to access something that won't properly exist until the chunk is completely built. You would need to get a specific coordinate after the chunk has generated. I believe this is how biomes are generated.
  3. 1.14 is unfortunately unsupported on the forum now. On a quick side note however: 1.16 introduces a state system for light value which should hopefully improve the lag issue.
  4. When you do ModelRenderer::addBox, it takes in a starting x, y, and z position. Just changes those to match where you want the model to be. Rotation should be handled by ModelRenderer::copyModelAngles.
  5. You're not allowed to reach across logical sides. It is a nullable method that only returns the current world if IChunk is an instance of Chunk. I'm pretty sure Chunk is not the instance of IChunk called when constructing a biome for the first time. The noise would make sense as its supposed to MAGNIFY the biome being created and fudge the sides to more fluently transition in. Didn't I just mention this? So question. If you're inside the SurfaceBuilder::buildSurface method, I believe it takes in a Biome as a parameter for the current biome. If so, why do you need to get the biome somewhere else? You're generating the surface for that specific chunk in that specific biome. If you're calling it to read from a different chunk, why?
  6. Hmm. Well then here's a thing. With the current system you have, it doesn't really support the method of local ModelRenderers. There are two ways to do it. Either remove the addChild tags and correct the model locations yourself with what you had before my previous message or redo the entire thing. I'm going to assume you're just gonna remove the addChild tags. From there you just need to fix the box locations which is easy enough to do.
  7. You shouldn't need to call them from the render part. If they are attached to a child, they get added via super.render(); There should be no reason to access a child anywhere outside the constructor.
  8. Well it definitely doesn't help if you can just walk right through the block. How am I supposed to walk on a block that I can't even touch? You might want to check Block::onEntityCollision since you would be inside the VoxelShape of the block.
  9. I just answered the question about double rendering on the other post with custom armor models.
  10. Do you have a picture of what it is supposed to look like because from what I can gather, the model seems to be rendering the way you wrote it. Fun fact about global and local ModelRenderers: If you make a global ModelRenderer a child of some other model, it will render twice! So, for every ModelRenderer you add, you need to make them local variables within your constructor to prevent that. Also, you shouldn't need to copyModelAngles if they are a child of the parent ModelRenderer. Also, make sure you are using the newest version of tabula released for 1.15 if you are creating models.
  11. The docs answers this question. But yes, IForgeBakedModel::handlePerspective should be enough if you're going to leave IBakedModel::getItemCameraTransforms defaulted.
  12. Let's see, first the version you are referencing with an id number is no longer supported. Second, you should look over ItemStack::addEnchantment to see how enchantment tags are written to. In case you don't understand, I'll do a bit of translation. Almost everything inside your nbt tag is wrong. First, the ListNBT (JsonArray) name is called "Enchantments" and not "ench". Second, the ListNBT hold an list of CompoundNBTs (JsonObjects). Each CompoundNBT holds two parameters: a String "id" holding the registry name of the enchantment and a short "lvl" holding the enchantment level. The value for "lvl" is clamped between 0-255 anyways so you should not exceed those bounds. Follow the link that diesieben07 sent and if you really need more of an example, enchant an item in game and open the player data file through an NBT reader so you can see how its structured.
  13. I was trying to achieve at the time making Effects completely invisible to the player. This means no particle effects or GUI notifications of how much time you have remaining regardless of what Effect it was. Apologies for such a late response. For some reason I never realized this was replied.
  14. { ... "result": { "item": "your_item", "nbt": { //Your nbt tag goes here. } } }
  15. You're creating a recipe. You're making it in a json file. You need it on the output. The json object is called "nbt".
  16. I'm confused because there are three questions I could ask: Are you changing the shape of your block? Are you trying to write to a tile entity? Are you trying to sync a tile entity to the client?
  17. There's a bunch of good tutorials (especially one on custom dimensions) from McJty that might be able to help.
  18. Personally, I'm not a big fan of the way you programmed it. You're implementing IRecipeType on a class (which makes no sense), not creating a serializer, and just not registering it anywhere. So, let's break it down. All recipes that hook into IRecipe have three things: - A class that implements IRecipe<T> (most likely T will be RecipeWrapper if you are using IItemHandler over IInventory which YOU SHOULD BE) - A class that extends ForgeRegistryEntry<IRecipeSerializer<V>> and implements IRecipeSerialier<V> (V is your class that extends IRecipe<T>) - A variable holding your IRecipeType<V> (statically initialized through IRecipeType#register should be fine). Let's start with IRecipeType. This just basically holds a string that will create a new map entry within RecipeManager for any recipe with that specific type. The string held within the registry should be your mod id appended with whatever you are going to call it. Next, let's go into IRecipe. All IRecipes should have a constructor that takes in a ResourceLocation, a String group (if you are going to use the RecipeBook), an Ingredient (NBTIngredient if you want to use NBT data), and ItemStack output. Note, it doesn't have to be an ingredient or itemstack, that's just the case most people use it for. Then we have the methods: - matches: checks to see if your recipe matches with the ones stored (will use Ingredient#test) - getRecipeOutput: the output of your recipe with no information provided beforehand (will be your result) - getCraftingResult: the output of your recipe with context (will be your result followed by ItemStack#copy) - canFit: checks to see if your recipe can fit in the required space - getId: the ResourceLocation of your recipe - getType: the IRecipeType your recipe should be stored in - getSerializer: the IRecipeSerializer used to read and write your recipe. Then we have the IRecipeSerializer. This will be registered within your code via RegistryEvent or DeferredRegister. This has three main methods: - read: reads the data from a JsonObject and returns an instance of your recipe (json file stored in datapack) - read: reads the data from a PacketBuffer and returns an instance of your recipe (server/client packet sending) - write: reads the data from your instance to a packet buffer (server/client packet sending) These methods can be observed in all recipe classes (e.g. ShapedRecipe, AbstractCookingRecipe, SingleItemRecipe) Once you start to create your json files (same place as all the other recipes), the type is handled by what the IRecipeSerializer is registered under (modid:object_name). And that's basically it. Hope this helps. If you want an example, I wrote a basic recipe and serializer for blenders a while back.
  19. Please create your own post with your code, error logs (if any), and examples if you need more to explain your point.
  20. Forge added an NBT tag (called "nbt" obviously) to outputs as they return an ItemStack and not a simple ingredient. The format is the same as any other nbt tag out in the wilderness of the Minecraft files.
  21. Learn about features, and then structures. IglooStructure and IglooPieces are a good basic introduction to creating structures with nbt data.
  22. Would you like to show us your code so we can actually diagnose the problem with little to no guesswork?
  23. Please use object holder to "hold" the block and item instances when registering or use deferred register if you're going to statically initialize anything. What you have written for custom blocks is just wrong.
  24. First of all, use a data generator. Second of all, your ruby_ore file is not a json file.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.