Jay Avery

In what events do you call those other classes? It's not about which class the method is in, it's about which stage of mod loading it happens in. Edit: Posting all your up-to-date code would be the easiest solution.

Where do you call these methods? ModelLoader.setCustomModelResourceLocation needs to be in either FMLPreInitializationEvent or ModelRegistryEvent.

You need to override isOpaqueCube and isFullCube in your block class to return false, so that it always renders the faces of adjacent blocks.

Bump! Does anyone have any ideas? D:

As long as you use getActualState, it will retrieve the information from the TE whenever it changes and return the correct state for rendering.

You shouldn't store a reference to the TE in the block - a block is a singleton so there's only ever one instance, but a new TE instance is created for every block of that type in the world. To get a TE at a certain position you just use world#getTileEntity.

Yes, if you store information in a TileEntity you'll need to use writeToNBT and readFromNBT to store and retrieve the data. It's saved when the world is saved/quit, and reloaded with the world. If you want the TE data to influence the block's actual state in the world (e.g. for rendering purposes), you'll also need to override getActualState in the block class. In that method, you retrieve the information stored in your TE, and return the applicable blockstate based on that.

I gave a link to the forge docs. I'm not sure what else to explain about metadata. It's just a way of translating from a blockstate to a number and back again, it's essentially a simple shorthand. There are two methods you need to override: getStateFromMeta and getMetaFromState. In the first one, you get a number and return a blockstate, in the second you get a blockstate and return a number. All you need to do is make sure that those two methods do the inverse of each other: that if you get X number in getStateFromMeta and return state Y, then if you get state Y in getMetaFromState you return number X. You can use whatever technique you like to translate your states to numbers and back again, it just needs to be self-consistent in order for the blocks to be saved and loaded correctly.

Okay, so he needs to learn how to use blockstates and metadata to save them. Start with the forge docs. Then inspect the vanilla code for blocks which store similar kinds of state information (hint: beds, doors). Ultimately there isn't any maths involved in metadata. It's just a way of representing the different possible states of the block in the form of a single number (between 0 and 16). If you want, you can manually translate them by checking individual conditions: "if this particular state, return 5, if that particular state, return 6", and so on (and the same in reverse). That's just slightly awkward and verbose, so it's more concise to use some simple multiplication and bitwise operations to do the same thing if possible - but if that's confusing them start by doing it the verbose way so you can understand what you're doing. Also note that if you have more than 16 different possible states, you won't be able to store them in metadata - you'd have to use a TileEntity to store them instead.

Please post the full stack trace of the error, and use the code tags (<> icon), otherwise it is very hard to read.

Post the latest log, it will contain the texture/model errors.

What exactly do you mean by "as a group"? There are a lot of different things involved in blocks - placing, breaking, activating, associated items, etc. All of those things happen independently, so have to be handled differently depending on exactly what you want to achieve. I'm not frustrated, but slightly confused - why isn't your friend posting here? It would be a lot easier to give help if we could see the current code and get precise details on what isn't (and is) working as intended.

Look at how vanilla multiblock structures like beds work - neighborChanged is the method that gets called when an adjacent block is broken.

You set a block in the world using world#setBlockState. Where you use that depends on exactly how you want it to work.

Post your code. That error means you are returning the wrong type of object from the method.

We can't help you if we don't know what you've tried so far.

I'm working on rearranging my mod to use the new(-ish) block, item, and model registry events (like this post). There are a lot of other registration-type things which I currently do in preInit or init events, and I can't find out whether there is a newer/better place I should be doing them. For example: Event handlers Entities Entity rendering Tile entities TESRs Fluids Packets Capabilities Do any/all of these have registry events (or similar) of their own? Or should they still be done in preInit/init as older sources advise?

I explained the problem, it hasn't changed. shadowfacts has explained (again) what is wrong, but you don't seem to be understanding it. It seems like you are struggling with some fairly fundamental aspects of object-oriented programming, and how methods and parameters work. There's not much more I can think of to say that will explain what's wrong other than re-writing your code for you - which I'm not going to do (because you'll immediately be back here as soon as you need to change something, if you don't understand the code you're using).

That error says that the ItemBlock is being registered twice. That's because you have a slightly different version of the same mistake in registering your items in registerBlock. Within that method, you twice create a new ItemBlock from the passed Block parameter, and register it under the Block parameter's name. You give the variables different names but that doesn't change the fact that you're doing the same thing twice.

It can't be the same error, because when you comment out those lines completely you no longer register either of your blocks at all.

No, you still don't realise what I'm saying. The method registerBlock, within itself, already registers both blocks. You've written it that way. Inside registerBlock, you have lines GameRegistry.register(townCentre) and GameRegistry.register(house). That means that every time you call the registerBlock method, no matter what parameters are passed to it, both of those lines get executed. When you call registerBlock(townCentre), those two lines get executed. When you call registerBlock(house), those two lines get executed.

No, you call it twice: public static void register() { registerBlock(townCentre); registerBlock(house); }

Within your private registerBlock method, you register your townCentre block and your house block. You call the registerBlock method twice. Both times you call it, it tries to register townCentre and house.

You never actually call your common proxy preInit method from your main class.

That's the reason it's not returning true, so fixing that will solve your problem. An ItemStack will never be == to an Item, so the if statement will always be false in its current form.