Posted May 26, 20169 yr 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
May 26, 20169 yr Author 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
May 26, 20169 yr 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
May 26, 20169 yr 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
May 26, 20169 yr 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.
May 26, 20169 yr 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.
May 27, 20169 yr Author 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).
May 27, 20169 yr Author 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).
May 27, 20169 yr 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.
May 27, 20169 yr 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.
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.