Jump to content

[1.9] Can a JSON model have multiple parents?


HashtagShell

Recommended Posts

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

The debugger is a powerful and necessary tool in any IDE, so learn how to use it. You'll be able to tell us more and get better help here if you investigate your runtime problems in the debugger before posting.

Link to comment
Share on other sites

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.

The debugger is a powerful and necessary tool in any IDE, so learn how to use it. You'll be able to tell us more and get better help here if you investigate your runtime problems in the debugger before posting.

Link to comment
Share on other sites

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).

Link to comment
Share on other sites

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).

Link to comment
Share on other sites

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.

Please don't PM me to ask for help. Asking your question in a public thread preserves it for people who are having the same problem in the future.

Link to comment
Share on other sites

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.

Please don't PM me to ask for help. Asking your question in a public thread preserves it for people who are having the same problem in the future.

Link to comment
Share on other sites

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.