Multiple pipes same volume like extra utilities 2

[matthew123]

I want to make my transfer nodes be able to occupy the same block volume, just like extra utilities 2 did in 1.12. The nodes also use tile entities to search and register themselves into the pipe network, and to store data and animate.

 

I am using 1.18.

[Alpvax]

You need to have a single block which can render any combination of "parts" on each side. I would suggest using a multipart model and using the modelData to decide which parts to render.

 

I have some code I used before here, using a custom model but I was experimenting at the time, and the code is very messy.   Edit: removed link to old, confusing code

In essence, I had an enum for which part was on a face, and a model for each part, which I then combined with a rotation based on each face to produce the correct result. You might need a custom baked model, as I had (with custom loader I believe is necessary, but I can't really remember), or you might be able to use the standard multipart model.

In my BlockEntity I had the following:

private final Map<Direction, ConnectionState> connections = Util.make(Maps.newEnumMap(Direction.class), (map) -> {
    for (Direction d : Direction.values()) {
        map.put(d, ConnectionState.NONE);
    }
});
  
@Nonnull
@Override
public IModelData getModelData() {
    ModelDataMap.Builder b = new ModelDataMap.Builder();
    connections.forEach((d, s) -> b.withInitial(BakedWireModel.DIRECTION_DATA.get(d), s.getString()));
    return b.build();
}

Unfortunately I don't know how much of the above has changed. (That was originally made for early 1.16.)

Edited March 1, 2022 by Alpvax
removed link to old, confusing code

[Luis_ST]

29 minutes ago, Alpvax said:

You need to have a single block which can render any combination of "parts" on each side. I would suggest using a multipart model and using the modelData to decide which parts to render.

there is the PipeBlock, for that case

[Alpvax]

PipeBlock uses blockstates to save the sides, and as a result can only have "connected" or "not connected" variants (it's the base for the chorus plant blocks).

It doesn't help with having multiple parts possible for each side as well as "not connected" (for example my wire was initially 3 possibilities per side = 3⁶ = 729 states). For that you would need to have a dynamic model and use the modelData from the BlockEntity.