Matryoshika

Never register things like this. ForgeRegistries#<REGISTRY> are solely for querying & iterating over. If you want to register an object, use the RegistryEvent's. I believe that lang-file(en_US) have to be lower-case only(en_us) in 1.11+. @Choonster goes over why here.

Override Item::onUpdate. Check if the item has the NBTTag, and if it doesn't, add it.

nope, on the fact that the images are very small, and very dark. Try and override the Client-Side only method Block::getBlockLayer, and return BlockRenderLayer#CUTOUT, like Glass.

This tutorial is not the best, on a couple of notes: There is not, and never has been, a "CommonProxy". Per definition, a Minecraft-proxy can only be either Client-side only, or Server-Side, the very antonym of "common". "CommonProxy" is a misnomer and based on faulty logic. Never call ForgeRegistries#<REGISTRY>#register. Use the RegistryEvent's for this. ForgeRegistries is, and I quote the documentation, "...a central place to access registries directly... queries and iterations can use this" Likely due to #2. The code for setting the models, is never actually called. Just because you have the method doesn't mean it's gonna get used. Use the ModelRegistryEvent, and for each of your items with IHasModel, call IHasModel::registerModel.

Yes, and no. Never use null unless you are absolutely sure that it is harmless. Most of the time, using null with cause nullpointerexceptions, aka crash the game. Use World::getBlockState::getBlock to get the block. As I mentioned in my previous post, ForgeHooks::canHarvestBlock checks for you if the player CAN break the block. If it returns true, use World::breakBlock with true as the second argument to actually break the block.

