V0idWa1k3r

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.

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.

Well you obviously need to call it from some kind of event that gets called every frame. RenderWorldLast or RenderTickEvent for example. As for the arguments passed see what Render#renderLivingLabel does.

You could try to use the same logic EntityRenderer.drawNameplate has(or maybe even straight up use that method) but scale the drawn textbox with distance to the player.

Didn't I tell you already in your other topic to look at how vanilla renders it's player arm in ItemRenderer#renderArmFirstPerson? I bet their code isn't much different from vanilla's. If I were to guess then: This is likely pushMatrix This is likely translate This is likely scale This is likely popMatrix This looks like Minecraft.player EntityLivingBase.isSwingInProgress? If the previous assumption is correct then this must be EntityLivingBase.swingProgressInt Something like mc.player.getHeldItemMainhand() mc.player.getHeldItemMainhand().getItem() Minecraft.getMinecraft().getTextureManager().bindTexture(Minecraft.getMinecraft().player.getLocationSkin()); renderplayer.renderRightArm(mc.player); Minecraft.getMinecraft().getTextureManager().bindTexture(TextureMap.LOCATION_BLOCKS_TEXTURE); You could have used MCPBot or the mappings stored on your PC yourself to get these, SRG names don't really change between versions unless the method/field is deleted completely. Also I think this is slightly illegal since you are planning to use this code in your mod and not decompiling for educational purposes. Well maybe not illegal but certainly not a nice thing to do. You should've asked the mod author for their code.

This makes no sense. Again - server proxy does server-side only stuff. The things that would crash the client. Like accessing the DedicatedServer class which is marked as @SideOnly(Side.SERVER). You can't make a common proxy do what a server proxy does, that would crash the client, similar to how registering a model would crash a server. If your code doesn't crash either the server or the client then it's common code and it goes anywhere else but your proxy. Again - proxies are side-specific classes. There can't be a common proxy because there is no common side. You are either on the client or on the server. You don't need a common ancestral class to use override. An interface does the job just fine and is in fact a preferred method of using a proxy. Just... no. IGuiHandler exists for a reason, and your proxy isn't one of them. Proxies are for separating PHYSICAL sides. IGuiHandler separates the thing needed to have a GUI/Container pair on the LOGICAL sides. There is a huge difference. Then your server must also become an extension of the common by the same logic, because you need to run that common code on both physical sides, right? Then why use the proxy in the first place? It is exactly the one thing proxies were made not to do. If your code must be ran on both sides run it in any other class that has nothing to do with proxies.

Any particular reason for using 1.10 anyway? I mean some people say that they refuse to update from 1.7 because of the model system, or others say that they refuse to update from 1.8 because of the combat system, but what's wrong with 1.10 -> 1.12? Nothing of significance was changed anyway, if anything more features were added both to the base game and forge. I think that there might have been a ForgeHooksClient.registerTESRItemStack method. It exists in 1.12 but marked as deprecated so it must have existed, but I have no idea since when. If this method doesn't exist in 1.10 then I am afraid I don't know the answer here. You can trace the execution of TileEntityItemStackRenderer#renderByItem and see where forge code takes place and what do you need to do in order to hook into it though. But you really should update.

Then have it anywhere else, just don't have a CommonProxy. You don't understand my issue here. It's not that having a common ancestral class is a bad thing, it's that the whole concept of a CommonProxy makes no sense whatsoever. It's bad coding practice. A proxy can't be common by definition of what a proxy is. It's like if the String class in Java derived from a Number class. Technically a string is a bunch of chars which are just unsigned shorts which are numbers and technically there may be nothing wrong with the implementation but it makes no sense. A String isn't a Number. A proxy can't be common. And I think the fact that you even have something being done in a common proxy is the whole reason you are having this issue. If you didn't have a common proxy you would not put any code in it and thus you wouldn't have any issues.

The thing is - the player's arm is not rendered if there is any item in the player's hand whatsoever. So you can't just rotate it into existance, you need to render it yourself. Since you can't use normal models for that(because the player's arm uses player skin as it's texture) you will have to use a custom renderer. Override Item#getTileEntityItemStackRenderer to return your custom renderer. I don't know if that method is present in 1.10 so you should update(I think there is another method to do that in that version but you should update to the latest version). Then in your custom renderer you can render the player's arm as you want - you can look at ItemRenderer#renderArmFirstPerson for an example.

