In-Code Json Creation

[ComputerCraze]

In my mod that I am currently working on, I have a numerous amount of identical blocks which you can texture using a texture pack. However hard coding all of these would be painful at best so I was thinking of looping over a piece of code that would create all of the jsons. How would I go about it?

[ComputerCraze]

Thank you! Now I don't have to have 150 separate JSON files for each of my 50 blocks. One more question though, and that's about how I would add the JSON file from my for loop in my java class?

 

Thank you,

ComputerCraze

[ComputerCraze]

Right, but is there a more efficient way of typing in the code for 50 blocks in the JSON file?

[ComputerCraze]

Ok then, thanks. Sorry I've been a bit stubborn, but just to make sure:

 

Could you loop over something in one of your classes that will create all of the variants in the JSON file without typing all of that in? I'm not really looking for compact code, although that would be nice, but I'm looking for something that will create that code right there on startup.

[ComputerCraze]

I don't really understand why a resource pack would come into play here. Let me explain thoroughly:

 

My mod is something that adds a set amount of blocks (50 as default) that are exactly identical to each other except the texture they use. When the game first boots up, these blocks are generated and added into the game using a for loop. What I want to do is create the model files for these blocks inside the code in that same for loop, so that the user can use a texture pack to retexture them as they please.

 

Basically I want to code something that goes into the for loop of my code and generates the JSON files at the same time as the blocks. All I need is the piece of code specifying where the file needs to be written to.

[ComputerCraze]

Okay, hopefully this will help:

 for(i=0;i<50;i++){
String json = "blah blah mymod:blocks/dummyblock1 blah blah"; //text for the jsons, the file names for the textures, models and blocknames are incremented
//add code for adding json
} 

 

If you're asking why, as in why would I want this feature in my mod, it's supposed to be more of a utility mod for mapmakers.

 

If you're asking why, as in it would make no difference whether you put it in there or not, although I might be new to programming Minecraft mods, you do need a JSON and only a JSON to specify the attributes of how the block or item is rendered, correct? So if I want all of the attributes of my 50 blocks to be the same, except for the texture, I would either have to have tons of variants of that single block or add three separate JSON files for each block, correct? So therefore I would just need to loop over a line of code that adds the JSON files for every single block on bootup as an alternative to typing out the code for all 50 of the blocks.

 

If this doesn't make sense, I'm really sorry, but I'm trying to explain this the best I can. Hopefully you'll understand now.

[LexManos]

Do not create the json or dynamic blocks from code.

You can create the data externally once and then ship it out.

Creating models/textures/jsons with code is bad.

[ComputerCraze]

  On 5/14/2016 at 9:12 PM, LexManos said:

You can create the data externally once and then ship it out.

 

This seems more like what I am looking for, however, could you explain the process?

[Draco18s]

  On 5/14/2016 at 9:12 PM, LexManos said:

Do not create the json or dynamic blocks from code.

You can create the data externally once and then ship it out.

 

Question, as I have a 1.7.10 mod that creates blocks at runtime.

 

The reason is that it's actually generating replacement blocks for an uncertain number of blocks, some of which may exist (as they are mod blocks) or may not.  The reason being that I create BlockFalling types for them and give them several runtime generated textures (as in, I have a custom TextureAtlastSprite that takes the original texture and pre-renders an overlay onto it for several variants).

 

For vanilla, it's no problem to handle this once, externally, and ship it.  But due to there being other mods that also ship blocks that I'd want to replace (and due to the overlay nature of the texturing) I did this programmatically and it even handles variant resource packs.  I even supply an API hook for someone to write a plugin that would register additional types.

 

When I do get around to updating to 1.9, how should this be handled instead?  Pre-packaged data?

 

(My number of blocks is small, vanilla would be 3 with another 3-6 from mods, so it's not an undo amount of work to generate the data externally, I'm just trying to understand the advertised method).

[LexManos]

Prepackage the data, and in all honesty what you've described doesnt need to do anything special or replace blocks, just listen for block change events and create falling entities.

'Dynamic' mods/block are a BAD IDEA. Do not do them.

[Draco18s]

You misunderstand my use-case.  I'm replacing stone.  All of it.  Every single block the world as it is generated.

 

And I don't want to merely create falling entities, I am trying to provide a custom level of physics support.  Each block needs to determine whether or not it has support and not just from below.  Hence a custom block class is required.  Which includes 4 variants, each with their own rules for falling and unique texture.  BlockChangeEvent is insufficient.

 

However there are multiple kinds of stone.  Vanilla (gray) stone, basalt, granite, marble, diorite...

 

That's why I asked.  I'm interested in learning the better way.  The reason I went with code-generated textures was three fold:

(Note: this was done prior to 1.8 being supported by Forge, these were the reasons at the time)

1) providing pre-packaged textures does not allow for popular resource packs without explicit support (if a pack changes the texture of vanilla stone, my mod would be unable to utilize it).

2) using a custom model utilizing two render passes resulted in problems with rendering (falling entities and particles would only render the overlay texture, etc.)

3) manually combining an overlay with the base texture was time consuming (I did it with my ores and I regret it; 11 supported ores with 16 metadata texture variants: 176 hand-created textures with no resource pack support).

 

All you have said is "they are bad, don't do them" and I am trying to understand why.  I am trying to learn, so please be informative.

[LexManos]

That is called layers, you can use normal textures layered on top of each other just fine. No need for custom generated code.

It would work JUST FINE with resource packs.

As for the physics shit, you can do the substitution system we have in the registry to take control. And leave it as is.

Generating context, be it blocks, items, textures, whatever is bad because it 1) breaks the data driven design that we at forge, and mojang are trying to do

2) It breaks a lot of functionality when it comes to external modification for resource pack makers, server owners, etc..

3) It makes life hell when trying to manage data and keep worlds/servers clean and synced up

4) It opens up a PLETHORA of potential security issues depending on the routes which you go.

5) It screws with the caching and performance of the re-written rendering pipeline causing major downgrades to end user's experiences.

 

There are A LOT of issues with doing dynamic content like that.

 

If you run into issues, then you can get them addressed. 1) Fixed with multilayer models 2) Fixed with some re-working of the entities nothing hard just needs to be brought it properly. 3) Should never need to be done.

 

[Draco18s]

  On 5/15/2016 at 6:10 AM, LexManos said:

3) Should never need to be done.

 

Technically speaking, 3 was fixed by:

 

  Quote

That is called layers, you can use normal textures layered on top of each other just fine. No need for custom generated code.

 

That's why I said "these were the reasons behind the decision in 1.7.10."  1.7.10 did not have a concept of layers.  I understand that those issues have been addressed.  Same goes for the particles.

 

Thank you for explaining why dynamic blocks are a bad idea.  I was completely unaware of those problems because you do a terrible job of advertising "doing it this way leads to a better experience, not doing it breaks fucking everything."  Instead people try their best to figure out how to get the effect they want, get something half-working and you come along and go "don't do that."

 

  Quote

As for the physics shit, you can do the substitution system we have in the registry to take control. And leave it as is.

 

Interestingly, said system doesn't actually work as of the most recent information I've seen.  Questionable as to whether or not it works in 1.7.10 perfectly as well.  That is: no one has been able to figure out how to get it to work, even hoped you (or anyone, really) would come along and post a working example, and it's lingered without a reply.