V0idWa1k3r

Okay, looking further into the slab issue:

Your blocks return the content of drop field when the getItemDropped is called. That field is assigned in a constructor. Your blocks are created in createBlocks method, and items are created in createItems method, respectively. Those methods are called in your... proxy for some reason like this: ModBlocks.createBlocks(); ModItems.createItems(); So every time your block is constructed it gets a reference of item that has not yet been initialized and thereforeafter is null. So your ores always return null when it comes to their drops(apart from that one that drops vanilla clay). Just determine the drop item right in that method, on the fly. Or assign that field later, when the item is not null. Blocks/items should not even be constructed by you like that. They should either be constructed straight in the field initializer or provided by forge's registred-objects-to-fields-injection(if that is available for you).

Well, 0 will pretty much disable the fog - and that is what you are seeing to be fair. I am not sure what causes the sky color issue, it might be something else as I do not experience it with your code.

I do not experience any issues with your implementation. What is ? It is supposed to be a float of [0-1] range (0 - no fog, 1 - pretty much only fog is visible, you can barely see the world)

Post your new code

If it is storing them as int values do not forget to cast them to floats/doubles before you divide by them otherwise java will perform an int/int division that has no decimal part and will get auto-rounded to 0(or 1, if the variable is 255)

cancaled? That would not even compile. You do not need to cancel FogColors event. Only FogDensity. What is Constants.fogColor ? Why are you dividing 255 by it's variables? rgb are float ranges[0-1], and unless Constants.fogColor contains floats/doubles that are greater than 255 it is not going to work and is going to set the color to either white(if they are less than 255) or black(if getRed/green/blue returns not a float/double and is greater than 255)

FogDensity/FogColors events work just fine for me. How exactly have you tried using them?

You DO have an instance of BlockDoor at net.minecraft.init.Blocks, You in fact have 6 of them there. Blocks are singletons. But that will obviously only work with vanilla doors and only if you hard-code them. If you want your method to work with any door that uses an inplementation of ItemDoor to be placed you would need to use reflection to access the block field of ItemDoor

Unfortunately that's the way it is. You can't reliably prohibit your item from going into the offhand slot(apart from ugly sollutions like dropping them if they are in that slot) so you have to handle it somehow. Unless all your items have their item-unique custom transform creating correct transforms for the offhand is just going to be figuring it out for one item and copy-pasting it to others. Even if each item is unique there has to be some kind of pattern for their transformation you can use. In any case you should do this. Imagine a mod adding a mannequin. That mannequin is it's own entity with it's own slots. It indeed can have items in the offhand slot. A user puts your item in there and... yeah. You know what is even worse? The name of that mod is Minecraft and the name of that item is Armor stand.

Item::isValidArmor is only fired for armor, hence the name. I do not see a not-ugly/hacky way to make the item invalid for offhand slot - it is initialized as a regular Slot without additional checks and swap hotkey has no hooks at all. Even if you cancel the keybind and handle the slot click some mods that have that slot in their own container will allow the item to go in regardless as you can't reliably handle that. Why are you trying to prohibit the use of the offhand slot fot your item to begin with? There is nothing special about that slot unless you explicitly handle your item being in that exact slot. Most methods that do something with the item do have an EnumHand parameter that will allow you to check if the item is not in that slot.

Here is a tutorial. It is a bit outdated but should work for the most part. Apart from that forge itself contains an example. Or you can see the example for JEI - mod, factory and gui

You need to register an IItemColor implementation using ItemColors::registerItemColorHandler. You can obtain an instance of ItemColors with Minecraft::getItemColors

I am afraid those are hard-coded at Entity::doWaterSplashEffect thus there is not much that can be done.

Define 'custom dimensions'. If you just want to scale your model use GlStateManager::scale. If you want the rendered block to be 3d - it already is, guis just disable lighting when rendering items so it looks flat. You can render a block/item model using RenderItem::renderItem. Use the overloaded method that suits your needs.

Just render your fluid texture using Tessellator in your event handler, then cancel the event. You can do this the same way vanilla does it in ItemRenderer::renderWaterOverlayTexture, just bind your overlay texture instead of the water one

I think I might have found what you are looking for. RenderBlockOverlayEvent is a cancelable event that renders a texture of a block the player is currently in. It also catches water overlay if the player is in water and fire overlay when player is on fire.

Well, I've tried to replicate your issue but even with something as ridiculous as this I couldn't get my game to crash. Granted, I've used a more recent version of forge for 1.8.9... Anyway, you could try and check if the chunk you are generating in exists, and the chunks that are triggered by your offsets exist before firing any generation. (IChunkProvider::chunkExists). Do not forget that that method takes chunk coordinates as it's arguments, not block coordinates

Well, in your BlockTestBlock you are canceling the action if world.isRemote check fails. So you are opening only your guicontainer, without actually opening the container itself. Apart from that I do not see anything obviously wrong

When you are generating one of four 'slants' that slant might be generating in an existing chunk. As you add more your placeBlock method attempts to place a block in a chunk that has not been generated yet thus causing an issue. It is visible if you inspect the stacktrace : Note how it goes from your placeBlock method to a world, then ChunkProviderServer, then ChunkProviderGenerate, then BiomeGenBase. You are trigerring a new chunk generation.

I am not sure about 1.10.x but 1.11 has Block::getMapColor that you can override to have custom map colors that are material-independent. The overlay can be rendered in any of RenderGameOverlayEvent's subevents however you please. Yet again, unsure about 1.10 but 1.11 has a Block::isEntityInsideMaterial (and Block::isAABBInsideMaterial) method to check if the specified entity is in specified material. Apart from that it seems that Forge checks if an entity is inside of fluid by checking the fluid fill level and it will check the level if a block is an instance of either IFluidBlock or BlockLiquid. Motion can be handled in Block::modifyAcceleration. fire/damage you will have to implement in Block::onEntityCollidedWithBlock as @Choonster said. Unfortuately apart from that a lot of things are hardcoded to work with Material.WATER/LAVA and you will either have to find a workaround with forge's events or just accept that it is not currently possible (if you really need something you could make a PR though).

You are most likely trying to generate your tree in a chunk that has not been generated yet, triggering recursion. As far as I remember the 'already decorating' exception is thrown to prevent that. How and where are you calling your generate method?

Yes, you are on the right track. In fact, you have mostly described how to do it already You can check for creative mod in EntityPlayer.capabilities field. There are all kinds of fields in there - isFlying, isCreativeMode and others. Just do not forget that ClientTickEvent is fired every client tick, including ticks where the player does not exist yes(ex. main menu screen) so you will need to check for that (player != null).

If it is a custom inventory then it depends on the particular implementation - it could be stored in an itemstack's nbt data if the inventory is bound to that itemstack or if it is something rather complex a custom packet might be required. Could you explain what exactly are you trying to do?

Create a class that implemets IWorldGenerator. the generate method is the one that will get called each time a new chunk is generated. The parameter names in that method have pretty self-explanatory names so you should understand what each of them means. When you are done wrighting generation code in the generate method register an instance of the class you've just made with GameRegistry::registerWorldGenerator(yourGeneratorClassInstance, weight) where weight determines the order your generator is executed relative to other mods generators. The bigger the number the later your generation will be executed. This is an example I found in ~5 minutes.