V0idWa1k3r

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.

Why would you simply copy-paste my proxy implementation? You don't need any of those methods. I only provided you with an example of how to use an interface for your proxy, I didn't tell "hey, here is my code, copy all of it!" You have never instantinated any of your blocks. Your array that you pass to the register method is an array of nulls. Instantinate your blocks before registering them. It is very obvious. But don't use static initializers. Instantinate them directly in the registry event. Don't use a method that is extremely outdated and deprecated. Use the overload that takes in a ResourceLocation as it's second argument. Your ItemsInit and ArmourInit are still not changed, but for some reason reuploaded. You need to fix those too. @SidedProxy(clientSide = Reference.CLIENTPROXY) public static ClientProxy proxy; This makes no sense. Again, proxies exist for separating sided only code. Please, understand what you are doing and how things work. A ClientProxy is a class that only loads on the physical client. A ServerProxy is a class that only loads on the physical server. A IProxy interface defines methods that these proxies share so you can call them without having to care which side you are on. Why do you have a Constants class and a Reference class if they both serve the same purpose - hosting final fields? Also your reference class still references the common proxy. Your RecipeHandler must not exist. Recipes must be done via json, not code. I mean you could use code for your recipes still since it is 1.12 but this option is out in 1.13 - every recipe must have a json counterpart in 1.13. You might as well start defining your recipes via json now than having to rewrite everything into json once 1.13 hits. Why is RegistryHandler still a thing again?

Sure

Well first of all your repository is setup incorrectly. Your root directory must be your root workspace directory, not the main folder, not even the src folder. Next up - why on earth do you have 2 mods in your repository? Which one am I supposed to be looking at? I'm assuming the AE Addon one, correct? Common proxy makes no sense. Proxies exist to separate sided-only code. If your code is common it goes into your main mod class. Hmm, wait a second, didn't I already tell you not to use CommonProxy? Why yes I did. Well I shouldn't be too harsh on you, you did listen when we told you not to use IHasModel after all, so good job on that. Now delete your CommonProxy, replace it with an interface and we shall never speak of this again. I am just going to quote myself from the post I've just linked public static void registerItem(Item item) { ForgeRegistries.ITEMS.register(item); item.setCreativeTab(ModClass.kryptonitetab); ModelLoader.setCustomModelResourceLocation(item, 0, new ModelResourceLocation(item.getRegistryName(), "inventory")); } You can't do this. First of all ModelLoader is a client-side only class, you can't invoke it in common code like this, it will crash the server. And even if you could - this is too early to be invoking it. Models must be registered in the ModelRegistryEvent and not somewhere else. public static void Client() { RecipeHandler.registerCrafting(); RecipeHandler.registerSmelting(); } Recipes are a common thing. Both the client and the server need to know about them. It makes no sense to only register them on the client. First of all I am in the middle of my reply here, nice. Secondly this is not a chat room, be patient. And finally you don't even need to "bump" your post, it is in the top 3 posts... Registry names must be entirely lower-case. Same with asset names. No. Don't ever access the registries like that. Use the appropriate RegistryEvent.Register events and access the registry provided to you by the event. public static void registerBlock(Block block) { ForgeRegistries.BLOCKS.register(block); block.setCreativeTab(ModClass.kryptonitetab); ItemBlock item = new ItemBlock(block); item.setRegistryName(block.getRegistryName()); ForgeRegistries.ITEMS.register(item); ModelLoader.setCustomModelResourceLocation(Item.getItemFromBlock(block), 0, new ModelResourceLocation(block.getRegistryName(), null)); } You can't do that. Items and blocks have separate registries and thus separate registry events. You can't register them both in the same event, that's not how anything works. Also: I already told you to do this in the appropriate event, but as an addition - variants can't be null. If you don't know which variant to pass to the item pass "inventory". Oh yeah, let me emphasise - you MUST register your stuff in the appropriate registry events. Not in your pre init. Please fix all of that, update your repository and then I will take a look at it again to try and determine what's wrong with your model registration. Right now the fact that the game even starts is a miracle.

Well first and foremost stop using GL11 directly. Use GlStateManager. Why do you need to disable the GUI scaling exactly? You can easily draw anything you want based on width/height and have your fullscreen GUI independent of the scaling factor. You don't actually need to be pushing/popping matrix here at all because if you are doing it in the middle of your operations you are screwing them up and once your drawing is done the game will reset the matrix anyway. The matrix mode is already modelview though. You've just set it to modelview 7 lines above and you haven't changed it. Any reason you are doing this? The game just did that for you like 6 operations or so ago. You are not using a different framebuffer after all and the one currently in use has just been cleared. You don't need to be doing this. The viewport is already set to the game's display width/height. Or to the custom framebuffer's resolution. In fact you could be screwing up someone's framebuffer setup by doing that. Apart from all that looks fine-ish to me. Fix all that and see if you have any more issues.

CommonProxy makes no sense. Proxies exist to separate sided-only code. If your code is common then it goes into your main mod file. In fact I am pretty sure that this is the root cause of your problem. You can't do this on a server. Translations are a client-side only thing.

In addition to what everyone else said I've seen people say that people using static initializers is the only thing that prevents registries from being reloadable during runtime.

Yes you do. Registry events are events where you register your things. RegistryEvent.Register<? extends IForgeRegistryEntry>. If you have any items/blocks present in your mod you are using registry events. Yes you do. You are currently instantinating your objects in static initializers. Just do the same in the registry event instead. Well maybe it is time to start. You can't really solve issues without a debugger and you can't write pretty much anything above a hello world application if you can't solve issues. They are a java feature. If you don't know java then you need to learn it before making a mod otherwise you are constructing a rocket without any instructions.

Don't do this, use ItemStack#isEmpty instead. An item stack may be empty but not equal to ItemStack.EMPTY. Don't ever use static initializers. Instantinate your stuff directly in the appropriate registry event. Apart from that use the debugger to see which items are actually selected within the AABB specified and whether ut contains your axe item. You might need to extend it a bit. Also consider using java 8's streams instead of loops in cases like this one.

Unless the OP made a class that is named EventBusSubscriber there is exactly zero difference between using the class prefixed name and the non-prefixed name. More than that you already know that their event handlers are working otherwise they would not have an item at all and wouldn't be able to report a missing model issue, they would be reporting a missing item issue. As the log clearly points out their model file is not in the right location and this is the issue that needs to be fixed for the model to appear in game. This is not how anything works. We are not here to write code/organize your workspace for you. 2 people have already told you what you need to do. Your models are in the blocks and the items folders, but the game looks for the block and item folders. Notice how there is no S at the end. Your folder structure is incorrect and you need to fix this.We told you how to do it, so just do it. There is nothing hard in renaming a folder. Besides this is dropbox. The most I could do with it is download it to my PC which doesn't help your in the slightest.

The game clearly thinks otherwise because it can't find the model file at the specified location. Check the folders carefully. As @luiihns pointed out items != item. What exactly have you tried? You need to move your model json file from the models/items folder into the models/item folder. Can we see your project's folder structure?

This only checks for whether it's raining or not. It doesn't actually check for the snow(which you've wanted to know about) and it doesn't check for cases where it won't rain/snow in a biome like a desert either.

What exactly is difficult to read here? I think I've explained everything pretty clearly - telling you what's wrong, why it's wrong and how to fix it. I don't know how can I be more clear than that.