[1.11.2] Rendering a functional multiblock structure with lots of variants without a TESR

[stross.stephan]

So, as the title says, I'd like to make a multiblock structure, with many variants, that has a central controlling block. This central controller has 25 possible variants. The rendering I want is a tint representing the variant overlayed on a neutral-toned OBJ model, with the emblem of the variant in question pasted on top. I'd also like to not have to instantiate the controller block twice, which is what I'm currently doing, as it feels really clunky, and requires a lot of book-keeping checks in a lot of the methods. I currently have 16 variants in the first instantiation, and 9 in the second. Is it possible to have all 25 variants of one block that all render slightly differently(but with the same parameters of a color and an overlay image), and all have the same item ID, WITHOUT resorting to a TESR? The render itself isn't animated(yet) and isn't particularly complex, and I'd rather not have to resort to a TESR(because I'd rather not deal with GL1.1 code). Oh, and, the block doesn't actually NEED to drop when the thing is mined, so I don't care about the consistency of behavior there, in case I DO still need to deal with the 4 bits of metadata.

 

I asked a similar question around the 1.7.10 modding era, and then college ate a bunch of time, and I had to drop working on it for a while. It wasn't possible then, but I'm wondering if the new IBlockState system can let me do this in a way that's not gross.

And for those interested in the code, all of it is present here

Edited June 3, 2017 by stross.stephan

[stross.stephan]

Nothing?

[stross.stephan]

Okay, so, maybe an easier question, since the first one doesn't seem to be getting any bites...

Is it possible to render a model that is supposed to take up space in multiple blocks using a baked model and json, or do I NEED to use a TESR to do it?

[draganz]

not sure about vanilla, but you could use .obj files, those are very easy to scale

 

[stross.stephan]

I know I COULD. The question I have is whether I SHOULD. Using an obj file means that the other blocks that make up the actual physical structure of the multiblock either do not render (Which I'm thinking would have to be a special block specifically for this circumstance, which is okay, but requires some context-awareness checks in said custom block) or have their rendering obscured by the big model.

I suppose this is more a question of best practices. Should a block model be used to cover multiple blocks, or should it be done with a TESR?

[V0idWa1k3r]

A block model is not supposed to take more than 1 block. It creates issues of all kind. Even Mojang had to go through a lot of inconvinience to make fences working, and that is mostly workarounds. You could use a custom IBakedModel if you do not care about collision boxes. You should just have your block have multiple other blocks surrounding it that act as 'parts of the bigger model'. 

As for your first question - it is a bit difficult to understand what exactly you are trying to achieve but you can use a Block::getExtendedState to have as many states of a block as you want. You will need to store something that dictates the current to-be-chosen state somewhere, most likely in your tileentity.

[stross.stephan]

Okay. Collision boxes DO matter, so, no go on the IBakedModel, unless I give both the core and the structural blocks their IBakedModel, and IBakedModels can be made structurally aware? And I'll look into the getExtendedState function. 

 

Thanks for giving me some places to look! 

[V0idWa1k3r]

IBakedModel is a model you register for a blockstate. You can't really make a model "structurally aware" (well, you can but you shouldn't), but you can make a blockstate aware with getExtendedState. Then you would return a model that corresponds to a structure type that the blockstate dictates.

[Draco18s]

World-stuff slid be done in getActualState. Extended state is for things like fluids, which need to control where each of the four corners are.