Custom block appearing in inventory but not when placed in world

[Echo Weaver]

So, I created a custom block. It even had a very simple C# modded BlockEntity class. Everything worked. It was beautiful.

Then I decided I wanted to my block to have a clayworking recipe. I created the recipe just fine, and it worked. Then I tried to add "-raw" and "-burned" variants to the blocktype json, using storagevessel in 1.20 as a template. 

At this point I blew up the json for my block in some way, and I haven't been able to recover.

Does anyone know why a block would appear in the Creative menu and in my inventory hotbar with the correct model and texture, but then not appear when I try to place it in the world? I mean, the block is "placed." I see the mouse over for it with the correct information, but it's invisible -- I guess the shape, texture, or both are not loading. But clearly the game has access to SOMETHING for the shape and texture, since it was able to create the thumbnail for inventory.

One thing I learned is that the json blocktype definitions are incredibly powerful, but they're also pretty fragile, and the same information is not necessarily represented the same way across blocktypes. 

This is really quite a baby mod I'm trying to build. I'm bemused that it has turned out to be such a challenge.

Edited August 28, 2025 by Echo Weaver

[Brady_The]

28 minutes ago, Echo Weaver said:

At this point I blew up the json for my block in some way, and I haven't been able to recover.

What do the logs tell you? If your block stopped working after the change, you might have mistyped something in the file that breaks your asset. Share it here if you like.

Btw, in 1.21 clay objects changed a bit. -raw and -fired variations were for some reason moved into separate files. -burned was replaced with -fired. This is just fyi. This change to the vanilla items should not break your block.

[xXx_Ape_xXx]

Share your blocktype json and we can take a look, it's hard to guess without knowing what we're searching for. Might be shape missing, texture not referenced properly or a number of other things that can cause this. 

 

Note:  Asking on Discord generally gets you faster answers, and more eyes on your issue, than the forum 

Edited August 29, 2025 by xXx_Ape_xXx

[Echo Weaver]

15 minutes ago, Brady_The said:

What do the logs tell you? If your block stopped working after the change, you might have mistyped something in the file that breaks your asset. Share it here if you like.

Hmm. So, when the game crashes, I can get the details I need out of the crash logs. There was nothing unusual on load up. I'm not sure which log to look in for the error.

20 minutes ago, Brady_The said:

Btw, in 1.21 clay objects changed a bit. -raw and -fired variations were for some reason moved into separate files. -burned was replaced with -fired. This is just fyi. This change to the vanilla items should not break your block.

Well, the complexity of managing both types in the same block definition makes me think that making them separate files is a good idea. There are something like dozen different fired ceramic colors, and several different ways to fire your clay with the nuances of the beehive kiln. I haven't actually tried to do anything with a beehive kiln, but I can see all those variants. 

Gotta say that moving from "burned" to "fired" is a great terminology change, though.

14 minutes ago, xXx_Ape_xXx said:

Note:  Asking on Discord generally gets you faster answers, and more eyes on your issue, than the forum 

Yeah. I've lurked on the Discord. I don't know why I'm more comfortable on forums. I'll make myself go ask there. Not that many experienced modders seem to hang out on this forum.

[Brady_The]

57 minutes ago, xXx_Ape_xXx said:

Note:  Asking on Discord generally gets you faster answers, and more eyes on your issue, than the forum 

Discord sucks, though. Especially as a forum replacement. So I try to be as active as possible here, even with my limited knowledge. 

Edited August 29, 2025 by Brady_The

[xXx_Ape_xXx]

Hey, nothing wrong using the forums, I'm sure there are experienced modders here aswell  

 

[Echo Weaver]

18 minutes ago, Brady_The said:

Discord sucks, though. Especially as a forum replacement. So I try to be as active as possible here, even with my limited knowledge. 

14 minutes ago, xXx_Ape_xXx said:

Hey, nothing wrong using the forums, I'm sure there are experienced modders here aswell  

Obviously you guys hang out here! And I am grateful.

I probably spend more time on Discord than is healthy, so it's not that I hate the place. When I've lurked there, the modding channel is actually SO ACTIVE. It's multiple conversations going simultaneously.

Well, I kinda wasted your time. I thought maybe there was an obvious thing that caused that behavior. I was able to copy over the vanilla object I started from and make piece-by-piece adjustments until it worked again. I'm still not totally sure what the problem was. I think I might've copied over a ".json" from a file path. After a while, you stare at these things, and they all run together. 

Now I have a git repository, and the damn thing is checked in properly, so at least I can back out to a state that works.

I do want that clayworks recipe, though it now occurs to me that I'm using a model that has a flat block-sized top. That makes the pit kiln a bit weird.  I don't have the model creator working, so it'll be what I can copy from vanilla until I go back to mess with that again. (I'm a Mac user, don't laugh.) The model utility requires an Eclipse framework I've never heard of. 

I'm much more a coder than a modeler.

[Echo Weaver]

OK, so here's one I'm still stuck on. I went back and added a separate block to be the raw clay version of the the block, ala the 1.21 way. I haven't found an example in 1.20 of the raw and fired (burned) versions of a block defined as separate blocktypes in separate json files, but the json certainly looks like it would work....

So, the project is just a new instance of the crate blocktype that has a bonus to food spoilage like a storage vessel. I'm using the shape of two versions of the "metal barrel" clutter, barrel-metal1 (the open version) and barrel-metal2 (the closed version) and texturing them with the 1.20 ceramic texture. I had to copy the shapes into the filenames foodcrate-opened and foodcrate-closed because the Crate class switches between opened and closed versions by doing a string-replace of "opened" to "closed" in the path of the shape. (WTF, c'mon Anego, it was your idea to make all this stuff insanely customizable with json....) 

