imacatlolol

In Blockbench, go to File -> Export and choose one of the options. You can use the exported files as normal. If you're doing a block, export as a blockmodel. If you're doing an entity, export as a java entity. Feel free to explore the other options too.

Food is no longer its own item, instead you have to specify the food in the item's properties. Take a look at the Food class for details, as well as how vanilla uses it; you'll have to use its builder to create a new food. As for AABBs, are you talking about blocks or entities? If it's for blocks, look into the VoxelShape class. Browse around the vanilla code to see how its used.

I want to create a mod library that can either be shaded into another mod's jar, or loaded as a normal dependency library. I'd prefer to avoid forcing mod creators to add my library to their list of required dependencies, while still giving them access to most of my library's features. For this to work, I'd need to rely on Forge not loading my library mod if it's shaded into another mod's jar. There's a handful of workarounds for this, such as forcing mod creators to chose one of the two options, but I'd love it if this idea is possible. Another way of visualizing my issue is to imagine a library that contains a main() method that allows it to do special things when run separately from the dependent's program (e.g. the H2 database engine, which can run a dedicated database on its own or simply provide a driver for a program). Similar idea to what I'm trying to achieve, but in the context of mods.

A compound NBT is an NBT tag that itself contains more tags, literally compounding them. You can read up on NBT data and how it works here.

@ObjectHolder objects must be public static final, not just public static. You can just initialize the object as null, and it will be replaced properly when the block is registered.

Your mod id is "cool" but your assets directory is called "coolmod". They need to be the same.

I created a complex block model to showcase the severity of the issue some more: Seems like BufferBuilder#sortVertexData() is only ever called to re-sort translucence vertices inside ChunkRender#postRenderBlocks(), which implies that manually sorting them ourselves in baked models may not be possible, but don't quote me on that. For now, a viable workaround would be to separate the problematic model into distinct "solid" and "transparent" models, then re-combine them in a single baked model by rendering them on the correct layers. You can check the current layer being rendered by using the static MinecraftForgeClient#getRenderLayer() method. The block would need to return true for both the solid and translucent layers, of course. This workaround isn't perfect, since quads that still need to render on the translucent layer won't be "fixed", but it will mitigate the problem for many cases. If it really comes down to it, using a tile entity may have to be a last resort if a better fix can't be found. Edit: Forge's multi-layer-model system would be a perfect way of implementing this solution, and would remove the need to write a custom baked model yourself. However, as of writing this, that feature is currently inaccessible. For now, you will have to implement this yourself.

I have the same issue, and sadly turning my blocks into tile entities won't be viable for me. Using a custom baked model and sorting the vertex data there would be an option, though. The trouble then is figuring out how to actually do that properly...

As a workaround, you could create an invisible light block that spawns nearby when the directional block is placed. You'd need to spend some time polishing it to make it seamless and handle odd cases, but it may create an effect similar to what you want.

After a bit of digging and testing, I've determined a solution that is adequate, though not very clean. (Pinging @Okmeis so they can see if this works for them) Add all needed textures to the atlas using TextureStitchEvent.Pre. In ModelBakeEvent, grab all existing registered models relating to the block from the registry, then wrap each state's model in a custom baked model and replace the registry entry. The custom baked model can then use the handy vanilla BakedQuadRetextured to "change" the texture of the wrapped model's quads. This feels kind of hack-ish, but it does produce the desired results with a minimal impact on load times and no file-spaghetti. I'm sure a superior solution can be found, so I'm happy to try other ideas.

