Jump to content
  • Home
  • Files
  • Docs
Topics
  • All Content

  • This Topic
  • This Forum

  • Advanced Search
  • Existing user? Sign In  

    Sign In



    • Not recommended on shared computers


    • Forgot your password?

  • Sign Up
  • All Activity
  • Home
  • Mod Developer Central
  • Modder Support
  • Common issues and recommendations
Currently Supported: 1.16.X (Latest) and 1.15.X (LTS)
Sign in to follow this  
Followers 1
diesieben07

Common issues and recommendations

By diesieben07, November 23, 2017 in Modder Support

  • Start new topic

Recommended Posts

diesieben07    7614

diesieben07

diesieben07    7614

  • Reality Controller
  • diesieben07
  • Forum Team
  • 7614
  • 55193 posts
Posted November 23, 2017 (edited)

What is this?

This is a collection of common issues and recommendations for the Modder Support subforum. Instead of repeating these things over and over again, a link to this thread can be used instead.

This post will be updated as needed.

Suggestions either via PM to me or in a separate thread to keep this topic clean.

Edited November 24, 2017 by diesieben07
  • Like 12
  • Thanks 4
  • Haha 2

Share this post


Link to post
Share on other sites

diesieben07    7614

diesieben07

diesieben07    7614

  • Reality Controller
  • diesieben07
  • Forum Team
  • 7614
  • 55193 posts
Posted November 24, 2017 (edited)

Problematic Code

  1. Please use the registry events to register your blocks, items and other registry entries.
  2. Use ModelLoader.setCustomModelResourceLocation in ModelRegistryEvent to register your item models. Do not use the ItemModelMesher.

  3. Do not use methods that are deprecated in Forge or vanilla Minecraft. Usually there will be an explanatory method next to the method explaining what to use instead.
    There is an exception for methods in the Block class, these may be overridden. Instead of calling them, use the one in IBlockState resp. it's supertypes. 

  4. Do not use ITileEntityProvider or BlockContainer. These classes are legacy vanilla code. To add a TileEntity to your Block, override hasTileEntity and createTileEntity in your Block class. 

  5. Do not use IInventory. Use the capability API with IItemHandler.

  6. Do not reach across logical sides. This will cause subtle and not-so-subtle issues that may occur randomly and very rarely. Read and understand the documentation about sides to understand why this is a bad idea.
  7. Do not use the unlocalized names for things other than displaying the name of a block/item. If you want to access the registry name for a registry entry, use IForgeRegistryEntry::getRegistryName.
  8. Do not use numerical IDs for registry entries. They can and will change. Use the static references in e.g. the Items class or use textual IDs (e.g. minecraft:stone) if you need dynamic references.
  9. Any IForgeRegistryEntry (commonly items and blocks) is singleton-like. That means that there is only once instance of your block class. There is not a new Block instance for every position in the world and there is not a new Item instance for every ItemStack. This means that you cannot store position-related things as instance fields in your block class, etc. You must use a TileEntity resp. the NBT data on ItemStack.
  10. Unlocalized names, TileEntity registration names and enum entries added using EnumHelper should contain your ModID to avoid collisions between mods. Note: This also applies to the unlocalized name for entities (set by EntityEntryBuilder::name resp. the entityName parameter of EntityRegistry.registerModEntity).
  11. A TileEntity class must have a no-argument constructor. As a general recommendation a TileEntity should not have more than this one constructor, to avoid confusion.
  12. An ItemStack variable should never be null and all of vanilla and Forge code expects this to be the case. Use ItemStack.EMPTY instead of null and ItemStack::isEmpty to check for empty stacks. Do not compare against ItemStack.EMPTY.
  13. Registry names and asset file names must be completely lowercase.
  14. Do not create registry entries (anything implementing IForgeRegistryEntry, like blocks and items) in a static initializer. Use the proper events.
  15. Do not access client-only code from common code, use the @SidedProxy system. See the documentation about sides (in particular the section about @SidedProxy) for more information.
  16. Do not implement IMessage and IMessageHandler on the same class. It does not make logical sense and leads to confusion and hard to trace bugs.
  17. Handle exceptions properly. Do not avoid a game crash at all costs, sometimes it is okay to crash the game. Read this article for more information.
Edited November 26, 2018 by diesieben07
  • Like 5
  • Thanks 2

Share this post


Link to post
Share on other sites