That is not what I said. When someone states "call method x" you do not override it as you did here, and especially not in a class that is not an instance of the class using the original method... What you did is re-create a method that blindly says "yes" whenever it is asked. Calling a method means you actually call the method. Here that means running if(ForgeHooks.canHarvestBlock(Block, Player, World, BlockPos)){//run code here if player can break this block}

I'm sorry, but... and? Your code doesn't actually break any blocks... It just ends with "i have these blocks." You are validating the block's materials, but nothing else... of course the blocks won't break. At the end of your for-each blockpos loop, call ForgeHooks#canHarvestBlock (to make sure the player can break these blocks (in the case of protection plugins etc)) and if they can, call World::destroyBlock with true to make sure the block's drops actually drop.

No. This forum is for helping people with their own code. Giving out copy-paste-code is not helpful, neither to you, who won't learn what the actual code does, nor us, who'd have to write detailed tutorials on where, how, why and when the code does whatever it does. I've told you how to gain access to a block that the player is looking at, and how to get the specific side as well (Item::rayTrace). Now try and use it. We can help you along the way. We will not send you off with a free ticket.

Call Item::rayTrace to gain access to a RayTraceResult, which can give you a block, and specifically the side of the block. Be sure to checkRayTraceResult#Type though. It might be nothing "MISS" or an entity "ENTITY". I would call said rayTrace method in an override of Item::onBlockDestroyed, and verify that the result's blockstate equals the blockstate being destroyed.

... You don't have a texture... Textures are linked in the .mtl file, under a "map_Kd" key. Likely caused by an unsuccessful UV-mapping. It was never actually "added". Here's an example of a .mtl file with mapped textures. Oh, and for the future, please paste the contents of files like this to pastebin/github gist. Downloading (possibly malevolent) files from strangers can be off putting.

Can you post your .mtl file? Also, what be sure that the normals for your model are correct.

If you crash, then please post the crash log. We cannot help you with what we cannot see. Use pastebin.com or github gist, and link the url here. I'm betting that you're getting a nullpointer exception. Your code runs on the belief that there is always an entity where you are looking... 95% of the time, that is incorrect.

The ObjLoader does support UV-mapping. If you mean the "key x is not supported, skipping", you don't actally need those in the .mtl. You should be able to remove them without any effects on your nodel.

Would this not be possible (but ugly) with an IWorldEventListener & overriding IWorldEventListener::notifyBlockUpdate? Would require some guess-work to make sure it was indeed placed by BlockLiquid::checkForMixing, but should be viable.

You can't really "disable" a recipe. It's rather the other way around. You can "enable" a recipe. Unless you specifically make a recipe for an item, it won't have one. To remove an item from a creative tab (and per extension JEI as well), use an if-statement in the item's constructor when adding to the creative tab (Item::setCreativeTab), or override CreativeTabs::displayAllRelevantItems in your own tab and remove your disabled items from the list given to you. For full-fledged removal, you could possibly override Item::onUpdate and make sure that the items remove themselves from player's inventories if they should be disabled (players can still use /give etc)

new PotionEffect(MobEffects#RESISTANCE, duration, level)... A very simple glance at the PotionEffect constructors could have told you that...

You cannot. You can either: apply the potion with 1~2 seconds left, and re-apply it every tick or apply the potion with Integer#MAX_VALUE as time, but this means that you have to also check if the player ISN'T wearing your armour. This can also lead to false positives in which the player gets the effect from another source, but you might remove it still, because the player doesn't have your armour... You can add a method in your ClientProxy, supplying the PotionEffect that (will be/has been) added to the player, and in said method call PotionEffect::setPotionDurationMax(true). This only affects the timer cosmetically, making whatever time is left look like **:**.

Subscribe to the PlayerTick event, and check if the player has the armour equipped. If so, give the player a potion effect for 1-2 ticks (higher for nightvision/nausea (effect flickers as it ends) etc)

Code Style #1. There is no such thing as "Common Proxy". It's a misnomer. Proxies handled by @SidedProxy are either Client-Side only, or Server-side only. There are no other alternatives. As such, the way you are doing this right now, the client will not have any idea what these items are. I have a GitHub project here made for 1.10 (works just fine for 1.12.2) that shows how to use the Register event for registering your objects, and quite animatedly commenting on common bad practices that should be avoided.

First and foremost: You should rename this thread. A TESR (TileEntitySpecialRenderer) is used by TileEntities to render things dynamically. The code given, has no references at all to TESR's, but rather Entity Renderers. Now, are you sure that your OBJ model is actually being rendered? Try placing a few println's around your code. Specifically in your model null-check etc. Also try printing out wether or not your objects are empty (like your skinmap). Then there could be an issue within your actual OBJ model. What program do you use to create your OBJ models? For blender (the most common program it would seem for OBJ models in MInecraft), a default vanilla minecraft block is represented by a cube at x0.5 y-0.5 z0.5 at 0.5 scale. This should give you a sense of scale and translation between Minecraft <-> OBJ rendering program. Be sure to have your Normals correct. If they're inside out, the OBJ will render inside out AKA be invisible unless the camera is inside of the model. Also be sure that your OBJ model has correct UV-mappings. Whilst I believe you can texture the materials directly, I strongly encourage proper UV-mappings. Check how your model looks like in your OBJ rendering program. For Blender, select the "Texture Viewport" at the bottom of the screen next to Object/Edit Mode.

To damage the itemstack, call ItemStack::damageItem instead. It automatically handles breaking when durability <= 0 & deals with statistics as well. You also need to provide an empty Set<Block> instead of null when instantiating your ItemCarvingTool.

Call Chunk::getBiome(blockpos, World::getBiomeProvider) to find out what biome is at the specified block (yes, biomes are per-block (non-vertical) but stored in the chunk) To find out what chunk you are in, call World::getChunkFromBlockCoords. You can then compare the gained biome to for example Biomes#TAIGA. However, there are a LOT of biomes, and it can get quite messy with if-statements. You can try to generalize it by comparing the biomes temperatures for example Biome::getTempCategory == Biome#TempCategory#WARM. (Using :: to signify non-static methods (needs to be called from an object) and # signifies static methods)

You are iterating through all Blocks, to get their chunk... which contains 256*height blocks already, leading to getting the same chunk about as many times.... Get the BlockPos at whatever is looking for all of these tileentities (the blockpos of this scanner). Get the ChunkPos from that. Great you got the center chunk. Now you have the ChunkX & ChunkZ values. As Chunks are 16 blocks across, you need to do as Diesieben said and run 2 for-loops, from each counting from -8 to 8 (inclusive (128 blocks radius)). Then you add the first loops value to either chunk values, and the other loop-values to the other. Now you got all chunks in this 256^3 area. Stuff these different ChunkPos coordinates you just calculated in a collection, and loop throughChunk::getTileEntityMap as described again by Diesieben.

Wrong init. The one in your main/common proxy that gets the FMLInitializationEvent

init-phase event-handlers need to be annotated with @EventHandler alt @Mod.EventBusSubscriber if outside your main class