Choonster

BlockEvent.BreakEvent.

If you look at GuiNewChat#drawChat (which renders the recent chat messages), you'll see that it renders each line by calling ITextComponent#getFormattedText to get the text with formatting codes and then FontRenderer#drawStringWithShadow to render the text. FontRenderer is responsible for interpreting the formatting codes and rendering each character with the appropriate colour and style. The vanilla FontRenderer only supports the colours and styles of the TextFormatting enum, you'd need to implement custom colours yourself.

Forge's documentation has a page on events here.

The method is only called on the Item that the player is holding. This is a general principle in Minecraft: methods of classes like Item and Block are only called on the object involved in the interaction (e.g. breaking a block calls a method on the Block that was broken and the Item being held by the player that broke it). To change the behaviour of Blocks and Items added by Minecraft and other mods, you need to use events.

You can set the acceptedMinecraftVersions property of your @Mod annotation to change which versions of Minecraft are allowed to run your mod. If your mod isn't actually compatible with a Minecraft version, it will likely crash at runtime when it encounters an incompatibility. Look at VersionRange.createFromVersionSpec for brief documentation of the version range format. Look at FMLModContainer#bindMetadata to see how FML replaces some specific version ranges with others (where multiple versions are compatible with each other).

Item#onBlockDestroyed is called when a player destroys a block while holding an ItemStack of the Item in their main hand (regardless of what that Item is). The ItemStack argument is the ItemStack in the player's main hand. It's not called in creative mode.

Use World#setBlockState to replace the IBlockState at the specified BlockPos with another. Use World#setBlockToAir to replace the IBlockState at the specified BlockPos with air (this just calls World#setBlockState). Use Block#getDefaultState to get the default IBlockState of a Block and IBlockState#withProperty to get an IBlockState with the IProperty set to the specified value. Forge has an introduction to block states here. You can call World#sendBlockBreakProgress to render the block breaking cracks on a block. If called from the logical client, it will update the break progress for that position. If called from the logical server, it will send a packet to all players within 32 blocks of the position (except the one whose entity ID was passed as the first argument) that calls the same method on their client.

A NullPointerException means you tried to call a method on or access a field of a null value. The only value on that line that can be null is the attachedEntity field. You need to check that it's not null before you try to call INBTSerializable#serializeNBT on it. This is basic Java knowledge.

You're not storing the facing in the metadata in getMetaFromState and you're treating the raw metadata value as both the facing and the variant in getStateFromMeta, which won't work. In getMetaFromState, you need to combine the facing and variant into a single metadata value using bitwise operators and then return it. In getStateFromMeta, you need to extract the facing and variant from the metadata using bitwise operators and then return the IBlockState with these values set. If your block can't have vertical facings, use EnumFacing.getHorizontal instead of EnumFacing.getFront to get the EnumFacing from its index. Use EnumFacing#getHorizontalIndex to get the horizontal index of an EnumFacing. Keep in mind that metadata is limited to 4 bits (16 possible values). If you have 4 possible facings (north, south, east, west), that only leaves room for 4 possible variants (because 4 * 4 = 16). Look at BlockAnvil for an example of a Block with two properties (facing and damage).

In addition to ItemStack#setCount, you can also use ItemStack#grow and ItemStack#shrink.

Post the FML log (logs/fml-client-latest.log in your Minecraft directory) in a spoiler (the eye icon in the editor). The two lines you've posted tell us almost nothing about what went wrong.

Not really, I don't know much about it myself. I've seen people recommend VisualVM for this sort of thing, you may also be able to use Minecraft's Profiler class. If you enable profiling in Minecraft (/debug start), you may be able to add a shutdown hook (Runtime#addShutdownHook) that saves the profiling output to a file (e.g. by running /debug stop). This would allow you to see what took so long after the server is stopped by the watchdog.

There's a list of tutorials here. Some of them have been updated to 1.11.x, some of them are only on 1.9.x/1.10.x but the versions are fairly similar.

Then the issue is probably with another one of your mods. Try removing all of the Malisis mods, I seem to remember them messing with Forge's internals at some point. If that doesn't fix it, post the complete FML log (logs/fml-client-latest.log); it may contain some useful information about the issue. If it doesn't, you'll need to remove mods until the issue no longer occurs.

