Draco18s

Other way around. TagList = List TagCompound = Map

https://academo.org/demos/rotation-about-point/

Of course it's not. For the same reason Blocks.PINK_WOOL isn't defined: it's a metadata state variant of the dirt block. You need to also read/supply a metadata value or IBlockState definition.

@Choonster Can we get your eyes on this? You seem to be more adept than anyone in finding issues with item model problems.

https://github.com/MinecraftForge/MinecraftForge/issues/3419#issuecomment-308583108

No, I mean I don't see any errors being logged.

http://export.mcpbot.bspk.rs/

This is because entities have a hurt resistance time: when they are flashing red they cannot take additional damage. You need to reset the hurt resistance time yourself to 0 when your shotgun bullets impact, allowing all of them to deal full damage. I did this once back in 1.7: https://github.com/Draco18s/Artifacts/blob/master/main/java/com/draco18s/artifacts/entity/EntitySpecialArrow.java#L184

Yep. Huh, I don't see anything in there.

They're called automatically by vanilla when needed. If you need them to be run you have to tell vanilla that your block is dirty and needs an update: https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/farming/entities/TileEntityTanner.java#L95-L98

Not related to your problem, but: https://github.com/KombatKitten/Collision/blob/Forums-Question/src/main/java/com/github/KombatKitten/dimensionalMagic/CommonProxy.java#L43-L44 You shouldn't do this. You should set the unlocalized name to the registry name so that your mod ID appears in the unlocalized name (this avoids conflicts with two mods naming their item the same thing). Post your log file.

Couple things: 1) Your overlay texture is #overlay, you didn't specify a resource location (this is likely the problem). 2) You haven't specified any UV coordinates. You probably don't need them, but it's good form to have them.

Yes.

You can't. The "elements" tag is specifically a replacement. Actually all named tags are replacements. Its just that in some cases (like the "display" tag on items*) that things aren't replaced, and it has to do with how the files are deserialized. You MUST add all 6 sides to your model twice, each with a different texture. There is no way around this. *This reason this is true is because "display" is an object. Each subtag present replaces the parent's original. "elements" is a list and there's no way to know that the element list you've supplied should add or replace the parent's list, so the default action is replace (if the default was add there would be no ability to replace).

No, you overwrote block/cube_all's elements. You didn't add, you replaced.

Add more elements with a different texture reference.

Which if you're using the registry events for your blocks and items, that is guaranteed to run before json recipes are loaded.

Actually, no. You create your own bed, register it normally, but, you make its registry name "minecraft:bed" Forge takes care of the rest.

Bad tutorials is a thing we do our best to fight against, letting their authors know about the problems so they can be fixed. No worries if you can't find them again, it just would have been helpful.

It's private. Please link any 1.12 tutorials that are still doing it that way so that we can inform them that they're either doing it wrong or falsely claiming to be a 1.12 tutorial. The new way feels oddly roundabout to me, but there are certain advantages to it (namely that the game can do a full rebuild of blocks and items while the game is running, should it need to). Essentially you need to subscribe to the RegistryEvent.Register<T> events (and you'll put the type of object you want to register where the T is, e.g. RegistryEvent.Register<Block>) and call event.getRegistry().register(...) on all of your things. Note that you will have to register item forms of your blocks yourself if you want your blocks to exist as items (i.e. pickup-able). You will also need to subscribe to the ModelRegistryEvent in order to register item models (though you still call ModelLoader.setCustomModelResourceLocation(...)) If you would like, I have set up two classes that I call my Easy Registry. It is essentially a wrapper around these things the way GameRegistry used to wrap around vanilla and forge internals. https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/hardlib/EasyRegistry.java https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/hardlib/client/ClientEasyRegistry.java Note that the EasyRegistry classes are effectively both event handler (for the aforementioned events) and the proxy classes for my library: https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/hardlib/HardLib.java#L44 You do not need to clone all of HardLib to make this work, you can re-point the references to your own library or main mod class, although there are some helpful interfaces you might want (that handle things like custom IStateMappers and so on). Usage is very simple and easy. It is also advised that you use @ObjectHolder annotations on your block/item fields (which I am not currently doing) in order to allow other mods to override your own (the "Substitution Alias" system wrought 1.12), see Lex's comments here:

You should always register your items and use configs to make them craftable or not.

You are essentially correct on all points. Have you overridden these three methods? One of them is explicitly for the purpose of telling the client what the nbt data was when the TE was loaded from disk.

Please explain further. I'm using it in my own code and it works fine.

Usually it means "will be removed soon" but Mojang has marked it as deprecated because everything should call the same methods in IBlockState instead (this is the "moved" part of things: the method calls need to point to the new thing). Whether or not they will be removed from the Block class entirely is unclear (and if they are, how would the behaviors be handled?).