Well, what do you think you made the IProxy interface for? Both the ServerProxy and the ClientProxy implement it, meaning they both can be injected into a field of an IProxy type. And it also allows you to define methods that your proxies should have and thus give you the ability to call them without caring about accidentally loading client-only classes on a server(and vice-versa). Also you are registering your stuff twice. registry.registerAll(blocks); ForgeRegistries.BLOCKS.registerAll(blocks); Why? why are you registering your blocks to the registry the correct way and then immediately repeat the operation with the same registry in the way I told you to never ever do? The same applies to your items aswell. And I have already told you 3 times that you can't do this in the registry event because you will crash the server and you must do this in a ModelRegistryEvent. And I have also told you to not use this outdated method and use the overload that takes in a ResourceLocation. Please fix the issues we(or in this case I) tell you to fix before starting to code in new stuff. Your code barely works and does all the wrong things, and when I tell you to fix all those issues you just add more. This is not how programming works. You fix the issues you have first, then you start implementing new stuff. Don't just put the issues aside, it will start a "chain reaction" at some point. Post the new log. I suspect that this happens because you haven't specified the domain for your recipe type and since your recipes are the one being loaded the game appends your modid to the recipe and can't find the recipe type. Actually I am 99.9% sure that is at least one of the issues. Edit: I kinda feel guilty a bit so I will add this. I am not trying to be mean to you or anything, I am trying to help you by making you learn, since this is the best way to help a person with programming in my opinion. I kinda see how I may seem harsh but I assure you it's not my intention. You are doing pretty well correcting some of the issues I've pointed out but you need to fix them all, and that's what I am trying to say here I guess. Sorry if I sound rude or something, that's just my way of relaying information.

@SidedProxy(clientSide = Reference.CLIENTPROXY) public static ClientProxy proxy; Didn't I tell you about this 4 times already?.. You NEED to fix this. Even if it isn't related to your current issue, it still is a huge issue that will net you a crash and multiple problems later down the line. As for the recipe issue: Your json syntax is invalid. Use a json plugin for your IDE(you will have to install it using the marketplace with eclipse and I believe IDEA comes built-in with one) or an online validator like jsonlint.

That is not how forge's blockstate format works. You are trying to merge vanilla's blockstate format with forge's. Choose one. What do you need 4 models for? Just have one and rotate it around the Y axis. In fact you are already rotating them. This might be the cause of your issue.

BlockBase is an antipattern. You don't need it. Don't set the blockstate in Block#onBlockPlaced or Block#onBlockPlacedBy. Just return the state you want in Block#getStateForPlacement. if(entityFacing == EnumFacing.NORTH) { entityFacing = EnumFacing.NORTH; } else if(entityFacing == EnumFacing.EAST) { entityFacing = EnumFacing.EAST; } else if(entityFacing == EnumFacing.SOUTH) { entityFacing = EnumFacing.SOUTH; } else if(entityFacing == EnumFacing.WEST) { entityFacing = EnumFacing.WEST; } if x is x then set the x to x? Why? This is equivalent to writing if (x == 1) x = 1; It does nothing. As for the rotation - this looks correct to me. See BlockFurnace#getStateForPlacement - it does a very similar thing. So I suspect the issue may be somewhere else. Could your please show your blockstate file?

I would argue against it, actually. Imagine if your mod has a multi-block structure, say an altar and that structure is composed out of a special block, say an altar stone. In your structure's TE you check the structure by comparing block instances - this.world.getBlockState(this.pos.down()).getBlock() == MyBlocks.ALTAR_STONE. Well, now let's say that someone else makes an addon to your mod which overrides your altar stone block with their version. Their mod loads after yours so the end object in the registry is their block. But now your comparason in your TE fails because MyBlocks.ALTAR_STONE isn't even registered, much less equals the AddonBlocks.ALT_ALTAR_STONE! This problem however goes away entirely if you use ObjectHolders instead since they will be populated with the actual block that was registered. As for @TheGoldenProof's question - ObjectHolders simply tell forge "okay, after the registry event is done go through all fields annotated with ObjectHolder that match the registry that just finished being populated and put the things that the registry was populated with into those fields"

This is indeed correct. With the way you are assigning values to the fields you don't need the ObjectHolder annotation though. I would say that using ObjectHolders to obtain references to your blocks is preferred though in case you need to compare the blocks at some point. So instead of assigning values to static fields in the registry event just register your blocks and let the object holders do the job for you like I do here and here.