V0idWa1k3r

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.

Erm, yes

Your json has no name property defined for your pools. Forge requires that property to be defined for mod loottables.

You do not use eclipse's export for creating jar files for mods. Like, never. Use gradle

You can see how vanilla does it in classes like BlockRotatedPillar, BlockChest, BlockAnvil... there are multiple blocks that are placed with rotation so there are plenty of examples. Be wary that those are vanilla examples and forge advices you to use a new forge method I've linked below that additionally contains a hand the player uses to place a block. Long story short the blockstate determined on placement is now conviniently returned in Block::getStateForPlacement(World world, BlockPos pos, EnumFacing facing, float hitX, float hitY, float hitZ, int meta, EntityLivingBase placer, EnumHand hand). You can override that method and return whatever you need.

You do not need to extend anything anywhere. Look at the examples Choonster graciously provided

Make sure that your loottable is a valid json and has proper syntax (name property defined) Place it somewhere within assets/modid/loot_tables/ Get a ResourceLocation pointing to it in your core. It should point to your loottable file, but it should not include the path up to loot_tables folder and the extension. Obtain a registry ResourceLocation using LootTableList::register Double check that your ResourceLocation is correct, your json is correct, etc. That ResourceLocation you obtain in step 4 is what you need. Refer to this topic for more details and examples: It is a very recent one too, so all the information there is up to date. Another related topic I've found: loottable file, location and syntax example. And registration example.

Replace all direct OpenGl calls with GlStateManager calls and your problem will magically go away. GlStateManager class is there for a reason and you should use it. The whole game uses it. Your problem lies in the fact that GlStateManager will only change the state if the change requested is not the current remembered state. Before the Post event is fired blend is enabled in the state manager. You are enabling it again later(which is fine, you never know if it is enabled or not) and then disabling it with GL. When the game renders the inventory screen it renders a slightly transparent overlay over the world. Guess how it does that? By calling GlStateManger::enableBlend(). Oh but there is a problem - GlStateManager thinks that blend is already enabled because you've used direct GL call and the boolean in the state manager has not been updated... so it does nothing leaving blend disabled. Thus you see the black screen. TL;DR - do not call GL directly. Use GlStateManager. Or things will get screwed up. Also you are neither scaling,rotating nor translating anything. You do not need to push/pop GL matrix as you are not changing it.