Choonster

World#isRemote is true on the client and false on the server. The server is in control of the game state, but you're making your changes on the client so they get overwritten the next time it syncs. Side note: Consider using bitwise operations when storing multiple values in metadata instead of using harcoded metadata values for each combination.

Correct, the two-argument overload of World#setBlockState (which uses 3 [1 + 2] as the flags) should work. Oddly enough, ItemBed uses 11 (1 + 2 + as the flags even though it only sets the block on the server and only the client-side implementation of IWorldEventListener#notifyBlockUpdate (indirectly called by World#setBlockState ) actually checks for flag 8. Edit: I always forget to disable smileys when posting something with "" in it.

Post your Block class.

When a bed item is right clicked on a block: The foot block is placed, calling Block#neighborChanged on the surrounding blocks (none of which are incomplete beds) The head block is placed, calling Block#neighborChanged on the surrounding blocks (one of which is the foot of the now-complete bed) Block#neighborChanged is never called on an incomplete bed while the bed is being placed. You should implement your Block#neighborChanged override such that it only checks the immediately adjacent blocks and not the whole structure. Let's say your structure is composed of three blocks: left, right and centre. When your item is right clicked on a block: Place the left block, calling Block#neighborChanged on the surrounding blocks. None of these are structure blocks. Place the centre block, calling Block#neighborChanged on the surrounding blocks. One of these is the left block, which checks the immediately adjacent blocks, finds the centre block and does nothing because it's valid. Place the right block, calling Block#neighborChanged on the surrounding blocks. One of these is the centre blocks, which checks the immediately adjacent blocks, finds both the left and right blocks and does nothing because they're valid. Whenever a structure block is broken, Block#neighborChanged will be called on the surrounding blocks. The adjacent structure blocks will see that the structure is now incomplete and remove themselves, propagating the change along the structure.

Do you ever create an register an instance of bookScale ? If so, why use the vanilla book for its sub-items? If not, why does it extend Item at all? A NullPointerException is thrown when you attempt access a method or field of a null value. You'll have to figure out what's null and why it's null . I mean you should use a loot function (either set_nbt or your own custom function) in the loot table file to fill out the page data for the book.

Forge has an animation system for baked models in the net.minecraftforge.client.model.animation package, though there's not a lot of documentation on it. Fry (a.k.a. RainWarrior) briefly described the purpose of each class in the commit that introduced the system. They've also documented the grammar of the Animation State Machine files here. Forge has a test mod for the system here.

That's correct.

The launcher is a standard Java program, you can decompile it with a Java decompiler. That said, you're unlikely to receive any support here for modifying it. I believe Lex's stance (and Mojang's) is that everyone should be using the official launcher rather than making their own. If you want to make a modpack manager, make it use the official launcher to run the game (like Curse does).

In 1.9.x, use World Saved Data. In 1.10.2, Forge has implemented World capabilities.

Either use the set_nbt function in the loot table file to set the NBT or create your own LootFunction that sets the appropriate NBT. You're setting the bookScale.eastScale field to an ItemStack of Items.WRITTEN_BOOK instead of the bookScale instance, are you sure this is what you want? I recommend following Java and MCP naming conventions: PascalCase for class names, prefixed with the base type that they extend (i.e. ItemBookScale instead of bookScale ).

You installed a coremod built for 1.7.10. If you don't know which one, upload the full FML log (logs/fml-client-latest.log) to Gist and link it here. You also posted this in the wrong section (Modder Support instead of Support and Bug Reports), but it should be moved soon.

I think you mean 0.

I'm not sure what the current problem is, creating a separate thread for it may be a good idea. There's a collection of tutorials for 1.10.2 here.

I can't help you with the world generation itself, but I suggest you use your IDE's debugger to pause the process when Minecraft freezes and see what it's executing. This may give you a better idea of what's causing the freezes.

EntityPlayer#inventory is an InventoryPlayer , not a Container . Use ItemHandlerHelper.giveItemToPlayer to give an item to a player or drop it at their feet if there wasn't room for it in their inventory.

Get the World 's WorldProvider from the World#provider field, then get the dimension ID from the WorldProvider#getDimension method.

I implemented this here using a per-tick check to see if the player's held item reveals hidden blocks (using a capability) and re-rendering chunks containing hidden blocks when the player starts or stops revealing them. This is based on the code that allows EnderIO's Yeta Wrench to hide Conduit Facades. I had to use a ticking TileEntity , but I tried to keep it as lean as possible. There was a small FPS drop when starting or stopping the revealing due to the chunks re-rendering, but FPS seemed stable once the chunks had been rendered. This may or may not be as performant as the TextureAtlasSprite method suggested by diesieben07.

TileEntity syncing changed in 1.9.4, there are now two separate methods used to sync data to the client. This document explains in more detail.

Call Container#detectAndSendChanges on EntityPlayer#inventoryContainer to sync the player's inventory to their client. If you make a large amount of changes to an inventory, consider calling EntityPlayerMP#sendContainerToPlayer instead. This sends a single packet with the whole inventory instead of sending an individual packet for each slot that changed.

Do not use the ItemStack(Item, int, int, NBTTagCompound) constructor, the fourth argument is for the capability data rather than the stack's compound tag. Use ItemStack#setTagCompound to set the stack's compound tag.

RenderGlobal#notifyBlockUpdate passes the boolean value of flag 8 to RenderChunk#setNeedsUpdate . I don't fully understand the world rendering code, but this appears to signal that the RenderChunk should be rebuilt from the current world data.

You need to set the srcCompat and targetCompat properties in build.gradle like I do here.

There's no reason to cast an object as you create it. Either refer to the inner class by its full name ( TileEntityBonfire.StackHandler ) or its own name ( StackHandler ), try to be consistent. As Animefan8888 said, you must have a solid understanding of Java and OO programming in general before you make a mod.

You never create an instance of your StackHandler class and thus you never use it. It should probably be a static inner class, it shouldn't need to access the TileEntityBonfire . There's no reason to override a method if all you do in the override is call the super method. Your StackHandler#insertItem method breaks the contract of IItemHandler , i.e. that passing true as the simulate argument doesn't affect the contents of the inventory. ItemStackHandler#insertItem already checks for stack being null and stack.stackSize being 0, there's no reason to do this in your override. Your writeUpdateTag method still doesn't account for storedItem being null .

Stop putting your posts inside quotes. I'm guessing your Block extended BlockContainer , which overrides Block#getRenderType to return EnumBlockRenderType.INVISIBLE (i.e. don't render the block). Instead of extending BlockContainer , extend Block and override Block#hasTileEntity and Block#createTileEntity .