Hey everyone,

 

I was trying to implement connected models for a multiblock structure I'm adding using the BlockStates JSON. It looks quite nice and is simple enough, but the facing (2 bits) plus the multiblock part enum (6 values/3 bits) is just one bit too much for the block meta.

Is there any way to supply state information to the BlockStates system other than metadata? Here's the JSON for reference: 

{
  "forge_marker": 1,
  "variants": {
    "normal": [
      {}
    ],
    "inventory": [
      {}
    ],
    "mb_part": {
      "single": {
        "model": "kaidencraft:boiler/single.obj"
      },
      "end": {
        "model": "kaidencraft:boiler/end.obj"
      },
      "corner": {
        "model": "kaidencraft:boiler/corner.obj"
      },
      "edge": {
        "model": "kaidencraft:boiler/edge.obj"
      },
      "center": {
        "model": "kaidencraft:boiler/edge.obj"
      }
    },
    "facing": {
      "north": {},
      "south": {
        "y": 180
      },
      "west": {
        "y": 270
      },
      "east": {
        "y": 90
      }
    }
  },
  "defaults": {
    "textures": {
      "#initialShadingGroup": "kaidencraft:texture"
    }
  }
}

 

I don't have part 6 (hidden) in there since this one is single layered. I'd appreciate any input, I know I can handle this with custom renderers but as you can see the BlockState way is quite nice so I'd prefer that.

You will need to use getActualState, which allows you to apply properties that don't fit in the metadata (but that won't be stored). Those properties must either be possible to calculate based on surrounding blocks (like a vanilla fence, which calculates its shape from the blocks adjacent to it), or be stored in a tileentity which you get the data from. Does your multipart block have a tileentity? 

Yes it does, but I'll take a look at the vanilla fence to see how that's handled. If I need any more help I'll just post again. To be honest I completely forgot vanilla changes blocks based on neighbors too

Edited June 29, 20178 yr by BenignBanana

Hmm, so after looking at fences (and glass panes since they behave a bit differently) I'm not sure I can use that system. Is there any way to check for multiple sides at once in that? Even then the JSON would become quite verbose if I have to check all 18 possible configurations. Any ideas on how to do this more elegantly?

I'm not sure what you mean. You won't need to add any new properties to your blockstates file, you just need to figure out how (if it's possible) to calculate the correct part for a given block by checking the states of its neighbours. Note that you can't check a neighbour's part, because that would require calling getActualState and create an infinite loop. If your block already has a tileentity, it's most likely easiest to simply have a part field in the tileentity which you can then access in getActualState.

Edited June 29, 20178 yr by Jay Avery

I see now, I was mistaking the actual state with the extended state, which can only be used through TileEntities. This seems like exactly what I need. Thanks for the help