Matryoshika

You are likely extending BlockContainer . Don't. Just simply override hasTileEntity(IBlockState) & createtileEntity(World, IBlockState) in your block. Go into the BlockContainer class, and look at it's getRenderType method. Generally speaking, BlockContainer is a pain in the proverbial behind most of the time, as vanilla uses TESR for almost all tiles.

writeToNBT is no longer a void method, instead, it is now a method using the object NBTTagCompound. This means that you need to return said object. public NBTTagCompound writeToNBT(NBTTagCompound nbt) { //Do stuff with the gained nbt parameter. return nbt; }

Well, if you cannot dynamically create your meta items through a simple for-loop, then you can always add them to a separate list. Let's call it itemMetaList. Then you can iterate through that list, and get the meta value from them, though it will be in the order you added them to the list. for(int meta = 0; meta < itemMetaList.size(); meta++){ Item metaItem = itemMetaList.get(meta); //Code to register this metaItem using the variable "meta" for the meta parameter. } This method will also keep the easy set-and-forget method for rendering said items, as long as you remember to also initialize said stand-alone meta-renderer

Blocks: Have a list that stores blocks Items: Have list that stores items Blocks in ModelLoader: Item.getItemFromBlock(block) Items in ModelLoader: item

Item and Blocks use the exact same way of registering, just need to convert the block to an item first(Item.getItemFromBlock(Block) == Item) If you choose to use this way, then yes, it should work if you mirror the rendering. Have a separate registering-list for items, and then call that item-list from your render-registry. Same setup as for the blocks. Of course, this way only works for items without specific meta. That "0" inside ModelLoader.setCustomModelResourceLocation(item, 0, new ModelResourceLocation(item.getRegistryName(), "inventory")); stands for the meta of the item that should be rendered.

After I kept seeing people make the same mistakes, I created this little GitHub project to help them. Right now, it only handles Registering & Rendering of blocks, which seem to be exactly what you need https://github.com/Matryoshika/Minecraft-Tests-Examples It shows examples of simple, and looped registrations. As pointed out, the looped is the preferred there. It also points you to use ModelLoader instead of getItemModelMesher(redundant) and why set & getRegistryName should be used instead of modid+substringing(completely horrid practice)

How do you want the player to interact with the block? Right click it? Step on it? There are method's in the Block class, and more, that will give you the player variable when he/she interacts with your block. The methods for the mentioned interactions are onBlockClicked & onEntityCollidedWithBlock . Be sure to cast the Entity given from the latter, to Player .

We need some more information, preferably some actual code. What type of worldgen are you using? I'm guessing that you are extending WorldGenerator, and not implementing IWorldGenerator instead. Have you tried using some logging to see if it even gets called/find where it stops?

Do not extend WorldGenerator directly. Instead, have your class implement IWorldGenerator. You can also seriously improve your method of finding a block-position. Is the twigs supposed to spawn up top, like trees, or can they also spawn in caves? If they only spawn with a clear view of the sky, you can use world#getTopSolidOrLiquidBlock(pos) . You can give it any valid block-pos, and it will ignore the y, and scan from the top of the world, down, for you. I make use of several IWorldGenerators here. Do note, I use a custom WorldProvider, ChunkProvider, etc. Ignore the parts of the code referencing those.

Blocks are singletons, so no. They cannot store any specific data. Change one, change them all.

mostly pseudo code, don't have access to my IDE atm. //Checking each possible slot for(i = 0; i < slots; i++){ //If one is null if(getSlot(i) == null){ //change the slot from null, to new itemstack setInventorySlotContents(...); break; } }

True. I use Main quite a bit myself, though the fact still stands: His code should be somewhere that is executed on both Server and Client threads.

The method's do not create the "same" thing. First and formost: The server only handles the Container. The container, is in essence, simply a list of boxes, and what they contain. The client handles the GUI. This is where the boxes from the Container are drawn. The client never touches the container directly. Anything you do inside a GUI, is sent to the server through packets. Think of it as a computer & screen. You interact with the screen, to change something in the computer. You don't manually open the harddrive and somehow magically set the correct state in the harddrive. In the code you showed: Line 19: return new [b]TestContainer[/b](player.inventory, (TestContainerTileEntity) te); Line 30: return new [b]TestContainerGui[/b](containerTileEntity, new TestContainer(player.inventory, containerTileEntity)); They return different things, if quite badly named, for the appropriate side.

There's not much that can be done about that, sadly. Tree's do not know if [This block of Leaf] belongs to itself, or if it belongs to another tree. What you can do, is force a maximum distance of which your method will destroy blocks inside. Essentially, follow every piece of leaves, up-and-until-these-blocks-away. This means your tool won't work (aka one-punch-kill all the leaves) on massive trees, but it will at least be better than punching individual leaf-blocks.

>_< Damnit, failed to see in time. If you read this post, would you mind answering why you have your Block Registration, in the Client-Proxy? That should be in the common-proxy, otherwise, if you load up a server with this, there will not be any blocks, because the server cannot see them, literally, if the server doesn't crash before that.

yeah, as I thought. You try to set the render for blocks, that does not yet exist. Switch these around:

Do you know about for-loops? Have a method that is run first when you break the tree. It checks in the x & z axis, in 1 block radii, meaning it checks blocks outwards in a 3x3 like this: It it cannot find a leaf-block at those coordinates around it, it goes up one level and continues. It gets the blockpos of that leaf, and runs throws it to another method. Then it destroys the leaf block. The "thrown" leaf-pos is sent, as said, to another method that scans the surrounding blocks around the leaf, and sees if any are leaves as well. If so, it continues to throw that new leaf to itself, iterating up, until it cannot find any connecting leaves. Because it throws the new leaf position, and then kills the leaf-block it originated from, the code will work from the bottom up.

Think I already know why, but please post your proxies & main file, preferably inside:

[*]Do not use Minecraft.getMinecraft().getRenderItem().getItemModelMesher().register for rendering. It's purely the years of experience and extensive knowledge of the rendering system, that let the Mojang coders keep the vanilla rendering "above the water". [*]Use the forge provided ModelLoader instead: Exactly the same variables used to call it. Just switch out Minecraft.getMinecraft().getRenderItem().getItemModelMesher().register for ModelLoader.setCustomModelResourceLocation [*] ModelLoader rendering has to be called in preInit , of course, after the blocks & items have been registered.

Minecraft has 2 sides. Client, and Server. Client handles everything that the Server doesn't need to know, like textures, rendering, and so forth, whilst the server handles positions, states, and so forth. Most code is run commonly eg, it is running on both of these sides simultaneously. World#isRemote() is checked against both sides, but only the Client returns true here, which means the server skips this piece of code.

Aaaaah. My bad then. You can simply skip checking what side you are on, and focus directly on the player instead. Your previous code-snippet should be fine to run, however, it is not explicitly safe. If you are on a server, the player should be EntityPlayerMP, yes, however, you never actually check if the player IS EntityPlayer first. You can cast classes to equal or super classes. You cannot cast it to another forked class like EntityPlayerMP/SP are. You can simply check: if(event.player instanceof EntityPlayerMP){ EntityplayerMP player = (EntityPlayerMP) event.player; //Rest of your code. } That is explicitly safe casting. Only cast to what you know you are casting to. Who knows, with the power of Java, pigs can easily fly. A mod spawning an EntityPlayerSP on a server wouldn't be too hard to imagine, bar for what possible reason.

Those are 2 different events altogether. They both fire when the player connects to the server, but in different places. Don't cast the Player to EntityPlayerMP or EntityPlayerSP unless you really do have to. Most if not all you really need exist in EntityPlayer already, which is what the event#player is. Entity->EntityLivingBase->EntityPlayer-> [EntityPlayerSp | EntityPlayerMP]. SP/MP are the same thing, just on the opposite sides of the server/client coin. If you only want to do something server-side, check if event#player#worldObj#isRemote returns false, and then do something, instead of checking isServerWorld() .

No, that is only fired when the server initially starts. You can subscribe to PlayerEvent.PlayerLoggedInEvent alt either FMLNetworkEvent.ClientConnectedToServerEvent or FMLNetworkEvent.ServerConnectionFromClientEvent . ClientConnectedToServerEvent is only fired on the client, and ServerConnectionFromClientEvent is thus, only fired on the server. I've also heard that the PlayerEvent.PlayerLoggedInEvent requires you to wait a tick before doing anything, as the event is fired before the player-entity is created.

Well, of course you cannot, the client only knows about itself. You would have to learn about packets and request the player's position from the server.

Well, as I mentioned in a previous post just today, I have an IWorldGenerator that places various trees for me, in a custom WorldType, WorldProvider, ChunkProvider etc. The actual dimension is heavily similar to the Nether, literally just stone instead of netherrack and so forth. You can find the link to said IWorldGenerator, in said thread. As for the grass: How much of the grass do you want to spawn? If you want it to spawn quite a bit, but not take too much resources, I'd recommend you bake it directly into your chunkprovider. In my own chunkprovider, I have a pseudo-dirt block that changes itself to grass|dirt|snow|sand|sandstone depending on biome and what is above it; this lets me easily add in 5 different blocks, at the world-generation cost of almost nothing. ChunkProviders work directly with blockstates, whereas most custom worldgen 1) get block, 2) check block, 3) either stop or change block. This is heavy on performance. You can see my voodoo-block here. Take note on the snow-placing especially, as it checks if the blockpos above is suitable for another type of block, like you want for your grass.