Jump to content

Recommended Posts

Posted

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.

Posted

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? 

Posted (edited)

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 :D

Edited by BenignBanana
Posted

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?

Posted (edited)

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 by Jay Avery

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Announcements



×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.