The code part of this mod is literally just a subclass of BlockEntityCrate to override the GetBlockInfo method to include the freshness info of the contents in the tootip using the method provided by the Shelf blocktype. By default, the container classes just report the spoilage rate, and you can't view the storage slots of a crate, so the tooltip has to tell you the state of the contents. So this is about the most baby of baby beginner code mods. All my trouble has been with the json for crate blocks.

So.

All the game mechanics seem to work with these two separate blocktypes, except that the raw blocktype has the REVERSE problem from the one I had earlier. It is textured correctly in the world, but in Inventory/Creative menu, the texture is a great big "?"

Here's my json if there's anything to learn from it.

{
  "code": "foodcrateraw",
  "class": "BlockGenericTypedContainer",
  "entityclass": null,
  "behaviors": [
    { "name": "GroundStorable", "properties": { "layout": "SingleCenter" } },
    { "name": "Unplaceable", "__comment": "The ground storable obsoletes this being a block. Should be an item, but is kept a block for backwards compatibility" },
    { "name": "RightClickPickup"}
  ],
  "shape": { "base": "block/foodcrate-opened" },
  "attributes": {
    "humanoidTraversalCost": 100,
    "reinforcable": true,
    "partialAttachable": true,
    "inventoryClassName": "crate",
    "defaultType": "normal",
    "types": ["normal"],
    "drop": {
      "normal": true
    },
    "quantitySlots": {
      "normal": 20
    },
    "storageType": {
      "normal": 189
    },
    "retrieveOnly": {
      "normal": false
    },
    "shape": {
      "normal": "block/foodcrate-opened"
    }
  },
  "entityBehaviors": [],
  "creativeinventory": {  },
  "creativeinventoryStacks": [
    {
      "tabs": [ "general", "decorative" ],
      "stacks": [
        { "type": "block", "code": "foodcrateraw" }
      ]
    }
  ],
  "heldTpIdleAnimation": "holdunderarm",
  "shapeInventory": { "base": "block/foodcrate-opened", "rotateY": 0 },
  "shapeByType": { "base": "block/foodcrate-opened", "rotateY": 0 },
  "_comment": "Must declare textures so they get added to the block texture atlas",
  "textures":{
    "blackbronze2": { "base": "game:block/clay/blueclay" }
  },
  "blockmaterial": "Ceramic",
  "replaceable": 1000,
  "resistance": 0.8,
  "lightAbsorption": 0,
  "sideAo": { "all": false },
  "sidesolid": {
    "all": false
  },
  "sideopaque": {
    "all": false
  },
  "combustibleProps": {
    "meltingPoint": 600,
    "meltingDuration": 45,
    "smeltedRatio": 1,
    "smeltingType": "fire",
    "smeltedStack": {
      "type": "block",
      "code": "foodcrate",
      "attributes": { "type": "normal", "lidState": "opened" }
    },
    "requiresContainer": false
  },
  "sounds": {
    "walk": "game:walk/stone",
    "break": "game:block/ceramicplace",
    "hit": "game:block/ceramichit",
    "place": "game:block/ceramicplace"
  },
  "materialDensity": 600,
  "tpHandTransform": {
    "translation": { "x": -1.3, "y": -0.5, "z": -0.7 },
    "rotation": { "x": 0, "y": 90, "z": -102 },
    "scale": 0.44
  },
  "guiTransform": {
    "origin": { "x": 0.5, "y": 0.5, "z": 0.5 },
    "scale": 1.16
  },
  "collisionSelectionBox": { "x1": 0.125, "y1": 0, "z1": 0.125, "x2": 0.875, "y2": 1, "z2": 0.875 }
}

 

[Echo Weaver]

Oh, I actually have an error message. Silly me. I still don't know how the json needs to change, but that's much more useful.

Missing mapping for texture code #normal-blackbronze2 during shape tesselation of block foodcrate:foodcrateraw using shape foodcrate:block/foodcrate-opened, or one of its alternates

ETA: Oh. That did tell me what the problem was. But why did the attribute type get prepended onto the identifier for the texture in the shape file?? That didn't happen with the fired version!

Edited August 31, 2025 by Echo Weaver

[Diff]

3 minutes ago, Echo Weaver said:

Oh, I actually have an error message. Silly me. I still don't know how the json needs to change, but that's much more useful.

Missing mapping for texture code #normal-blackbronze2 during shape tesselation of block foodcrate:foodcrateraw using shape foodcrate:block/foodcrate-opened, or one of its alternates

The way I read this, looks like the error doesn't lie in this JSON, but in foodcrate-opened that this JSON depends on.

[Echo Weaver]

3 minutes ago, Diff said:

The way I read this, looks like the error doesn't lie in this JSON, but in foodcrate-opened that this JSON depends on.

It's the same shape file used by the fired version, though. There's no "normal" in the texture information of the foodcrate-opened shape.

[Echo Weaver]

The biggest lesson here is that I'm not thinking to look in all the right places for my errors. I could've saved myself a few hours of experimentation if I'd found that error earlier.

[Brady_The]

7 hours ago, Echo Weaver said:

Missing mapping for texture code #normal-blackbronze2 during shape tesselation of block foodcrate:foodcrateraw using shape foodcrate:block/foodcrate-opened, or one of its alternates

This might be BlockGenericTypedContainer's doing, generating definitions based on the block attributes. Replace "blackbronze2" with "normal-blackbronze2" and see if that helps.

[Echo Weaver]

1 hour ago, Brady_The said:

This might be BlockGenericTypedContainer's doing, generating definitions based on the block attributes. Replace "blackbronze2" with "normal-blackbronze2" and see if that helps.

That did it. Woot. This thing is finally done.

I hadn't thought about the block class being different. That gives me some context as to why this texture definition behaves differently than the ones elsewhere.