diesieben07    7614

diesieben07

diesieben07    7614

  • Reality Controller
  • diesieben07
  • Forum Team
  • 7614
  • 55193 posts
Posted November 24, 2017 (edited)

Code-Style

  1. The concept of a "common proxy" does not make sense. The whole point of @SidedProxy is to abstract over client specific and server specific behavior, the opposite of "common". Common code should go in your main mod class.
  2. Use @Override when you intend to override methods. This helps tremendously when updating your code for new versions of Minecraft, but in general is good practice. Read this Stack Overflow answer for an explanation.
  3. Using an interface (usually called IHasModel) on your Item and/or Block classes to denote that they are capable of registering a model is an anti-pattern and not necessary. All items require a model to be registered for them and usually no type-specific information from the item is needed, only the registry name, which is accessible for all items by default.
  4. Do not abuse inheritance for code-reuse. This often manifests in classes like ItemBase, BaseItem or ItemExampleMod. Using this pattern prevents you from extending other essential classes, such as ItemFood and in that case requires code duplication. Prefer composition or utility methods instead to reuse code.
Edited February 20, 2019 by diesieben07
  • Like 7

Share this post


Link to post
Share on other sites

diesieben07    7614

diesieben07

diesieben07    7614

  • Reality Controller
  • diesieben07
  • Forum Team
  • 7614
  • 55193 posts
Posted November 28, 2017 (edited)

General issues

  1. Do not use the "export" or "create jar file" functionalities of your IDE or other means to create your final mod file. You must use the Gradle build task. See the documentation for more info.
  2. When creating a Git repository for your mod, the repository root should be where your build.gradle file is. The MDK ships with a default .gitignore file so that only the necessary files will be added to version control.
Edited June 18, 2018 by diesieben07
  • Like 5

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.
Sign in to follow this  
Followers 1
Go To Topic Listing



  • Recently Browsing

    No registered users viewing this page.

  • Posts

    • DaemonUmbra
      net.minecraft.world.biome.biome$category cannot be cast to java.lang.string

      By DaemonUmbra · Posted 1 hour ago

      Same answer  
    • DaemonUmbra
      1.12.2 won’t install

      By DaemonUmbra · Posted 1 hour ago

      1.12 is no longer supported on this forum. Please update to a modern version of Minecraft to receive support.
    • DaemonUmbra
      1.16.5 Modpack "Missing License Information"

      By DaemonUmbra · Posted 1 hour ago

      This is either a bug in a mod, or you installed mods that won't work with your current version of Minecraft. Note that mods are rarely ever compatible with multiple versions of Minecraft.
    • kiou.23
      [1.16.4] Custom item enchantability

      By kiou.23 · Posted 1 hour ago

      well obviously, Enchantment#canApply(), calls ItemStack#CanApplyAtEnchantingTable(), which calls Item#canApplyAtEnchantingTable. Therefore, you got yourself an infinite loop...
    • AndrewLI
      World creation in 1.16.x

      By AndrewLI · Posted 1 hour ago

      Hi I want to write a new mod in forge 1.16.4, which should generate a new (water) world, and add later the usual blocks there. But I found only old tutorials, that use IWorldGenerator. And I cannot find a new (json-based) world generator. Does anyone know a tutorial or documentation of the new world generation?
  • Topics

    • LOLCREW
      3
      net.minecraft.world.biome.biome$category cannot be cast to java.lang.string

      By LOLCREW
      Started January 8

    • Winterlotus16
      1
      1.12.2 won’t install

      By Winterlotus16
      Started 2 hours ago

    • elliotfoxk
      1
      1.16.5 Modpack "Missing License Information"

      By elliotfoxk
      Started 2 hours ago

    • AzizD
      4
      [1.16.4] Custom item enchantability

      By AzizD
      Started 4 hours ago

    • AndrewLI
      0
      World creation in 1.16.x

      By AndrewLI
      Started 1 hour ago

  • Who's Online (See full list)

    • AtlasTheFirst
    • Zemelua
    • Winterlotus16
    • ZTurtleTortoiose
    • MoeBoy76
    • Bradycole13
  • All Activity
  • Home
  • Mod Developer Central
  • Modder Support
  • Common issues and recommendations
  • Theme

Copyright © 2019 ForgeDevelopment LLC · Ads by Longitude Ads LLC Powered by Invision Community