[1.12.2] Adding Resources at runtime

[TheJays]

Hi All,

Was hoping to get a bit of help here. Or to know if what i want to do is even possible (which i'm sure it must be).

 

is it at all possible to create mod resources at run-time; that is to say create the blockstate / models / textures at launch. 

 

These will all be based off templates. 

 

From what i gather (looking at ForgeDocs) i will need to create a new ResourceLocation? 

I'm a bit stuck in how I should go about doing this.

Thanks in advanced. 

 

- Jay

 

[Cadiboo]

What do you want to use these resources for?

Its completely possible to autogenerate your resources using gradle it in your development workspace, but you would never want to do it in production

Edited June 25, 2019 by Cadiboo

[TheJays]

I have been working on a mod for mod-pack developers. See here 

 

The idea is to supply the mod a payload (currently json, eventually zip). And the Block & Items will be added at runtime.

 

The blocks & Items added are just basic ones. mainly used in crafting recipes or decoration. 

I have the bulk of it working. its just adding the resources that I'm struggling with. 

 

Thanks for taking the time to reply ?

Edited June 26, 2019 by TheJays

[TheJays]

31 minutes ago, Cadiboo said:

Its completely possible to autogenerate your resources using gradle it in your development workspace, but you would never want to do it in production

Is this an implication that it is not possible to do while forge is loading? 

 

Thanks ?

[Cadiboo]

You’re able to go around the JSON system and directly baked models etc. but the entire point of the JSON system is to make everything accessible to and modifiable by end-users. I think that your users make the jsons themselves would be the best choice. 

[TheJays]

Well see.. That was the route i was starting to take; the end user would just supply a resource pack.

 

However (unless I'm doing something else wrong) Upon loading the resource pack the lang entries work, but models & textures do not. 

 

I  cant see if Forge needs to at least initiate some resources before adding a resource pack.  

[Cadiboo]

Every mod is it’s own resource pack and data pack

[TheJays]

Sorry I should have been clearer. 

I was referring to adding a resourcepack.zip to the games ./resourcepacks folder. 

Doing this has resolved my issue. ( i mush have made an error with the pack format)

I just need to find out how to apply a pack by default now. 

Thanks ?

[Cadiboo]

I highly recommend not doing what you’re doing.

[TheJays]

Why is that? 

I feel its a good idea for those who just want to add blocks and items. And don't want or know how to create an entire mod to add them.

 

The Mod is actually working great now, and doesn't add much to the launch time after the first launch (providing the user doesn't add/change files)

[Cadiboo]

I'm not against having blocks + items load from JSON, I think that its a great idea and I've been planning on doing something like it that would also allow the blocks/items to be added when the player joins a server. I'm against mods creating json files in production. These files defeat the purpose of the JSON system altogether and do not allow resource packs/data packs from users/modpack makers to change enhance the look of the blocks.

[TheJays]

I'm all about choice, and I completely agree that taking away control from the user is always a bad idea. but i have to stress that my mod wont do everything. and still allows the users to add their own textures etc.

Take a look at the mod its self - https://github.com/TheJaysH/BiarMod

 

It currently it has 2 options in terms of adding the blocks & Items.

1) supply it a zip with the json payload, and textures
2) just supply the json.

The first option will create the ResoricePack.zip from the textures the users supplied - and apply it.
The second will just add the blocks & Items, which leaves the Resources down to the user.

the json is as follows:
 

{
  "TABS": [
    {
      "langName" : "Example Tab",
      "unlocalizedName" : "tabExample",
      "icon" : ""
    }
  ],
  "BLOCKS": [
    {
      "langName" : "Example Block",
      "unlocalizedName": "exampleBlock",
      "registryName" : "example_block",
      "tabIndex" : 0,
      "hardness" : 1.5,
      "soundType" : "STONE",
      "material" : "ROCK"
    }
  ],
  "ITEMS": [
    {
      "langName" : "Example Item",
      "unlocalizedName": "exampleItem",
      "registryName" : "example_item",
      "tabIndex" : 0,
      "maxStackSize" : 16
    }
  ]

 

And this is the Zip file structure (should they choose to use it)

`biar.json` is the aforementioned json file
 

.minecraft/
    |
    |__ biarmod/
        |
        |__ biarmod.zip
            |
            |__biar.json
            |
            |__textures/
                |
                |__items/
                |   |
                |   |__example_item.png
                |
                |__blocks/
                    |
                    |__ example_block.png

 

 

The idea of option 1 is a one size fits all solution for mod pack developers who just want blocks & items with one texture who may not have the know-how to create a full ResourcePack.zip

And my vision down the line, is to have a comunity repo for "block-packs" or "item-packs" so users can download a set of blocks and items made by the community. 

 

The main push for this idea came from a modpack developer i know who wanted me to add a bunch of items to the pack - they were just used for crafting recipes and noting more. That gave me the idea to create this. 

[Cadiboo]

Looks pretty good.

I would change a couple things - the registry name & unlocalised name should be the same and it looks like you’re only providing English translations.

[TheJays]

currently im only working with English. 

 

Lang will soon be its own node with different entries like so:

 

{
  "lang": {
    "en_us" : "The Blah",
    "br_fr" : "Lé Bláh"
    ...
  }
}

 

 

As for the naming convention; i was considering  having only one name.. however i'd prefer to stick to the convention of snake_case for registry and camelCase for unlocalised

[TheJays]

9 hours ago, Cadiboo said:

Looks pretty good.

And thank you.

I work in Devops so automation is what i do... been having fun with this. ?

[Cadiboo]

15 hours ago, TheJays said:

however i'd prefer to stick to the convention of snake_case for registry and camelCase for unlocalised

Unlocalised names/translation keys were made the same as registry names in 1.13.

[TheJays]

8 hours ago, Cadiboo said:

Unlocalised names/translation keys were made the same as registry names in 1.13.

Well gosh... It's been a while hasnt it. So everything camel case now then?

 

[Cadiboo]

Er no, snake case. It’s done automatically - setUnlocalisedName/setTranslationKey no longer exists