For clarity, my idea there was to have a single set of model jsons and do this, which would (from what I understand) ensure all variants are stitched onto the block texture map, even if they aren't directly referenced in the variant models. Since it does ruin the space efficiency of the generated texture atlas, I would probably instead look into the TextureStitchEvent to see if I can insert the textures there. As suggested, I tried making all of the json files. It gives me the desired effect, of course, but it also added a significant (i.e. noticeable/non-trivial) increase in loading time. It also turned my filesystem into spaghetti, forcing me to use subdirectories just store all of the variants for each json model to not clog things up. This is all for just one complex block, which means the problem could compound if I ever want to add similarly detailed multipart blocks. This is really just an edge/corner-case issue, so using the normal route for this wouldn't be the end of the world, but I'd really prefer a less painful route. On the topic of baked models, something like this might be an option, especially if I use the TextureStitchEvent as I'd mentioned.

Bumping, if that's alright. One of my ideas for a solution would be to assign it a dedicated texture map that contains all of the variants, then somehow offset the UVs in a custom baked model. Not sure how to go about offsetting things like that, if that's even the best idea.

Hmm, that's certainly frustrating. When it comes to events, I'm not sure if there's an easy workaround. However, since the route you want to go may not work out, I do have two other suggestions to consider, just in case: Override onBlockActivated in your block's class and run your code there instead; this is likely the best alternative. Use an access transformer (or use reflection) to make BLOCK_STRIPPING_MAP in AxeItem public, then modify it to include your blocks. Or, since it's only protected, you can technically also add your own axe and modify it there.

One thing to mention, if you want to use my not-too-elegant solution, the main hand event will always fire first (since it's first in the Hand enum) so you'd only need to "cancel next" if the main hand fulfills the conditions.

Oh, I see what you mean. (I'm not on my A-game today) I'm sure a more experienced developer can offer a better solution, but you might try storing a temporary "cancel next" variable that cancels the following event in the opposite hand.

Oh, my bad. I believe that is normal behavior as well, since both hands can "right click". Perhaps check which hand is holding the item, and then pick the correct hand (I'd recommend choosing the offhand first, if both hands have the item).

That event is fired on both the server and the client, which is normal behavior. If you need to filter it out, perhaps check if the player's world is on the client or not the event itself has a method to check the logical side, so that would be the best place to check where the event comes from.

I have a multipart model for a block with a lot of states (maybe too many, but that's another issue). In it, some of the block state properties needs to be able to change the texture of the model. Ideally I'd add conditions in the multipart model definition to set the texture appropriately, but it seems like this feature isn't available. Since I'd prefer not to make a hundred or so new model JSONs just to do what I want (since that would increase load time and make things tough for resource pack makers), is there a good workaround for what I'm trying to achieve?

Oh, that makes more sense. It even says that right there in the docs for RegistryObject. Whoops, thanks again!

Woah... The DeferredRegister system is really cool! That's even better than anything I was expecting, thanks for bringing it to my attention! I'm assuming it won't interfere with ObjectHolder, right? From the looks of it, I simply need to initialize ObjectHolder objects with DeferredRegister#register instead of null and ObjectHolder will still take over any replacements by other mods.

Well, nevermind, found an adequate solution. Rather than initializing the fields inline, initializing them in a static constructor seems to solve the problem, funnily enough. However, I'm still open to other solutions for the sake of variety, if anyone has them.

I'm enjoying the ObjectHolder feature that was added to Forge, but it's been giving me a bit of a stylistic headache. I'm using IntelliJ IDEA and since ObjectHolder fields have to final, and therefore initialized as null before injection, it's complaining that ObjectHolder fields always return null. Checking to see if an ObjectHolder field is null before using it is still a good idea, but since it's a final initialized as null my IDE thinks I'm being silly. Also, I'm using the class-level ObjectHolder that infers the registry names from the field names, since I don't want to type my object registry names more than once in case I need to change them, and adding a separate set of fields just to hold the registry names feels like overkill, which is why I'd prefer not to do that. But if someone has a solution that requires me to annotate each field directly, I think that's a fine compromise.

Quark uses an access transformer to access layerRenderers, you can see it here.

You're registering your block as "block_sapphire_ore" but are using "sapphire_ore" for the resources.

Ah, I think that's exactly what I was looking for, thank you!