[1.9] Can a JSON model have multiple parents?

[HashtagShell]

The title says it all: The question is, whether or not you can have multiple parents for one json model.

 

The exact scenario I am facing is the following:

In my models/block, there is a model file for a block, it defines the texture and sets the parent to be a cube.

Then, in my models/item, I have a file called standard_item.json, which defines all the rendering angles (got it from Bedrockminer's tutorials).

The previously mentioned block also has an ItemBlock, whose json is also in models/item. Its parent is currently models/block/exampleBlock, so that it would inherit its texture. But then I have to define all the item rendering angles in the file. One possibility would be to make standard_item the parent, but the parent still has to ultimately be cube_all, and thus models/block/exampleBlock.

 

What I currently have works. But it is in no way clean, and when I'll want to change the angles, I will have to go through all files. (There's regexp, but that's just covering the issue, not solving it).

 

PS: The captcha is wrong; the question&answer:

  - Q: Are spiders nice during the day?

  - A: They don't care about whether or not it is night, it is the light level that matters.

Didn't get accepted, for some reason one can only imagine

[HashtagShell]

The title says it all: The question is, whether or not you can have multiple parents for one json model.

 

The exact scenario I am facing is the following:

In my models/block, there is a model file for a block, it defines the texture and sets the parent to be a cube.

Then, in my models/item, I have a file called standard_item.json, which defines all the rendering angles (got it from Bedrockminer's tutorials).

The previously mentioned block also has an ItemBlock, whose json is also in models/item. Its parent is currently models/block/exampleBlock, so that it would inherit its texture. But then I have to define all the item rendering angles in the file. One possibility would be to make standard_item the parent, but the parent still has to ultimately be cube_all, and thus models/block/exampleBlock.

 

What I currently have works. But it is in no way clean, and when I'll want to change the angles, I will have to go through all files. (There's regexp, but that's just covering the issue, not solving it).

 

PS: The captcha is wrong; the question&answer:

  - Q: Are spiders nice during the day?

  - A: They don't care about whether or not it is night, it is the light level that matters.

Didn't get accepted, for some reason one can only imagine

[Leviathan143]

Since the Item is an ItemBlock, it doesn't need an item model, it will use the block model if there is no item model. For example

[Leviathan143]

Since the Item is an ItemBlock, it doesn't need an item model, it will use the block model if there is no item model. For example

[jeffryfisher]

I think that "parent" can be set to only one thing. JSON syntax, even with Forge's advanced improvements, is prone to redundancy that grates on programmers (JSONs are crystalizing data for lookup, not making runtime decisions, which is a completely different mindset). Therefore, expect to repeat yourself repeatedly when writing blockstate and model files.

 

BTW, I may be an idiot, but if I had been writing the new (for 1.8 ) system, I would have used a client-side only method that for any block state would have returned a rendering data set (model, texture etc). Then the bakery could have called the method repeatedly during setup, baked all of the results, and nobody would have been the wiser. Forcing coders to elaborate the data, sometimes with Cartesian product output, was moronic. Not only was it tediously voluminous, but text is prone to bugs.

[jeffryfisher]

I think that "parent" can be set to only one thing. JSON syntax, even with Forge's advanced improvements, is prone to redundancy that grates on programmers (JSONs are crystalizing data for lookup, not making runtime decisions, which is a completely different mindset). Therefore, expect to repeat yourself repeatedly when writing blockstate and model files.

 

BTW, I may be an idiot, but if I had been writing the new (for 1.8 ) system, I would have used a client-side only method that for any block state would have returned a rendering data set (model, texture etc). Then the bakery could have called the method repeatedly during setup, baked all of the results, and nobody would have been the wiser. Forcing coders to elaborate the data, sometimes with Cartesian product output, was moronic. Not only was it tediously voluminous, but text is prone to bugs.

[HashtagShell]

I didn't know that ItemBlocks don't need a models/item JSON, that certainly makes the code clearer. However, you would still need to make standard_item the parent to avoid copying entirely, which, based on jeffryfisher's response, isn't possible.

I also think that the JSON system is not very practical, but JSON models are IMO a lot easier to make than obj (thx MrCrayfish with your modeler).

[HashtagShell]

I didn't know that ItemBlocks don't need a models/item JSON, that certainly makes the code clearer. However, you would still need to make standard_item the parent to avoid copying entirely, which, based on jeffryfisher's response, isn't possible.

I also think that the JSON system is not very practical, but JSON models are IMO a lot easier to make than obj (thx MrCrayfish with your modeler).

[Choonster]

In 1.9,

block/block

defines the standard display transformations for block models. This is extended by all full cube models (e.g.

block/cube

and

block/cube_all

).

 

Similarly,

item/generated

extends

builtin/generated

and defines the standard display transformations for simple item models.

 

You only need to define display transformations yourself when your model has a custom shape or you want it to be displayed differently to normal models.

[Choonster]

In 1.9,

block/block

defines the standard display transformations for block models. This is extended by all full cube models (e.g.

block/cube

and

block/cube_all

).

 

Similarly,

item/generated

extends

builtin/generated

and defines the standard display transformations for simple item models.

 

You only need to define display transformations yourself when your model has a custom shape or you want it to be displayed differently to normal models.