Jay Avery

What version of forge are you using? Did you install it correctly?

net.minecraft.entity

What is your question?

"Some errors"? If you don't give specific details no-one can help.

Okay, so then you fix that error. If you get a new problem when you make a step forwards, you shouldn't step backwards - you should fix the new problem. Where in the code do you open the container?

Bump! Someone please tell me there's a foolishly obvious solution

I feel like this must be something really obvious, because it seems very basic. I've got a custom door (which does not subclass vanilla BlockDoor - I'm adding and changing a lot of functionality so it's easiest to do from scratch), which opens and closes on right-click (as vanilla). In singleplayer this works fine, but in multiplayer there is a weird syncing problem. Visually, the door appears not to change its state - the model and the highlight bounding box stay the same. But the state does change on the server - if you try to walk through the door after 'closing' it (even though it still looks open), you bump into it (in a glitchy, jerky way), and can't get through. Here is my onBlockActivated. I was under the impression that setBlockState by default synchronises the state change with the client - and I've stepped through in the debugger and seen that it does reach notifyBlockUpdate. So I don't understand why it doesn't seem to be updating properly? The whole class is here (along with the rest of my code).

World#destroyBlock sets the block to air, spawns particles, makes the break sound, and drops items if applicable.

Okay, I just realised that I was noticing updates triggered by my own moving light source system... Thanks anyway.

Oh, when you asked this- I assumed you meant that the nether star is in the inventory. If it's not, then yes you will have to sync the nether star independently.

A few times I've noticed that events which occur in onNeighborChanged seem to happen when a player goes near (or touches?) a block (for example, I have some blocks which fall like sand a certain % of the time when they get neighbour updates, and they often fall when a player walks near them). I've looked through the code and can't find an explanation, but I'm also pretty sure I'm not imagining it. Do entities cause onNeighborChanged updates, and can anyone direct me to where this happens, if so? If not, can anyone explain this apparent behaviour I'm noticing?

Best way is to use ordinal() to turn the enum value into an int, and then values()[ordinal] to turn the int back into the enum value. Where is the code which is supposed to make this happen?

When you update the inventory contents on the client, you don't update the value of hasNetherStar. You need to set this field by checking whether the updated inventory contains a nether star or not.

Okay, so you're sending the information about the inventory contents to the client. How will the client know to set hasNetherStar if the inventory contains the right item?

Where/how do you sync the inventory?

It looks like you aren't syncing the hasNetherStar state to the client. You'll need to use a packet to send the new data to the client when it changes on the server.

Just reference the actual item that you want. All the items are stored in fields in the Items class.

Choonster's guess was correct, you are spawning the item on both the logical server and logical client. You need to check that the world is not a client (!world.isRemote) before spawning any type of entity - and read the page Choonster linked to make sure you understand about sides.

That suggests that the cache isn't working properly. Set breakpoints in getQuads and see whether models are being correctly retrieved from the cache when they're already present - or why they're not being retrieved if they should.

Are there errors in the console? Do your potion names contain capital letters? In 1.11+, all resource paths have to be entirely lowercase.

What for? What do you want to achieve (in gameplay terms) with this?

Post the latest log output, it will contain information about the errors. This approach is very outdated. Instead of Minecraft.getMinecraft().getRenderItem().getItemModelMesher().register, you should use ModelLoader.setCustomModelResourceLocation. You should not use getUnlocalizedName and that messy substring business to set model locations. Instead simply use getRegistryName, which also already includes your modid. Where and when do you call your ModBlocks' init() and registerRenders() methods? These textures do not contain your modid, so by default forge will be looking for them in the minecraft folder.

Changing vanilla textures (or models) is the same process as making a resource pack, like Draco said. To change the generation of ores, you can subscribe to OreGenEvent.GenerateMinable, check the EventType and set the result to DENY to cancel it. Then make your own IWorldGenerator and generate the ores as you want them.

What do you mean by "stuck on the loop"?

The unlisted properties aren't used in equals, so they won't be taken into account when using extended block states as keys for a cache. To get around this, make the keys of type Pair<ImmutableMap<IProperty<?>,Comparable<?>>, ImmutableMap<IUnlistedProperty<?>,Optional<?>>> which is the ugly parametrised type that represents Pair.of(state.getProperties, state.getUnlistedProperties()) This forces the unlisted properties to be taken into account when checking whether the state is already present in the cache. I use this approach in a model here if you want to see an example.