Jay Avery

That's because Item and ItemStack are different types. getHeldItem returns an ItemStack (not an Item). Use stack#getItem, like in V0idWa1k3r's first post.

I don't think there is any way for you to intervene in the code of another mod which doesn't use events.

Getting a value from NBT is different to getting a value from a capability. Which do you want to do? For NBT, you can call stack#getTagCompound. For the capability, you call stack#getCapability and pass your capability instance.

Choonster's information explains why the check failed - player#getActiveItemStack only returns a stack if it's currently in use (like charging a bow). When a player right-clicks on your block, the item they're holding isn't in use, so player#getActiveItemStack will always be empty. If you want to know the stack they have in their hand (regardless of whether it's in use), you can use player#getHeldItem using the EnumHand parameter passed to the method (the player's current active hand).

getClientGuiElement should return a GUI, not the Container class. You should use the ID parameter to identify which container to open, rather than instanceof checks. Where do you open your GUI(s)? Please use code tags (<> icon) next time, otherwise it is very hard to read.

Your client proxy needs to call super in each method, in addition to its own code - otherwise it won't do the basic registration and stuff.

I've never contributed to something on github before and I'm a bit unsure of what to do. Plus there's an open pull request for a big overhaul of the models and blockstates documentation so my small addition will probably get in the way?

Your block class doesn't contain a facing property though. You have to define it in the block's code, otherwise how does minecraft know when to use which variants from the blockstate file? When you don't specify variants, it uses "normal" by default. The link I sent explains how to create a block property.

Glad to help! Json can be a nightmare for small and inexplicable bugs. D: I just dug through the ForgeBlockStateV1 code to understand why this happens. It's not specifically to do with the "custom" tag, it's just the way that forge identifies fully-defined variants. The way forge recognises a partially-defined variant (one where the properties will be combined with the properties from all other variants) is that the first element inside the variant is a json object (a tag followed by curly brackets). So the variant "property_name" is recognised as partially defined because the first element inside it is "one_value": { }, a json object: "variants": { "property_name": { "one_value": { // submodels and whatnot }, "another_value": { // submodels and whatnot } } } And a fully-defined variant which starts with, say, a "model" tag will be recognised because the first element inside it is not a json object (it's a json primitive, a tag and one string): "variants": { "full_variant": { "model": "modid:modelname" } } But, in a case like a fluid blockstates file, you might want to make a fully-defined variant (one that shouldn't be combined with other properties) where the first tag inside it happens to be a json object, like the "custom" tag: "variants": { "fluid_variant": { "custom": { // etc } } } So forge gets confused and thinks this is a property variant like the first example, and can't find it properly when it's needed. But (other than making sure the first element in the variant is an object, like by putting the "model" tag first inside every one), this check will be overriden if the variant is a json array (a tag followed by square brackets): "variants": { "fluid_variant": [{ "custom": { // etc } }] } Sorry for the infodump, I got a bit focused on working this out because I've always been irritated by not understanding forge blockstates. I've seen advice to "use an array for fully-defined variants" but never quite understood why that was or how exactly it's defined.

I just did some poking around my own fluid rendering and I think I've found the problem. For some reason (I don't 100% understand the forge blockstates format myself...), forge doesn't seem to understand fluid blockstates if the "model" is defined in the "defaults" section and the "variant" is surrounded only by curly brackets {} . Either you need to define the model individually inside each variant: { "forge_marker": 1, "variants": { "your_fluid_type": { "model": "forge:fluid", "custom": { "fluid": "your_fluid_name" } } } } Or you need to wrap each variant in square brackets [] too: { "forge_marker": 1, "defaults": { "model": "forge:fluid" }, "variants": { "your_fluid_type": [{ "custom": { "fluid": "your_fluid_name" } }] } } I'm guessing it's something to do with the use of the "custom" tag, but maybe someone very knowledgeable about the forge blockstates format can explain fully.

RenderingRegistry.registerEntityRenderingHandler should be called in preInit, not init.

Post the latest console log (in full) and the most up-to-date blockstates file. Also, please use the code tags (<> icon), otherwise it's hard to read.

This is the variant it's trying to render. That means it's looking for a blockstates file (in assets/smalladditions/blockstates) called fluid.json, and a variant in that file called "liquid_mercury". You either need to rename your file and variants, or change the ModelResourceLocation that your fluid tries to render. If you need more help, post the code where you register your fluid's state mapper etc.

You can register a custom state mapper - ModelLoader.setCustomStateMapper. Take a look at BlockModelShapes.registerAllBlocks to see how vanilla implements state mappers (there's a StateMap.Builder class which has an ignore method).

If you want your block to have a variable state (like direction), you need to use blockstates. Define a property, override getMetaFromState and getStateFromMeta, and whatever methods you need to set the state as you want it (e.g. getStateForPlacement). If you don't want to do this, instead you can simplify your blockstates file - remove the "facing" variants and just provide a "normal" variant and the model will always be facing the same direction.

Do you define variants in your Block class? Post your code.

That's because you're storing the block ID as a static field, which is the same for every instance of the class - you're overriding it for all instances each time you construct a new instance.

I created an item decay system. It uses a capability which stores the world time that the item was created, then any time the decay status needs to be checked the age is calculated using the current time. I haven't (yet) done anything with special containers that affect the rate of decay though, it would probably need a bit of an overhaul to my current system. The code is on github if anyone wants to see anyway.

Entities store their own position which you can get using entity#getPosition.

You're getting a ConcurrentModificationException because you are modifying a collection (by calling content.remove()) while iterating over it (your loop for (final ExtendedItemStack stack : content.values())). To prevent this you need to create and use an iterator directly, and call remove on that instead of on the collection itself.

As I suspected! I didn't use your blockstates file technique, so my bet is that it's somewhere in that process that models aren't being found or loaded correctly. I just had another poke around. In the vanilla blockstates process, BlockStateLoader.load is called with a specific Gson as the second parameter, not a generic new parameterless constructor one. The method ModelBlockDefinition.parseFromReader calls it using its own Gson which seems to be set up to read blockstates, so I'd give that a shot! (Disclaimer, I have no direct experience of reading json resources, but this is what I would be doing if I wanted to work it out :P). Edit: But yes, becoming comfortable with using breakpoints and the debugger is always a good idea!

That's what I'd try next! See what result contains just before it's returned from getQuads. It may be empty for some reason, and then you could backtrack and find out why it's not being filled.

Are the appropriate methods being called (e.g. accepts, loadModel and bake during startup, getQuads when the block is placed or the state is changed)? If the methods are being called correctly, step through them (or use print statements) to see whether the flow is what you expect it to be (e.g. is a condition returning false when you expect it to be true, is something null at the wrong time). I can see you've already got some print and log statements in the code, could you show a log from starting up the game and placing one of your blocks?

Do you mean you want to know where to find the folder?

1.7.10 isn't supported on this forum - your thread will probably be closed by a moderator. If you're updating a mod, you should move to the latest version, 1.11.2.