Matryoshika

Mobs spawned by the world & mobs spawned by spawners eventually pass through LivingSpawnEvent#checkSpawn before actually getting spawned. And yes, all children of LivingSpawnEvent will be given to you unless a specific one is stated. Btw, your whole "create a fake-player just to get the server" is quite redundant. Just call World::getMinecraftServer and be done with it. Creating FakePlayers is dangerous if you don't also make sure to remove them when the world needs to unload, or it's not gonna get unloaded, because the "player" is still in there.

Key parts are : ICustomModelLoader -> Provide a dummy IModel here pointing to your actual IBakedModel. IExtendedBlockState -> Override Block::getExtendedState & Block::createBlockState to provide IUnlistedProperties. These are used to provide data to the IBakedModel through the IBlockState List<BakedQuad> -> This is the model boiled down. IBakedModel::getQuads is where you'll be doing your logic, per block-face. Be sure to as said cache your models, aka put the List<BakedQuad> somewhere. Always check if you have the wanted model, and only if you do not, should you make one from scratch. This is the optimization over TESR's. I am doing this in my project Echo (for 1.10.2, but procedure should be the same for 1.12.2) to allow any block (well, full blocks) to be compressed into Menger-fractals. ModelLoader, IBakedModel, Block

Other way round; a TESR is more rigid than custom IBakedModel handling. Might not be nearly as easy, but custom IBakedModel handling can do everything a TESR can, and if done correctly, using only mere fractions of the resources that a TESR would have taken. And it depends on how you're gonna store the models. If you cache them as they are rendered (aka lazy caching) then the memory foot-print will be much smaller. The client(s) will only know about the models that actually need to be rendered.

It's not just "recommended". There are multiple issues just these last weeks where people are registering though ForgeRegistries. As per the JavaDoc for ForgeRegistries "..but queries and iterations can use this". Why should one use the RegistryEvents when you can be lazy and register objects like this? Well, registration has to happen during a specific interval in Minecraft's life-cycle, which the RegistryEvents were made specifically for, or you may end up with "The object [name] is being added too late" because Forge has called ForgeRegistry::freeze because whoops, time's up, and you shouldn't be messing with this stuff now.

Never use any Client-Side only code (Minecraft::player etc) unless you are working with Client-Side only code. The method execute already provides the player, abstracted into the ICommandSender. Use ICommandSender::getCommandSenderEntity to get the Entity back. Cast it to EntityPlayer if applicable, and voila, you're done.

You can use Capabilities, or NBT-data, you just need to use packets to get it. How are you setting this value to begin with? If nothing else, you could use a simple client-side config to store it.

