Leaderboard

Many Block methods (like Block#isOpaqueCube) have been deprecated by Mojang to signal that they should be overridden but not called; the corresponding IBlockProperties methods (inherited by IBlockState) should be called instead. Other methods have been deprecated by Forge to signal that they shouldn't be used at all, these usually include a comment explaining which method to use instead.

Don't extend BlockLiquid or create your own property; just use Material.WATER and include the BlockLiquid.LEVEL property. Since your Block has a property, you either need to include the property's values in your blockstates file or ignore the property by registering an IStateMapper for the Block by calling ModelLoader.setCustomStateMapper in ModelRegistryEvent. You can create the IStateMapper using StateMap.Builder. It won't render water on any side of the block not touching water:

Using Material.WATER does allow the model to be rendered with water surrounding it, as I explain here: A screenshot of the effect (with Night Vision and Water Breathing active):

Minecraft 1.12: The newest version of Minecraft has been released. Forge has been updated to support this new version. However due to the way Mojang implemented the Recipe changes there are a lot of under the hood changes that we need to do. Most notably re-writing on of the largest/most intricate systems of Forge, The Registry system. This will take some time, so do not expect a recommended release quickly. However if you are a modder you can start using the current versions to build against. Some API's may change in the early days of Forge so be sure to be ready for that. I'm sorry, I usually try my best to maintain binary compatibility, but it's just what will need to happen. For users, you can use the current builds. But just be warned that things are actively being developed and we ask to please responsibly report issues on the forum. Once I finish the rewrite and get a stable recommended build of Forge out I will make a more detailed post listing all the major changes like I always do. New Policy on Coremods: Sadly core modding is still a thing. As always we request that you guys attempt to work with us to get changes into Forge instead of core modding it yourself. However, if you MUST we have decided to put forth to the community a few 'Best Practices' for core modding. The intention is that large communities such as FTB, Technic, and Curse work with us to promote these best practices. 1) Coremod must be the coremod only, and no extra library/features/apis/etc. There are far too many coremods in the community that package tons of classes that have nothing to do with the modifications they make to the game together so that people will be forced to use their coremod just because they want a utility. This is bad. So Coremods themselves should be limited to JUST the IFMLLoadingPlugin, and IClassTransformers, and as few utility methods needed to make those hooks run. 2) Coremod binaries must be signed. This is a very basic thing that just verifies the person/organization we think made the coremods actually did. It also verifies that the file that was downloaded has not been modified in any way. As it sits there will NOT be any central authority on the keys used to sign things. So Self-signing will be allowed as long as you provide the community your signature. Starting in 1.13, with the loading system rewrite, users will be prompted to accept signatures of coremods. It is our intention to work with people like FTB, Curse, and others to make these signatures easy to use and manage. For example a user would say they trust FTB, and wouldn't be prompted for every coremod that exists in a FTB modpack. For the technical side you can read more about Jar Signing here: https://docs.oracle.com/javase/tutorial/deployment/jar/signindex.html 3) Coremods should be visible source. This will be a controversial standard, but my thoughts on it is that if you're screwing with someone else's code (which is the only reason to ever write a coremod), then you should be willing to show what you are doing. It is stressed that this is VISIBLE SOURCE only. It is not a requirement that you allow others to use your code, or modify and distribute it. It's simply that we can see it. The signatures and visible source are NOT designed to be security measures. As there is nothing preventing malicious code from being signed and a user accepting it. This is just the risk you run with Minecraft modding as you're running compiled code from random people on the internet. This is however designed to make the community more open and try and stem the number of coremods out there that have no reason to be coremods. Major Policy change: I am happy to officially announce a new member of the Forge team. Everyone welcome Mezz. His official responsibilities are to be the Pull Request, and Issues manager. Basically, he's the guy you yell at if your PR/Issue is rotting on github. He's the guy who is tasked with reminding me that they exists. He will be the one responsible for filtering all the PRs/Issues before they get to me. So I don't have to deal with telling you guys to follow the standards like making a test mod, posting logs, etc.. In addition, he is also the one who decides if old versions will have PRs accepted. Yes this means there will be a limited development system for older versions. How far back that means is ENTIRELY up to Mezz. However the rules are that ANY pr adding features for a old version MUST be applied and accepted for the current version FIRST. Save for features that would have no place in the new version. Example being adding a new achievements hook when the new version removed achievements. It will still be our official stance on this forum to only provide support for the Current version, and the previous version. However, if the community wishes to have a few dedicated people step forward and become our Legacy support team them I am willing to work with them and see what we can set up. The main reason we do not provide support for old versions is simply we do not have the manpower. So start helping out! Response From Sponge:

No, not right now. The amount of people who screw this up accidently outweighs those who do it intentionally. So you're stuck dealing witht eh idiots. For now, just deal with the log lines.

Block#onEntityWalk is called when an entity (that can trigger walking) walks on top of a block. If a block has a collision bounding box smaller than a full block, Block#onEntityCollidedWithBlock is called when an entity collides with the block. You can override one of these two methods to check if the entity is an instance of EntityLivingBase and then use EntityLivingBase#addPotionEffect to add a potion effect to the entity.

Override Block#getBlockLayer to return BlockRenderLayer.CUTOUT or BlockRenderLayer.CUTOUT_MIPPED. The Grey Ghost explains render layers in more detail here. Override Block#isOpaqueCube to return false.

There is no property with the name "LEVEL" in your Block's BlockStateContainer, so BlockStateContainer#getProperty returns null and you call StateMap.Builder#ignore with this null value. The name of the BlockLiquid.LEVEL property is "level". Don't call Block#createState yourself, don't store the BlockStateContainer in a static field and don't use BlockStateContainer#getProperty to get the property. Just reference BlockLiquid.LEVEL directly.

Minecraft couldn't find an item model or blockstates variant for the Items tut:itemtutitem and tut:tutblock. Minecraft couldn't find a blockstates file for the Block tut:tutblock. Are you sure your JSON files have the right names and paths? Have you set up your IDE project as per the documentation?

It's worth noting that you can use an OreIngredient (forge:ore_dict) in any recipe now, not just Forge's ore recipes (forge:ore_shaped and forge:ore_shapeless).

You need to add the LEVEL property to your block's BlockStateContainer, by overriding createBlockState. Setting your block's material to water won't make any difference to the way it renders though. If you want it to look like water you'll need to model it yourself.

Also, please don't just blindly follow the tutorials and don't copypaste. There are tons of threads on this forum from people who don't understand their copypasted code and asking stupid questions. The goal is to understand how things work and then write your own code.

Yes, Forge is - it will only call the method on the client. But like draco said, the JVM isn't clever enough to know the method won't get called, so it crashes as soon as it finds a reference to a nonexistent class. You won't have any problems when you run code like that on the physical client because all the referenced classes are present - it's only the server that will crash. @SideOnly isn't forbidden, it's just that it needs to be used correctly. People get mixed up about the difference between logical and physical sides - @SideOnly applies to physical sides.

Yes, and I misspoke ModelRegistryEvent is not the Client Side only class (at least it is not marked with @SideOnly(Side.CLIENT)), but ModelLoader is. And if you compile a Common or Server class with ModelLoader referenced in it it will crash with a "Class Not Found Exception". Seeing as how the class doesn't exist in the servers files.

The problem is that all the client stuff isn't available on server. Should a server try to run a class that contains client code (even if its not directly executed) it will crash in almost all cases. I would run a setup with two classes, a YourModItems class and a ClientRendererItems class. YourModItems has a list of all your items and a method to register them that is started by the common proxy. Your ClientItemRenderer has a function that loops through all your items in the YourModItems class and registers the rendering stuff for them.

That has nothing to do with it. Pretend you are the JVM. When you load a class you need to check that the class contains valid code. Ie that every referenced class with its already loaded or can be found and loaded if it is needed. The JVM cannot predict whether or not a given method will execute, so it assumes that all of them will at some point. The JVM scans through your class, finds a reference to a ModelRegistryEvent, attempts to locate this class, and fails to do so.

Isn't forge smart enough to call the method with ModelRegistryEvent on the client only? I didn't have any problems with this being in the common class. And, isn't @SideOnly kind of... "forbidden"?

@ObjectHolder as far as I know don't really have advantages or disadvantages in this case. Instead of an array I suggest a ArrayList. That way you have access to List#add. Also you will need to move your ModelRegistryEvent to another class or it will crash the dedicated server as it is a Client side only class. You also will need to put @SideOnly(SIde.CLIENT) at the top of your class.

Register methods must be static. You put what you register . You can create new items right in that event and then take them from @ObjectHolder class later, or do some form of storage (array, separate instances). To keep code clean, it's better to move your model registries into the model RegisterHandler and completely get rid of _Items class.

Obviously what you are trying to register...aka your items.

This is not the proper way to register them. You must do event.getRegistry().register...

Please post your code. It'd be nice if you create a github project or at least post each file to gist.

Hi everyone! Here is a simple teleporter mod I've created. The mod only adds one item to the game in total. shift-rightclick(sneak-rightclick) to set the register your current information and the name you assign it to the item. Normal right clicks to teleport to the location you assigned. Very easy to locate the teleporter you want to use by the name if you have a bunch of them in your inventory. This is also very convenient for emergency uses like escaping someone: just right click and you are gone! There's problems like dimensions and such that exists, if you used it and liked it, please comment or message me to let me know there are people who uses this and I will fix them! Also if you have suggestions, please tell me also. Thank you in advance! Donwload link *REQUIRES FORGE 1.9: https://mega.nz/#!hZYSxQ5J!5-X4uGIOkJ3zqQToqnHJCxooDwUyjKHsDQpnTFCCwY8 Screenshots: [/img] [/img]

If they don't need the powered property, then remove that property from your door. If your door needs to have that property but you do not want it listed in the JSON file, then register a custom state mapper that doesn't use it, e.g.: ModelLoader.setCustomStateMapper( yourBlock, (new StateMap.Builder()).addPropertiesToIgnore(POWERED).build() );