Jump to content

Choonster

Moderators
  • Posts

    5117
  • Joined

  • Last visited

  • Days Won

    75

Everything posted by Choonster

  1. Judging by the "ForgeData" tag, it looks like you're using TileEntity#getTileData somewhere; don't do this. The tag returned by TileEntity#getTileData is for mods to store custom data on external TileEntities; but the capability system is a much better way to do this. When you call TileEntity#writeToNBT, pass an empty compound tag as the argument.
  2. 1.11.x has these methods and it has the registry events. All of the advice you've received here still applies.
  3. Subscribe to GuiOpenEvent instead, it can be cancelled to prevent the GUI from opening.
  4. There are three overloads of IForgeRegistryEntry.Impl#setRegistryName (which is inherited by Item): (String) (ResourceLocation) (String, String) Even if it did require a ResourceLocation, it's not a very complicated class: it's simply a domain (your mod ID) and a path (the name of your Item).
  5. That doesn't change anything, it still shouldn't be used.
  6. You need to use submodels to combine multiple models. Are you sure you actually need multiple models and not just a single model with multiple textures?
  7. You're storing compound inside of itself, leading to infinite recursion when Minecraft tries to write the NBT to disk.
  8. This is incorrect. There's nothing in the Forge build system that removes @SideOnly classes from the JAR, since Forge mods are universal (i.e. required on both sides) by default. You may be thinking of Mojang's build system for Minecraft, which doesn't include client-only classes in the server JAR or server-only classes in the client JAR. ForgeGradle adds @SideOnly to client- or server-only classes, fields and methods when it merges the client and server JARs for the development environment.
  9. You can probably make use of the active item use mechanic used by bows, food, shields, etc. Try overriding Item#onItemRightClick to do the following: Call EntityLivingBase#isHandActive to check if the player is actively using an item. If they aren't, call EntityLivingBase#setActiveHand to make the player start using your item and then perform the effect. If they are, do nothing. You'll also need to override Item#getMaxItemUseDuration to return the maximum duration in ticks that the player can actively use your item (bows and shields use 72000, which is 1 hour), and optionally Item#getItemUseAction to return something other than EnumAction.NONE.
  10. Enchantments are managed by a Forge registry, so the numeric IDs are automatically assigned per-save and shouldn't be used. Use the registry name in the JSON instead and store the Enchantment instance in the Ingredient for matching.
  11. You can use the Capability system to store additional data on Vanilla TileEntities.
  12. What are you trying to achieve? There's probably a better way to do it than replacing the TileEntity completely.
  13. You'll need to create a copy of IngredientNBT and override Ingredient#apply to perform a partial NBT match instead of a full NBT match. You'll then need to create an implementation of IIngredientFactory that creates an instance of the Ingredient class from the provided JSON object; you can use CraftingHelper.getItemStack to parse an ItemStack from JSON. Register this factory by adding the fully-qualified name to your _factories.json file; you can see an example here. The name you specify for the factory in _factories.json is the name you'll use in the type property of the ingredients in your recipe files. Edit: You might want to use an NBTPredicate for the NBT matching rather than storing a full ItemStack. This isn't really what the OP is looking for, since the conditions are only evaluated once when the recipe is loaded.
  14. Resource packs can't modify server-side files like recipes, structures and loot tables; but the data packs being added in 1.13 probably will be able to.
  15. Override FluidHandlerItemStackSimple#fill and FluidHandlerItemStackSimple#drain to call the super methods and then damage FluidHandlerItemStackSimple#container if the super method returned something other than 0/null and the doFill/doDrain parameter is true.
  16. You don't write the patches yourself, you set up a Forge workspace, make your changes to the appropriate Vanilla classes and then run the genPatches Gradle task to re-generate the patches with your changes. Forge's documentation explains how to contribute to Forge here and here.
  17. active=true,facing=south is not the same as facing=south,active=true. If you use Forge's blockstates format, you can specify the effect of each property value individually and you don't need to list the properties in a specific order (except when using fully-defined variants).
  18. An ItemStack with zero count is automatically empty; you don't need to return ItemStack.EMPTY.
  19. Running mh isTransparent on MCPBot tells me that Particle#func_187111_c was renamed from isTransparent to shouldDisableDepth on 2017-02-18 by kashike.
  20. If you look at ItemBlock#getCreativeTab, you'll see that it always uses the Block's creative tab and ignores the one set with Item#setCreativeTab. You need to use Block#setCreativeTab instead.
  21. The field is protected, so it can only be accessed normally from a subclass of RenderLivingBase or from a class in the same package as it. Since your code is neither of those, you'll need to access it via reflection.
  22. CommonProxy subscribes to RegistryEvent.Register<Block> and calls BlockRegistry#register, which registers all of your Blocks. BlockRegistry also subscribes to RegistryEvent.Register<Block> and registers the same Blocks a second time, resulting in this warning. Also see Code Style Issue 1. Your registration code should be largely self-contained, the class that registers the Blocks and Items should be the same one that subscribes to RegistryEvent.Register; there's no reason to subscribe to it in one class and call methods in another class to do the actual registration. You can see how I handle Block and ItemBlock registration in my mod here.
  23. The main point of IItemColor is to separate the colour methods from the Item class (where they used to be in older versions), so you shouldn't implement it on your Item. You should implement IItemColor with a lambda or anonymous class instead. You can see how I implement and register my mod's IBlockColors and IItemColors here. ColorHandlerEvent was added in a recent 1.12.2 build, before that you needed to register them in init.
×
×
  • Create New...

Important Information

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