V0idWa1k3r

Depends on what you want to do. It is generally recommended to use json recipes whenever possible since you get: No ~1000line-long classes that register various recipes but instead each recipe is neatly in it's own file. Easy to edit anytime you want without having to spend minutes trying to search for that one line that defines the recipe Any pack maker can easily alter your recipe with a datapack(1.13). No specific recipe-altering mods required. The _constants file. In it you can easily define a constant that corresponds to an item. Or to multiple items. Or to an oredict enty. Or to both. Here is an example of me using one constant to handle differently named oredict entries. While you kinda can do the same with hardcoded recipes it's not as intuitive and easy as just writing a couple of files in your json. If something goes wrong with a json recipe the game will kindly provide a log of what went wrong. If something goes wrong with a hardcoded recipe - it just will be missing from the game with no indication as to why. You will need all your recipes to be json recipes for 1.13 anyway. However for some complex recipes you will need to use "hardcoded" IRecipe implementation. An example of that would be leather armor dyeing or firework making. There is however a point to be made that even custom IRecipe implementations can still be registered with json as I do here and here. If you are using json recipes simply create a recipes folder in your assets/modid folder. All json recipes will then go there. Here is a minecraftwiki page with a description of the format and here is the examples I used myself provided by Lex. If you are using in-code registration subscribe to RegistryEvent.Register<IRecipe> and use event.getRegistry().register to register your recipes. Do not forget to give them a registry name!

You can't directly transform the metadata from a blockstate to a metadata of an ItemStack. For example the metadata of a sideways spruce log would be 5. An itemstack of a log block with a metadata of 5 would be something completely invalid since log metadata for items only goes as high as 3 - as you can see this approach doesn't work since metadata of items and metadata of associated blocks can represent completely different things since as I've said metadata of blocks is only used for serialization. The most accurate solution to getting an ItemStack from a block I can think of is Block#getPickBlock. While it is not 100% accurate(depends on the implementation especially for modded blocks) it is the ItemStack that is associated with middle-clicking that block and in most cases it will be the ItemStack representation of that block with that particular state in the world.

What are you trying to achieve? The only way I can think of is to invoke Block#getMetaFromState. But you shouldn't be using metadata from blockstates directly as it is pretty much only used for serialization purposes.

Why is your texture an .obj file? No. When a model is looked up in the game the blocks/models/ path is added automatically. With your path the game tries to look for the model at momcraft:blocks/models/blocks/models/magic_node.obj which is incorrect. Just specify your path as momcraft:magic_node.obj similar to how I do here.

It makes no sense. Proxies are objects which are injected into the field based on the physical side the game is on. The entire point of a proxy is to separate sided-only code. Your "common" code can go anywhere else. A common proxy is using proxies in the only way they are not supposed to be used.

No. That is hardcoded at EntityFallingBlock#fall and there are currently no forge hooks into it as far as I can tell.

There is a reason models are limited to 2 blocks tall max and you shouldn't even do that. Models should be a 1x1x1 cube. If you need a big model either use a TESR or multiple blocks each with different parts of the bigger model. The collision boxes won't work properly if they are greater than 1x1.5x1 and even the 1.5x on the y axis is a hack in vanilla. Solution - use multiple blocks for big collision boxes.

You can use AnvilRepairEvent to control the chance of the anvil damaging when it is used to repair/combine items.

MobEffects.LEVITATION

You are overriding Entity#entityInit to do nothing. entityInit is responsible for registering keys into the data manager of the entity. In your implementation no keys are being registered so when the game tries to set the health for the mob it crashes because health is managed via datamanager.

You cannot blindly assume that any entity hit by your projectile is a subclass of EntityLivingBase. Use instanceof before casting.

If you are registering a class object to the event bus your event handers must be static. To have non-static handlers working register an instance of your class to the bus. https://mcforge.readthedocs.io/en/latest/events/intro/#static-event-handlers

This is based on your resources pack format. If you have a pack.mcmeta file that specifies the pack_format as 3 then all resource names MUST be lowercase including the lang file. If you are using format 2(happens if you do not specify the format at all then forge will use LegacyV2Adapter) then lang files must be as en_US.

You are getting your ItemBlock instance from a fresh instance of Block but you should be getting it from the actual block that is already registered. Your ItemBlock instance points to an unregistered instance of a Block. I do not know if this is a source of your problem but it is still a big issue. To be clear public static final Block[] MOD_BLOCKS = new Block[] { new UraniumBlock() }; public static final String MOD_ID = "blueshades"; public static final Item[] MOD_ITEM_BLOCKS = new ItemBlock[] { new UraniumBlock().toItemBlock() }; You have 2 different instances of UraniumBlock here, only one of which gets registered and it's not the one your ItemBlock referres to.

Use another super constructor call in your ToolAxe constructor. The one that takes a ToolMaterial, float, float.

The last parameter of World#createExplosion is a boolean controlling whether the explosion damages terrain.

You do not need to cast a float to a float. Why is your networkwrapper in your proxy? And this looks like a Code-style Issue #1 to me. I think that your issue is here. Explosions with a very low power value will not damage entities.

Wrong subforum. Banners use vanilla's hacky TE based rendering. They are not rendered as other items are so they are not something you can base your rendering on. You have 2 options: Use forge's blockstates with sub-models. Using sub-models you can just define 16*3 variants instead of 163. Use custom BakedModels with a custom ICustomModelLoader. I think this is what Tinkers does.

Why are you using lastTickPos insread of pos? As long as you pass your actions to a server thread this is the correct way to do this. Show more of your code preferrably as a git repository so I can debug it myself.

To specify a model based on NBT data look at vanilla's ItemBow and it's model. While it doesn't use NBT data you can easily adapt the code there to use NBT. By the error in your log it looks like vanilla json can't have a non-vanilla obj(provided by forge) as it's parent.

Your model's parent model is block/block yet you've specified the textures for block/orientable. Edit: well I'm slow

This happens because you extended BlockContainer which overrides Block#getRenderType to return INVISIBLE. Either do not extend BlockContainer and override Block#hasTileEntity and Block#createTileEntity or override Block#getRenderType and return EnumBlockRenderType.MODEL.

Detect the key press client-side then send a packet to the server and spawn the explosion.

Yaw and pitch are angles for rotation. Use Entity#getLookVec to get the vector of where the player is looking to then rotate and translate it until you get the desired result.

You must return an object that extends GuiScreen in your GuiHandler#getClientGuiElement. You are returning a Container.