Registering blocks & Items using the Register<IForgeRegistry> events Registering models during the ModelRegistryEvent oh, I missed one thing earlier. You never in any way connect the BlockState JSON to the model JSON. You're just stating "use this texture". Inside the variant "normal" [{}] in your BlockState, add a "model": "modid:name". Example: "normal": [{ "model": "underworld:blockbrazier" }} (It seems like you're in-between different formats. One that declares everything inside the BlockState JSON (which doesn't need any models) and one that makes use of a ready model JSON. I took the liberty of directing you to make full use of the second option, as you already had a JSON for that.)

Problematic Code #1 Do not register your blocks/items by calling IForgeRegistry::register. Instead of creating your ModelResourceLocation as modid+":"+id, just call Item::getRegistryName. It has already been formatted to "modid:id" for you "behind the curtains" Please also add the fml-client-latest.log found in <modding-directory>/run/logs. Paste the contents to pastebin.com or as a github Gist. Please do not upload the file directly here, or copy/paste the contents as a post.

Should have told you enough. If you're still paranoid about sides, launch server, launch client, connect with "localhost" and test. If you crash, then no.

if your PropertyEnum is the only property on your Block, use Enum::ordinal as your meta. You will need to override Block::getStateFromMeta & Block::getMetaFromState, if you haven't already, of course.

A simple glace through your IDE should have shown you that the World::rayTraceBlocks (there's three of 'em) are not annotated with any SideOnly. The reason EntityPlayer::rayTrace is Client-Side only, is because that is only where it is used. Way back (in 1.3?) when Minecraft split the Server & Client logic, it was determined that the server only needs that which it uses. Anything that could have been common, but was only used Client-Side, was forced to become Client-Side only, during this split.

ASM/Core editing is not supported by Forge. A Moderator will likely lock this thread unless you change to a more viable solution.

It looks like you want the shortest distance between the player, and this entity, yes? Call Entity::getDistanceToEntity, to find the distance between two entities.

I was under the idea that you were coding post Minecraft 1.7, due to your use of "net.minecraftforge ", but the evidence of "cpw.mods.fml" states that this is 1.7 or lower. 1.7 is not supported in this forum. Please update, before a moderator locks the thread. @Differentiation He does not need proxies when he's merely using events that happen on both sides aka COMMON. I also told him to use static, so that he could annotate his class with @Mod.EventBusSubscriber instead of having to manually register it. Please do not barge in stating things are wrong when they are not.

You are comparing the items correctly now, yes. However, you should be getting the ItemStack from the event itself, not from the player. (Go back to ItemStack stack = event.getItem()) And on another note, I am now seeing what I missed before. Your method takes in two arguments (the Event & Item). This code will never be called because you have more than one arguments. Forge's EventHandler (which is the thing that goes "HEY, this happened, do your stuff") can only see static methods that need one argument, and that has to be some type of Event. TL;DR remove the Item itemStack at the top, and put "static" after the "public", before the "void".

Difficult? How am I making this difficult? I've told you how to get the item I have told you how to cancel the event. Now you take one, and stick it to the other, and you're done.

No. Why won't I? Because this forum is meant to help people with their own code. If I write the code for you, you won't know what the heck it does, why it does it, when it does it, nor how it does it. If you have any issues, you would have no idea how to solve them, and would need further help. You were pretty close last time around, just had to actually compare an item against an item.

"event" is given to you by the EventHandler, because your method "PlayerUseItemEvent" requires a Start Event (which here is a sub-class of the actual PlayerUseItemEvent) (Your method shouldn't have the same name as the event, as it can get confusing). This "event" will always be of the type PlayerUseItemEvent, specifically before the item is used. (As indicated of the sub-type Start). As such, you do not have to worry about "which" event, because this will only work for the event that you have. For the future, you should also look up what Static and Non-Static classes, methods and fields means. This is as said basic Java knowledge, which is sorely needed, but not taught here.

event.item returns an ItemStack. event.item.getItem() returns an actual Item. This is basic Java...

"getItem" is a non-static method, in the ItemStack class. You need to call it on an ItemStack. As it is right now, your code will not even compile, and your IDE should tell you as much.

ItemStack is not an item. You are still trying to compare them, which will always return false. You get an ItemStack from the event. You then need to get the item out of the ItemStack. You then compare the item, to string.

You are comparing an ItemStack(that contains an item) to an item. You need to use ItemStack::getItem, and then compare it. ItemStack::useItemRightClick does not do what you think it does, by the way. It is normally called when an item is rightclicked, and replaces the current ItemStack to a new one (normally the same itemstack, perhaps +-1 stack-count depending on what the item actually does). If you want to block the player from actually using the item, call Event::setCanceled(true).

Call EnchantmentHelper#getEnchantments(ItemStack). This will return a Map<Enchantment, Integer>. If Map::get(Enchantment) returns null, the enchantment is not present on the itemstack.

What are you trying to do? Neither hurting an entity, nor protecting from damage can be done client-side, as that is done server-side. It would not make sense if the client could overrule and go "nu-uh, that missed", or "I'm gonna attack you with 1 MILLION DAMAGE"

You need to iterate over all biomes that you want to change the temperature for, and change the value of the temperature field. Due note, it is both private, and final, which means you will need to use Reflection to both access it, and change it.