Choonster

I have an example of something similar here, here and here. I use a World capability (IChunkEnergyHolder) to store a Map containing the IChunkEnergy (which stores a single integer) for each chunk of the World. I use ChunkDataEvent.Load to read the IChunkEnergy from the chunk's NBT and store it in the Map, ChunkEvent.Load to create a default IChunkEnergy for the chunk if it doesn't have one and store it in the Map, ChunkDataEvent.Save to save the IChunkEnergy to the chunk's NBT and ChunkEvent.Unload to remove the IChunkEnergy from the Map. The capability doesn't actually save any data itself, it only exists to hold the Map at runtime. I use ChunkWatchEvent.Watch to send the IChunkEnergy to the client when a player starts watching a chunk. Whenever an IChunkEnergy's stored value changes, it's sent to all players watching the chunk.

I don't think this is currently possible using the vanilla passive spawning system. When WorldEntitySpawner#findChunksForSpawning tries to spawn an entity, it calls WorldServer#canCreatureTypeSpawnHere and WorldEntitySpawner#canCreatureTypeSpawnAtLocation and only proceeds if they both return true. You can use WorldEvent.PotentialSpawns to change the result of the former, but the latter is hardcoded to check for water if the entity uses EntityLiving.SpawnPlacementType.IN_WATER and call Block#canCreatureSpawn (which calls (Block#isSideSolid with EnumFacing.UP) for any other EntityLiving.SpawnPlacementType. Lava isn't water or a solid block, so entities won't be spawned in it. I think Forge would need to add an event in WorldEntitySpawner#canCreatureTypeSpawnAtLocation to allow the result of the method to be changed.

I suspect you're running into the discrepancy between EntityPlayerMP#getPosition and EntityPlayerSP#getPosition. The former adds 0.5 to the y coordinate and uses the x and z coordinates as-is, but the latter adds 0.5 to every coordinate. I don't really know why Mojang chose to do this. You'll likely want to use the BlockPos(Entity) constructor instead, this won't add any offsets to the entity's coordinates.

Mod fluid Blocks implement IFluidBlock. If it's only working on one side, you're likely doing something wrong. Post your code.

OkHttp depends on Okio, which you don't have.

What do you mean by "crush"? Is the client crashing? Is it freezing? Post the code where you use the client. If it's crashing, post the crash report as well.

That difference is what prevents it from being an override method. As this tutorial explains, override methods must have the same return type, number and type of parameters as the super method. You can return a subtype of the super method's return type, but the parameter types must be exactly the same.

This isn't specific to Minecraft or Forge, this is basic Java knowledge which you should already have before starting to make a mod.

Your method doesn't override any method from a parent class (it has the wrong argument types to override Block#onEntityCollidedWithBlock), so it's never called. If you'd annotated it with @Override, your IDE or the compiler would have told you this. I recommend using your IDE to auto-generate override methods with the correct signature and annotations. When updating a new version of Minecraft, I auto-generate override methods for any methods I was previously overriding that have changed signature and then move the body of the previous method into the new one. Side note: DamageSource instances should be treated as singletons (i.e. created once and then stored somewhere) unless there's additional data that changes each time the damage is done (e.g. the entities of EntityDamageSource/EntityDamageSourceIndirect).

CraftingManager#addRecipe(ItemStack, Object...) converts Block ingredients to ItemStacks with OreDictionary.WILDCARD_VALUE as the metadata value, but CraftingManager#addShapelessRecipe converts Block ingredients to ItemStacks with 0 as the metadata value. The ore recipe constructors do the same: ShapedOreRecipe uses OreDictionary.WILDCARD_VALUE, ShapelessOreRecipe uses 0.

I haven't used the new launcher yet, but I'd guess you already had a profile called "forge" and the installer didn't overwrite it. What you need to do is create a new profile and select the appropriate Forge version from the versions list.

Which version of Forge did you download? What makes you think it's for 1.10.2? Can you post the URL you downloaded it from?

The super method is the method with the same signature (name and parameters) in the super class (the one overridden by the current method).

It was added in Forge 1.10.2-12.18.2.2107, make sure you're using either the Recommended or Latest version of Forge. The line that calls GlStateManager.scale. Only use the Grill instance stored in your TESR (the grill field) if the Grill argument (te) is null (i.e. it's being rendered in the inventory rather than the world).

Look at BlockSkull or BlockBanner. You can see an example of a TileEntity's IFluidHandler being saved to an ItemStack's IFluidHandlerItem here.

Did you try searching the Block class for "hardness" or "resistance"? If you did, you probably would have found Block#getBlockHardness and Block#getExplosionResistance(Entity)/Block#getExplosionResistance(World, BlockPos, Entity, Explosion). Block#getHardness shouldn't be called directly, you should call IBlockProperties#getBlockHardness instead (IBlockState extends IBlockProperties).

You need to save the TileEntity's data to the ItemStack's NBT (or capabilities). You can do this by overriding Block#getDrops to create an ItemStack with the appropriate data and then return a List<ItemStack> containing it. By default, the TileEntity is removed from the world before Block#getDrops is called. You need to delay this like Forge's patch to BlockFlowerPot does.

If it's crashing, post the code and the crash report/FML log. Override Block#getStateForPlacement(World, BlockPos, EnumFacing, float, float, float, int, EntityLivingBase, ItemStack) to do the following: Call the super method to get the state from the metadata Call IBlockState#withProperty on the IBlockState returned by the super method to get an IBlockState with the facing property set based on the placer argument Return the IBlockState Use Entity#getHorizontalFacing to get the horizontal EnumFacing of an Entity and EnumFacing#getOpposite to get its opposite. I believe it's GlStateManager.scale.

The TileEntity passed to TileEntitySpecialRenderer#renderTileEntityAt will be null when it's rendered in the inventory. You need to store an instance of the TileEntity in your TESR to use when it's rendered in the inventory.

Use the Simple Network Wrapper.

Indeed, I didn't realise that you don't have access to the player in a @NetworkCheckHandler method. I think you'll need to send a packet from the client to the server when they connect to tell the server that the player has your mod installed.

Indeed, I completely forgot about Set for a moment there.

It wouldn't hurt.

Unfortunately not, it just confirms what we already knew: something happens right after loading the Mekanism coremod to crash the game without printing anything to the log.