V0idWa1k3r

Finishing @Animefan8888's response - you've never set this to anything. So it's zero by default and Random.nextInt(0) will crash. And yeah, those field names... Also if you want to add something to the drops of an entity use loottables.

Field f = null; try { //noinspection JavaReflectionMemberAccess f = Blocks.class.getDeclaredField("field_150480_ab"); //The obfuscated field name for the current version of the Blocks class } catch (NoSuchFieldException e) { try { f = Blocks.class.getDeclaredField("FIRE"); } catch (NoSuchFieldException e1) { e1.printStackTrace(); } } Instead of all this you could've just used ReflectionHelper.findField It might just be me but I really dislike magic numbers like this one. Although in this case it is quite easy to understand what this is doing I would still write this with a reference to the constant instead: That's kinda what I thought too but from my debugging the Blocks class gets initialized before the block registry event is fired, so it always grabs the vanilla blocks from the registy even if mods override them later. I will do more debugging later.

What do you mean "fix this"? You've linked a commit, not an issue. A commit that is fixing an issue. What do you need to do exactly?

1.7.10 is no longer supported on this forum. Update to a modern version of minecraft to receive support.

It depends on how your configuration is setup. Are you using the suggested @Config annotation system? If you are it's just a matter of referencing the fields in the annotated class. If you are not however then you can get the data from the configuration using various getters provided by Configuration class, like Configuration#getFloat for example.

Why do you need that exactly? What are you trying to achieve?

Well, you are popping the matrix twice thus completely screwing it up.

This tells forge to do nothing and proceed with the default game logic. The string passed to TextComponentString can't be null. Well set the message returned by the event to the empty line. Not null, but an empty string. Then send an empty line and your message to the chat. The order is reversed because the event's message is the one that is displayed last.

I don't think I could provide more detail even if I wanted to. I gave you the method names, their location and even which overload to use.

Well, show what you've tried.

Use the overload of GameRegistry.addSmelting(or FurnaceRecipes#addSmeltingRecipe) that takes an ItemStack as it's first parameter

Well, there isn't an event for detecting any chat message but there is a ClientChatEvent that is fired every time most messages get added to the client's chat. It may not work for something like command messages though. For stuff like that you will need to manually check for changes in the client's chat. You can use GuiNewChat.chatLines to get all the chat lines(private, needs reflection) or GuiNewChat#getSentMessages(only works for the messages the client sent at any point, not the received ones) and check for changes in those lists, then modify them if you need it. You can get an instance of GuiNewChat with GuiIngame#getChatGUI and you can get an instance of GuiIngame with Minecraft.ingameGUI

This doesn't look right. Apart from that use the debugger to check whether the client is even aware that the dragon has a banner in it's inventory in the first place.

I did some debugging with your code and here are the results: Turns out this is not the right event to render things in the world because the GL matrices aren't correct. RenderWorldLast works just fine though. These 3 parameters are the x,y,z relative to the camera's position, not relative to 0,0,0 in the world. So kept like this they will make the text render 64 blocks directly above the camera. So to render at 0, 64, 0 you would need to translate against the camera first by subtracting the camera's position from these coordinates. These parameters don't want the yaw and pitch, they want the RenderManager.playerViewY and RenderManager.playerViewX instead. Use Minecraft.fontRenderer instead. After I've applied all these fixes the nameplate did indeed render in the world.

Well there is a ScreenshotEvent...

Um, what other options are you looking for exactly? You can either delete the stuff you don't need or don't. Can you describe what you want to happen? If the world loads up with some registry entries missing it will always tell the player about that and there is no way around that nor should there be.

That's due to the projection matrix being setup for the display. You can change that too - see this topic.

You have a wrong concept of TileEntities. TEs are attached to blocks. World#addTileEntity puts the given TE into a BlockPos <-> TE map. A TileEntity can't really be detached from a block and still function/render correctly unless it's coded to do so. That has nothing to do with TileEntities, the banner is rendered as an item on the player's head much like a pumpkin is. There are two ways to do this. Either copy what TileEntityBannerRenderer does but without an actual banner tileentity present(pull the data from the ItemStack) or simply render the banner in the same way the items are rendered on the player's head - you can see how the game does that in LayerCustomHead. Really the only method you actually need is ItemRenderer#renderItem. And you would need to adjust the GL matrix to your dragon of course. The second option is preferred in my opinion.

when is this initialized? It could be null. This has two phases - you need to check the phase first before doing anything. This could be null when RenderTickEvent fires. These are your x,y,z coordinates. Are you sure you want it to be drawn at 0, 64, 0? If you are not crashing then your event handler isn't registered. Otherwise fix what I told you to fix.

Common proxy makes no sense, proxies exist to separate sided-only code. If your code is common then it goes anywhere else but your proxy. This makes even less sense. A server proxy either contains noop implementation for client only stuff or references to server-only classes that would crash the client in a similar way how model registration crashes the server. A common proxy can't be your server proxy. Don't use static initializers ever. Instantinate your stuff directly in the appropriate registry event. Don't use this outdated method of registering your TEs. Use the overload that takes a ResourceLocation instead. Why are your blocks and items declared in two separate places(ObjectHandler and ModBlocks/ModItems)? This makes no sense because they are different objects/instances of the same class where only one is registered. IHasModel is stupid. All Items need models, no exceptions and nothing about model registration requires access to private/protected things. Register your models in the ModelRegistryEvent directly. You are registering your items/blocks twice. Once in the RegistryHandler, once in the ObjectHandler. You also have your Item/Block classes copied in two packages, the projecteplus one and the gameObjs one. Please structure your mod/repository correctly. Maybe I am blind here but I can't see any class in your repository that would implement IGuiHandler. The GUI/Container pair won't magically open itself just becaue you've invoked EntityPlayer#openGui. You need a registered IGuiHandler implementation.

You could've also looked at the examples vanilla has like RecipesArmorDyes for example. That one also returns an empty stack at it's IRecipe#getRecipeOutput.

Well obviously this won't work. An Event can't be equal to a Block, this is basic OOP. The event has a getter that will get you the IBlockState of the block being broken and you can then get the block with IBlockState#getBlock and compare that. The drop chance applies to all the items at the same time, not to the one you've added. If you want a chance for your item to drop then only add the item to the list if the random check succeeds.

Your github repository is setup incorrectly. The root directory of your repository must be the root directory of your project. CommonProxy makes no sense. Proxies exist to separate sided-only code. If your code is common it goes into your main mod file or literally anywhere else but the proxy. Don't ever use static initializers. Instantinate your stuff in the appropriate registry events. Unlocalized names have nothing to do with anything but displaying the item's name. Just use item.getRegistryName instead. @Override public void preInit() { super.preInit(); ItemRegistery.registerItemsModel(); } No items or blocks have been registered by preinit yet. It is too early to register models. There is a specific ModelRegistryEvent for you to register your models in and not anywhere else. { "variants": { "defaults": { "model": "learn:ruby_ore" }, "normal": { "model": "learn:ruby_ore" }, "inventory": { "model": "learn:ruby_ore" } } } Why are you specifying the variant named "defaults"? You don't need to specify the "inventory" variant either. Apart from all that look at the log the game generates during startup. It tells you all you need to know about any issues.

Yes, absolutely. You would need to rethink your recipe logic though and instead of having n recipes where n is the amount of items matching the criteria you would have one recipe that matches all tools matching the criteria and determines the outcome based on the inputs dynamically. Then you can register that recipe with json and a custom factory just fine.

When you update the counter in your TE you need to do 2 things: In order for the texture to change you need to notify the client of the new value of the counter and tell it to re-render the block. TileEntity#markDirty only notifies the chunk that the data has changed and needs to be serialized, it doesn't do anything with the client. When the state of the lit field changes you need to notify all neighbouring blocks of the change in order for the redstone to update. See BlockLever#onBlockActivated as an example of what to do.