Draco18s

...inline it?

static RenderItem ri = mc.getRenderItem(); Have you tried...not doing it like this?

You can use this class as an example. It's a wrapper that prevents insertion, but allows for extraction. You'd be doing something similar, but in reverse. As Choonster mentions, it has a reference to another ItemStackHandler that acts normally so that your machine can insert and extract, but this one is exposed in getCapability: Instantiation: https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/ores/entities/TileEntitySifter.java#L50 GetCap: https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/ores/entities/TileEntitySifter.java#L141 Internal use: https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/ores/entities/TileEntitySifter.java#L93

I don't know.

What's wrong with world.setBlockToAir?

TL;DR you're composing states into 4 bits worth of information and the decomposing those 4 bits back into states. Booleans are 1 bit, integers are 1-4, depending on how many values they have (horizontal facing uses 2 bits, full facing uses 3). Bitwise operators mask off the bits that aren't related to the bit(s) you care about. & 3 means that only the lowest two bits retain their values: bx1010 //some arbitrary meta value & bx0011 // & 3 ======== bx0010 //facing value (2)

public static final PropertyEnum<BlockModBark.EnumAxis> LOG_AXIS = PropertyEnum.<BlockModBark.EnumAxis>create("axis", BlockModBark.EnumAxis.class); You know, you don't need to create a new LOG_AXIS property, you can just reference the one in vanilla's BlockLog.

What you're looking at is the only way to register blocks and items right now. And it's the raw basics of it. There's no differentiation between how blocks and items need to be handled (variants, IStateMapper, custom MeshDefinition...) If you want something with a little more nuance, check out my EasyRegistry classes: https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/hardlib/EasyRegistry.java https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/hardlib/client/ClientEasyRegistry.java Note that the classes are both proxy and event handler.

GameRegistry.register is private in 1.12, so I don't know how you're using it. You should be using the Registry events. If you want to have a one-line registration and handle everything all at once regardless of how you want to register the block, check out my EasyRegistry classes: https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/hardlib/EasyRegistry.java https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/hardlib/client/ClientEasyRegistry.java note that the classes are both proxy and event handler.

If you're using @GameRegistry.ObjectHolder then you don't need to do this: ItemSaw= The whole point of ObjectHolder annotations is to set the field for you.

https://en.wikipedia.org/wiki/Bitwise_operation#AND

event.getRegistry().register(ItemSaw=new ItemSword(... event.getRegistry().register(new ItemSaw(... Wot. Why do you have two different RegistryEvent handlers? Not that either one of them is actually subscribed to the event bus.

This is 100% normal and expected. As for why the alpha's rendering oddly, no idea.

Caused by: java.io.FileNotFoundException: isdevpds:models/item/steel_ingot.json Caused by: java.io.FileNotFoundException: isdevpds:blockstates/steel_block.json Caused by: java.io.FileNotFoundException: isdevpds:models/item/steel_block.json

Ah, there we go. Almost certainly going to be almost impossible to pull off.

That's not 7, that's 12. 2 possibilities * 6 possibilities = 12 You can also use a different bit (6 -> 8, uses bx0111, leaves bx1000 for the boolean)

Wait Are you trying to prevent the render of a specific block that you control, or something else?

EnumFacing is a 6-value property. If you don't want to have a block face up/down you can use EnumFacing.getHorizontalIndex instead.

It has nothing to do with preference, it has everything to do with logical sides vs. physical sides.

There's a reason this thread exists:

Use breakpoints and dive into the isInsideStructure method and see what's going on (you'll have to go a few levels deep).

Log?

Generics (explained generically) are very useful. They're for telling the programmer "I want a thing, but I don't care what kind of thing, as long as that thing has these properties" (expressed as an interface, other class, or hierarchical relationship). For example, the (old way) of registering items was a single method: GameRegistry.register(...) the parameter for that method was defined as <T extends IForgeRegistryEntry>, that interface being applied to blocks, items, potions, enchantments, and a whole host of other things. It allows the program to be clean and elegant, as the single method can handle any kind of object that needed to be registered, as they were all handled identically, even though they were disparate object types. It's not that much different from declaring the parameter as the thing it is (e.g. IForgeRegistryEntry) except you can be more specific. e.g. I do this for one of my helper registration methods. Notice that the parameter is declared as being two things: A Block and IBlockWithMapper (an interface that allows me to extract a custom IStateMapper for determining how to map block states to models) and I can then do so without ever needing to do instanceof or explicitly cast. Or do things like this, where two different parameters relate to each other. In this case, that one type (V) is a child class of another type (T) and that an object of each type will get passed in: IProperty<T> property, V value How generics relate to one another comes down to Covariance (the alterations are altered the same way) and Contravariance (the alterations are mirrored): https://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science)#Inheritance_in_object-oriented_languages

You need your mod ID as a folder between "assets" and "textures" / "models"