You posted this in the wrong section, but it should be moved by a moderator soon. Does this occur without OptiFine? Does this occur if you revert to Forge 1.11.2-13.20.0.2227 (the Forge version supported by OptiFine 1.11.2_HD_U_B7)?

This is a crash induced by ServerHangWatchdog because a tick took longer than the maximum tick time (1 minute by default). You'll probably have to do some profiling to figure out what's taking so long.

You can't compare ItemStacks using Object#equals, you need to use one of the static equality methods in the ItemStack class. You shouldn't be creating a new ItemStack at all, though. You need to get the ItemStack key from the Iterator and check its Item, metadata and NBT as appropriate to determine whether it should be removed. Iterator<E> is a generic type, don't use it (or any other generic type) without specifying its type argument.

Calling Map#remove with a new ItemStack on a Map with ItemStack keys won't do anything. ItemStack doesn't override Object#equals or Object#hashCode, so two ItemStacks are only considered to be the same key if they're the same object. Map#remove will only work here if you call it with an ItemStack object that's already a key in the Map.

It should probably be fired just before the second if statement in WorldEntitySpawner.canCreatureTypeSpawnAtLocation. The event should include the EntityLiving.SpawnPlacementType, World, BlockPos and IBlockState and have an Event.Result that controls the behaviour (like LivingSpawnEvent.CheckSpawn). An alternative would be to add a method to EntityLiving.SpawnPlacementType that takes the World, BlockPos and IBlockState and returns a nullable Boolean or Optional<Boolean> functioning similar to Event.Result (allow, deny, default). You'd then need to add a field to EntityLiving.SpawnPlacementType to hold a delegate function for the method to call (like EnumEnchantmentType#canEnchantItem/EnumEnchantmentType#delegate). A Function<Triple<World, BlockPos, IBlockState>> would work, though it's a bit ugly.

It was renamed to net.minecraft.util.text.translation.I18n and deprecated, because the server shouldn't be translating things (the dedicated server can only translate to en_US). Use net.minecraft.client.resources.I18n from the client instead (or send a TextComponentTranslation, which will translate to the client's locale). This hasn't changed. Override Block#hasTileEntity(IBlockState) to return true for any state that has a TileEntity and override Block#createTileEntity to create an return an instance of the TileEntity for the provided state. Which methods do you want to know about? Try looking at the TileEntity class or vanilla extensions of it. MCPBot can tell you the SRG name of a field/method in a specific version and also tell you the current MCP name of an SRG name. This issue tracker documents most renamed field/methods. Again, look at vanilla examples like BlockCactus or BlockBasePressurePlate. Store the block's bounding boxes as AABB fields. Override Block#getBoundingBox to return your Block's main bounding box, Block#getCollisionBoundingBox to return your Block's collision bounding box (if it's different to the main bounding box) and Block#getSelectedBoundingBox to return your Block's selection bounding box offset by the BlockPos (if it's different to the main bounding box). If your Block has multiple collision bounding boxes, override Block#addCollisionBoxToList (the instance method) to call Block.addCollisionBoxToList (the static method) for each bounding box. Entity#getRidingEntity returns the entity being ridden by this. Entity#getPassengers returns the entities riding this.

Create a new instance of your IWorldEventListener for each World and store the World in a field. ServerWorldEventHandler and RenderGlobal both do this.

Which clients need which data and when? If a client always needs to know a particular value (e.g to render it on a HUD), send a packet to any relevant players when they log in and when the value changes. If a client only needs to know the value in a GUI, you can probably sync it through the Container (either using the built-in syncing packets or your own). If a bank account is only ever linked to one player, consider storing a player's bank account(s) in a player Capability instead of using World Saved Data.

Are there any errors in the log?

Your WorldSavedData class must have a constructor that takes a single String argument.

You're using the blocks Field twice and casting the value of the second call to List<Template.EntityInfo> instead of using the entities Field. This will throw a ClassCastException at runtime. It also looks like you're not actually using the size Field. I recommend following Java naming conventions by using CONSTANT_CASE for constant fields.