V0idWa1k3r

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.

Just move model registering to a client proxy. A replacement for ItemModelMesher is ModelLoader. The model file for the ruby block is indeed correct. It is not correct for the ore block.

That is not a material but a model issue. Make sure that your model is correct - you can follow this guide Okay, looking at your sourcecode: Please, never use ItemModelMesher. It leads to numerous bugs and issues. There is a ModelLoader class for registering your models. You should move everything rendering registry related into your client proxy. Models for blocks/items must be registered during pre-init, not init. Your blocks/items should be statically initialized. There is no need to call the init method. Simply write public static final Block rubyblock = new BlockRuby(); I believe that your blockstates file is not correct. I have provided a link to a tutorial on how to make those. Your model JSON file is invalid. It is missing an opening bracket

Define 'material not working'. Is the mining tool incorrect? The map color? Piston movement? There are a few things that materials control. In addition to @Ugdhar's answer - do not forget to register your IWorldGenerator implementation with GameRegistry::registerWorldGenerator

Drawing must happen each frame, as at the beginning of each frame the screen gets cleared of anything that is drawn on it. Create a variable to hold if the player clicked the mouse or not and draw your rectangle in the drawScreen method if that variable is true/hold whatever value you need it to. If you want something to be drawn 'after draw screen' just put your drawing calls after the super.drawScreen

I have answered you in that other thread, and you could have asked this question there too. Anyways, wool and other colored blocks all have the same behaviour that is defined at net.minecraft.block.BlockColored

One class, one Item instance, different metadata/blockstates

Enums have an ordinal() method that returns their... ordinal. It is a number. Data parameters work with numbers just fine. As far as your other question goes as I've said, look how it is done in vanilla. Basically you want to change your attributes whenever the 'growth stage' is changed/loaded from nbt

I do not see any obvious issues with it(although I have never worked with 1.10.x so I might be missing something) apart from calling Minecraft from common code. How do you know it is not working? What happens if you place a breakpoint inside the neighborChanged method?

Depends on what you are trying to do. If it is a custom item you can just use ItemColors::registerItemColorHandler. See how vanilla does it with leather armor, for example.

What behaviour are you expecting and what are you getting? EntityLivingBase::applyEntityAttributes is only fired in entity's constructor. You know, before any of your data is loaded from NBT/initialized. If you want to have varying attributes based on some data you should look how vanilla does it. An example exists in EntitySlime. And maybe you would like to use enums instead of strings for your 'growth stage' checks. You only have a constant amount of growth stages and using strings is a bit of an overkill and a waste of memory.

will not fire for the block if it is not set to tick randomly. (Block::setTickRandomly(boolean)) should work just fine for block updates nearby. However as you have not specified the game version you are modding for I will assume it is 1.11.x and if it indeed is 1.11.x then your signature is incorrect. It is neighborChanged(IBlockState state, World worldIn, BlockPos pos, Block blockIn, BlockPos fromPos) and yours is neighborChanged(IBlockState state, World worldIn, BlockPos pos, Block blockIn) While you do have an override annotation and the compiler would tell you that there is nothing to override normally you are extending BaseBlock which is your imlementation you have not posted code for, and that can contain that method without an override annotation. As far as I am able to tell Block::onNeighborChange only has something to do with comparator logic and not block updates. Oh, and also not relevant to your issue but I fail to see what is the purpose of If you are setting the hardness literally 1 line below.

EventHandler is for mod lyfecycle events - init/pre-init/post-init, etc. You need to work with event bus events. Here is how to do it

That is hardcoded in the way entities move. Basically while the player holds a movement button their motion gets set to a specific amount. As the button is released the motion gradually decreases by something like motionX *= 0.9 in the onUpdate method. You can however easily disable the 'drift' effect as you call it. Create an eventhandler that will handle client player's tick(or a client tick), check if the player is in creative and is flying, check that none of movement keys are pressed (you can get them in GameSettings which you can obtain from a Minecraft instance), and if all conditions are met simply set motionX and motionZ to 0.

I have misunderstood your initial question a bit. I have edited my reply to adress that:

Well, if something changes as the block nearby gets updated it does not mean that there is an issue with writeToNBT, it means that if you are using extended block state to render changes made to the block you need to call World::markBlockRangeForRenderUpdate to re-render it in the world in your packet as it is handled on the client

FYI: you do not need to do that. That method only creates the packet, it does not actually send it or do anything with it. So your NetUtils and MessageHandler simply create a new packet object and immidiately discard it as you are not doing anyhing with it. Also your getUpdatePacket implementation in your tile does a lot of redundant work. It sets the values of the sides and then calls writeToNBT which does the same. Well, at least it is doing that in the code you have posted, but you might have changed it already.

You have either posted incomplete sounds.json or it is invalid as it is missing } at the end. Also I am pretty sure that last time I checked mc printed sound-related warnings and errors into console if something was wrong with the soundevent(sound can't be found/registered, invalid json, invalid ogg file, etc) so you should scan your log for any sound-related errors.

Okay, so a couple of things I would like to explain: 1. Difference between TileEntity::getUpdateTag and TileEntity::getUpdatePacket. They are build around the same purpose and cause a lot of confusion, but they are slightly different. getUpdateTag is appended to the ChunkData packet(the one player recieves from a server when loading a chunk/chunk data is changed). getUpdatePacket is sent in 2 circumstances: If a BlockState changes and the new one has a TileEntity(world::setBlockState is mostly the cause here) or if the amount of changes in the chunk is greater than 1 and less than 64(so a couple of blocks got thanged). Then the getUpdatePacket is sent for each changed blockstate with tile entity. So you do need to override both in your tileentity. Override only getUpdatePacket - and the client will not recieve the data when the chunk is loaded or multiple blocks are changed at the same time. Override only getUpdateTag - and the clients will not see the changes upon blockstate changes. 2. Please use breakpoints to debug. They are so much nicer and handy, you have no idea. Writing stuff to output is messy, time-consuming and leads to situations when modmakers forget to remove their println debugging from the final product and the log gets overflown with useless debug information and slows the game down. Just launch any big modpack out there and watch the log. You will quickly see what I mean. A breakpoint is literally 2 clicks of mouse to set, gives you all the info you need and even more and it will never end up in the final product. 3. getUpdateTag should return all your NBT information you need to sync. A couple of responses above you posted: That will not work. It will send an empty packet to the server upon chunk loading and your tileentity will not have any data synced. Even worse, it will completely mess everything as the tileentity will not get loaded at all! See how it is done in the base Tileentity class. If you simply override both of those methods and their handlers (onDataPacket, handleUpdateTag) then your tile will get updated correctly on the client when the respective packet arrives. You still will need custom packets to sync real-time changes though.