Jay Avery

You need to check the item of the element in the same way you were with your for loop: the element is an ItemStack so you need to call getItem to see if that matches the block's item. Edit: You really are getting close, don't be too disheartened!

I was on the 'noob' side of these conversations for many months, so it seems only fair to pay it forward when I can! Ah yes, you have the right idea! To handle this safely, you'll need to use an Iterator for the list. Here is a little summary of using iterators. Instead of your for loop, create an iterator and then use a while loop, with the condition that the iterator hasNext. Then to get the next item from the list, instead of your get(i), use next on the iterator. That'll return an element of the list (an ItemStack) in the way you expect, and you can check its conditions in the way you currently are, and remove it from the list using remove on the iterator. Edit: Checking the length in that way unfortunately won't work reliably, because of counting through the list at the same time as changing its length. Here is a stackoverflow question addressing the same problem.

You can't compare ItemStacks using the == operator, it checks for object identity - so a newly created stack will never be == to an existing stack. Instead you need to check the item that's within the stack (using stack#getItem) and compare it to the block's ItemBlock (which you can obtain from Item.getItemFromBlock). Items can be compared using ==, because they are singletons (so there's only ever one gold ore item, for example).

What is the error now? We aren't looking at your environment, you need to give every detail of what you change and what happens, every time, if you want more help.

Moving that method call will fix the current rendering problem, it just won't fix the sided code issue. It's okay to learn one step at a time.

You're telling it to remove a newly-created ItemStack object. That exact object won't be present in the list, because you've just made it. You're right in thinking you need to check if the drop would be the ore block. You'll need to iterate through the list of drops, and for each element, check whether its item (ItemStack#getItem) is the ItemBlock for the block in question (Item.getItemFromBlock(block)).

That's because you don't have a block variable there. You can use the same call to ModBlocks.registeRenders() that you were using. Just call it in your proxy's preInit instead of init.

Bump! I've tried digging through the block modelling code to see if I can figure anything out, but I'm really struggling to interpret. I've found where the 'face' of the element defines the shading brightness and it seems pretty definitive, so I'm guessing something goes wrong in the process of calculating which face is actually in which direction. It seems like this is done in FaceBakery#makeBakedQuad, with the makeQuadVertexData and getFacingFromVertexData methods. But it seems to use some mysterious bitwise calculations using arrays, and I do not understand how it works at all. Can anyone help me understand how those calculations are done, or suggest how/why they might be producing the wrong answers for my model?

The same would go for your previous code - modelling/rendering code is almost all client-side only and would crash a dedicated server.

Are you sure there are no errors? Post the latest log and updated file structure.

Yes, I think so too. Maybe you could try changing the file names?

This is the file it's looking for to get the item model. Do you have an item model file at this location? (Hint: you don't) This is the file it's looking for to get the blockstates. Do you have a blockstates file at this location? (Hint: you don't)

Show your most up-to-date log and file structure. The names don't all have to be the same, they just have to be pointing to the correct resources. The blockstates file has to be the block's registry name, but the models it directs to can have any name - as long as there is a valid model file at that location. Similarly, the textures used in a model file can have any name, they just have to actually be there.

I think it was only enforced in 1.11+ (but was recommended before then).

Post the latest log, and a screenshot of your assets folder structure.

All asset names must be completely lower case - names of blockstates files, models, and textures.

The docs have a basic overview of using events. To edit the drops from a block, you can use HarvestDropsEvent. In the event, you can check for your chosen block(s) and then edit the list of drops (from event#getDrops()) however you like.

I don't know the exact cause of the error, but the substitution system is generally extremely buggy. It would be much easier to achieve what you're trying to do using events.

Bump, any ideas?

All asset paths must be entirely lowercase. You are setting the model path using the registry name which contains capital letters. If that doesn't solve the problem, please post the latest log.

Well, if you've never set the NBT then it's never going to be equal to the condition you're checking for. It won't set itself to the exact text you want unless you tell it to. You're also using the == operator which checks for object identity. So unless you are checking references to the exact same object, they will return false even if they seem to be the same. Instead you should use equals or an equivalent method to check for matching content.

Where do you set the NBT of the stack you're checking?

What arguments does it ask for? Are they objects which you have access to?

I'm having a really confusing problem with shading on a json block model. The model is quite complex and made of several parts, and the block can be placed facing in any horizontal direction. In three directions, it looks normal, but when it's facing south, there's this strange shading error: To explain what's going on, that triangle is made of two elements (they are different sizes to stop them poking out the edges of the rest of the block), and for some reason on one side of the bock when it's facing one direction, the elements are shaded differently. Here is how the same face on that model looks when it's placed facing north (this is the way it should look all the time): Here is the model file (the relevant elements are the two that have rotation): I can't see anything in the model that can explain this. The elements are rotated exactly the same and constructed as similarly as they could be. I understand that minecraft automatically shades the different faces of an element differently to make cubes look realistic, but surely the faces of these two elements should always be the same anyway, so the minecraft-applied shading should match? And if it wasn't going to match, surely they would mismatch in every direction, not just on one side in one direction only? I know that I can add "shade": false as a fix, but this makes the whole element appear weirdly bright relative to things around it, and I'd much rather allow the default shading which is so close to being just right. Can anyone explain how this happens in one direction and not others? Is there anything I can do to fix it?

You never seem to initialise your item handler.