Jay Avery

Post the whole log.

Your item model files all have the same json syntax error - they are missing a closing bracket. To avoid this in future, use a json plugin in your IDE or run your files through a checker like jsonlint.

You specify a model in the "inventory" variant of the block's blockstates file, and it will automatically be used for the ItemBlock's model if there isn't one in the item folder.

I typed it wrong, I've now edited my post - the method is ModelLoader.setCustomModelResourceLocation. Sorry for confusion!

Don't use ItemModelMesher#register for models, it is buggy and very outdated. Instead use ModelLoader.setCustomModelResourceLocation (the method takes the same parameters), called either in FMLPreInitializationEvent or ModelRegistryEvent. Please post the latest client log, it should contain rendering errors (logs/fml-client-latest.log).

Forge has a Slot implementation for IItemHandler inventories - net.minecraftforge.items.SlotItemHandler.

You want to get a random number to pass as the metadata of your egg block. To get a random number, use world.rand.nextInt(yourNumber). Replace yourNumber with a number that's one bigger than the biggest possible number you want. So if you want a random number between 0 and 3, you would replace yourNumber with 4.

Generate a random number from the possible values. Use the Random instance from the World (world.rand), then call nextInt which returns a random integer between 0 (inclusive) and the argument you pass it (exclusive).

Bump!

Yes, you need a model for every ItemBlock. But there are easy ways of doing it if it has the same model as the block itself. If you use an item model file, set the parent to the block model itself, then you don't have to set the textures in the item model because the block already has them. Or if you use the forge blockstates format, you can define the ItemBlock model using the "inventory" variant (or the defaults, as long as you still include an inventory variant).

Next one, models/block/tutorial_ore (ah, this is where the cube_all came from) Last but not least, the models/item/tutorial_ore Okay, a few problems in these files!. Firstly, in the blockstates file, your model points to "ianusinchq:tutorial_ore". The game translates this to the location assets/ianusinchq/models/block/tutorial_ore. Is that the location of your block model? No, you said your assets folder is named modclass, not ianusinchq. Now, you have the same problem in your block model file. The texture points to "ianusinchq:blocks/tutorial_ore", which translates to assets/ianusinchq/textures/blocks/tutorial_ore. But you said your assets folder is named modclass. Additionally, as Draco18s pointed out, you are labelling the texture "layer0", but this isn't the name of the texture in cube_all. The texture used for the block faces is called "all" (this is what you saw in the log). And finally, the same problem again in your item file! The model points to "ianusinchq:block/tutorial_ore", which means assets/iausinchq/models/block/tutorial_ore, which isn't the correct location of your block model.

I assume by "in GUI" you mean the ItemBlock doesn't have a model? That will be because the ItemBlock model is defined by the "inventory" variant in a blockstates file. Your "inventory" variant is empty, and you have no default model set, so there is nothing for the item to refer to. Edit: Actually I didn't realise you do have an item model file (which takes precedence over the blockstates "inventory" variant, making it unnecessary in your file). What do you expect your item to look like when the only information in your model is this? { "parent": "block/cube_all" } The log even contains a hint: [20:06:06] [Client thread/WARN]: Unable to resolve texture due to upward reference: #all in minecraft:models/block/cube_all It's looking for a texture definition #all, but you haven't given one. You've just told it to be a cube with no information about textures.

.

Your posts make me smile! I like how detailed you are about explaining what you've done and what's not working, compared to some people who just say "it's broken" and expect answers. So, the block with no texture. This issue is only to do with rendering - it's nothing about registration (you seem to have that all working - although I'm no expert on @ObjectHolder stuff). For the rendering problem, there will be errors in the console log which explain what has gone wrong - can you post the log so we can look? Also, because there are several files with the same name I'm not certain which is which from your post. Could you please clarify by posting the files you have at each of these locations: blockstates/tutorial_ore models/block/tutorial_ore models/item/tutorial_ore

You have made a method yourself which gives the data from the tileentity: public String getOwnerS() Also, this field should not be static: private static String ownerS; Static means there is one value for the whole class, rather than one value per instance. If someone places a new tileentity, they will become the owner of ALL tileentities of that type. Presumably that's not what you're going for. You also cannot use this. with static fields - your IDE should give you a warning if you do.

You already have a much more convenient way of finding out if your code still has problems: try it and see what happens!

Yes, you need NBT, it's just not relevant to this particular issue of making a tileentity which only a certain player can access. NBT is just something you have to do for any tileentity which stores data of some kind.

This is not a specific question, I'm more just wondering about best/recommended practises. Is it a good idea for a released mod to have some kind of logging system (like forge itself does), to use for recording and identifying issues? If so, where should this be? A log file of its own? Combined with something else? Just printed to the console? And how detailed should logging be? Should it only contain errors, should it record initialisation of the mod, in-game behaviour..? And if it's not particularly recommended for a mod to have a logging system, then what should be done with errors? For example I have a mod which takes user input in the config and resets it to the default if the input is invalid - it would be good to tell the user when this has happened, so where should that information go? I'm sure a lot of this is just personal preference, but I'm interested to hear what other people do. I've never 'released' any code other than mods, so I have no idea what is normal in this kind of situation. Examples or recommended reading would be appreciated too.

NBT is for storing data when the world is saved, it's not relevant to this issue. When the block is placed, you need to store the placing player in the tileentity. You have access to the block and the placing player in onBlockPlacedBy, you just need to get the tileentity and store the information in there. Then when someone tries to activate the block, you check the tileentity to see if they are the allowed player. You have access to the block and the activating player in onBlockActivated, so you just need to get the tileentity and check the information to respond accordingly.

I'm not sure what you mean. You won't need to add any new properties to your blockstates file, you just need to figure out how (if it's possible) to calculate the correct part for a given block by checking the states of its neighbours. Note that you can't check a neighbour's part, because that would require calling getActualState and create an infinite loop. If your block already has a tileentity, it's most likely easiest to simply have a part field in the tileentity which you can then access in getActualState.

You will need to use getActualState, which allows you to apply properties that don't fit in the metadata (but that won't be stored). Those properties must either be possible to calculate based on surrounding blocks (like a vanilla fence, which calculates its shape from the blocks adjacent to it), or be stored in a tileentity which you get the data from. Does your multipart block have a tileentity?

Where are you calling your model registration code? Is it actually being executed?

I have implemented an invisible light block in my mod, you can see it here. Overriding rayTrace to return null means the block has no collision box or wireframe highlight, and overriding getRenderType to return INVISIBLE means the block has no model. Get/set the light value in the same way as any other block (in mine I have the light value as a changeable property of the block which is stored in the state, but for a constant light level that's not necessary). Place the block in the world in the same way as any other, using World#setBlockState.

In your workspace there should be something called "referenced libraries" or similar, and inside there will be a folder called something like forgeSrc. Here is what it looks like in my eclipse workspace: You can also get directly to a particular class by right-clicking and choosing "open declaration" (again, in eclipse - but other IDEs should have something similar) - for example you can click on Item where your class extends it.

Well, it seems to be in the right place now. What forge version are you using? In my 1.11.2 workspace, the annotation is at net.minecraftforge.fml.common.SidedProxy - can you find it?