As an essential step towards the Minecraft modding API, and also for sanity's sake in our own code, we're removing Texture Packs and replacing them with a new Resource Pack system. Ultimately, every mod/plugin will be its own resource pack, vanilla will be a resource pack by itself, and users will be able to apply multiple resource packs at once…

gistfile1.json

{
    "//comment": "All metainfo files will be ORIGINAL_FILE.mcmeta. For example, textures/blocks/portal.png.mcmeta. The format is, of course, JSON.",
    "animation": {
        "//comment": "This block will be required for animated textures. It can be an empty block, but it will be needed to detect an animation.",
        "frames": [
            1,
            {"index": 2, "time": 4},
            3,
            4
        ],
        "frametime": 2,
        "width": 2,
        "height": 5
    },
    "texture": {
        "//comment": "This block can go on any texture and it'll control how that is rendered out. Not yet implemented as of time of writing.",
        "blur": true,
        "clamp": false
    },
    "font": {
        "//comment": "Font files will have all their data serialized out so that we don't break the font trying to figure everything out ourselves. Not yet implemented as of time of writing.",
        "characters": {
            "default": {
                "spacing": 0.1,
                "left": 0.2,
                "width": 0.3
            },
            "0": {
                "spacing": 0.2,
                "left": 0.3
            },
            "1": {
                "spacing": 0.3,
                "width": 0.3
            },
            "2": {
                "spacing": 0.5,
                "left": 0.1,
                "width": 0.2
            }
        }
    },
    "pack": {
        "//comment": "This will be in your pack.png.mcmeta. It replaces pack.txt, and will contain more info in the future. Not yet implemented as of time of writing.",
        "description": "hello world!",
        "pack_format": 1
    },
    "//short_term_todo": "Sound registration, language registration"
}

Nice! Love that change (:

Loving that! But what about including some options for pulling updated resource packs?

Instead of using JSON, why not use TOML. It supports comments and is a lot easier for non-programmers to write.

https://github.com/mojombo/toml

I love Mod API development guys! :D

How would one add a new resource pack, simply place the files in the /resource folder or similar?

Well, directly from Toml's Github page:

Latest tagged version: v0.1.0.
Be warned, this spec is still changing a lot. Until it's marked as 1.0, you should assume that it is unstable and act accordingly.

Do you really think that building something that big with an unstable language is a good idea?

I don't.

@iand, "Data types [in Arrays] may not be mixed" doesn't sound too good for the animation frames above...

This is great to hear!

Instead of using JSON, why not use TOML. It supports comments and is a lot easier for non-programmers to write.
https://github.com/mojombo/toml

Or CSON, which is coffeescript-syntaxed JSON
i.e. it supports regular JSON, but also supports a syntax not unlike YAML
and you can mix them too

or just use YAML, since that's what many people are used to, now, thanks to bukkit.

I have a question for @Dinnerbone, that is why would people already using a java interface want to switch to a format they have no intention of learning? the ModAPI should be in a java interface, as that is the easiest and most efficient way of making the API

@ShadowChild, JSON is a format for representing data. It can be used in Java. Java is not a format for representing data. You couldn't use write the metadata file in "Java" format

Are all vanilla blocks going to be metadata blocks ie 16 blocks in 1 ID or are you adding a massive metadata system similar to redpower which supports several thousand blocks under 1 id? Or has this got nothing to do with block metadata ;)

This has nothing to do with the world block format.

I don't know if I understand this correctly right now, but if I do I think this is a great step in the right direction :D

So you are using a json instead of nbt? What blasphemy is this? ;-)

That TOML format looks familiar... Oh yeah! Windows 3.1 INI files. LOL. I'm not a big fan of JSON either, but as long as it's a well-established standard, it shouldn't really matter.

@Dinnerbone: A few questions:

• Will it be possible to have a map as part of a resource pack? Like a resource pack for a map, including the map specific texturepack (and/or mods)?
• Will these resource packs have some sort of versioning and dependency system from the start? Or will that come later? Or not at all?
• Could shaders at some point become a resource?
• Many texturepacks have addons for different mods. How would that be realized with this system? Would the resource pack for the mod or the texturepack contain the mod specific textures? Or would it be a seperate resource pack?

This looks great so far!

Please keep in mind that ResourcePacks are just 'extensive texturepacks' (you can just do more with them, in theory replace 'all' resources. They are not plugins, they will eventually be used to access resources for plugins.

@02JanDal

• Will it be possible to have a map as part of a resource pack? Like a resource pack for a map, including the map specific texturepack (and/or mods)?

  • I'm assuming you are referring to a world/save/level not the ingame item? If the former, we have no plans for that right now.
• Will these resource packs have some sort of versioning and dependency system from the start? Or will that come later? Or not at all?
  • ResourcePacks will have no dependencies (would be strange, you could merge them then?). Versioning might be useful but there won't be anything enforced from our side.
• Could shaders at some point become a resource?
  • Shaders are resources, so yes.
• Many texturepacks have addons for different mods. How would that be realized with this system? Would the resource pack for the mod or the texturepack contain the mod specific textures? Or would it be a seperate resource pack?
  • A ResourcePack can contain resources for multiple namespaces, the default one will be 'minecraft', assuming mods will use this system (Forge is planning this already) they should be able to provide for their own namespaces as well. This is simply done through folder structure, assets/$namespace/files

This looks awesome.

Will multiplayer servers still be able to download Resource Packs to the clients? And will there be any hopes of individual textures for each arm and leg in the next update? (or whatever update this is for, I'm guessing it's the next one.)

As for versioning, I think it would be useful to have the option to include a version inside Resource Packs to warn players that they might need an update (similar to the multiplayer screen's response to old servers, just not restricting access). Nevertheless, I'm very excited to see what modders as well as myself will be able to do with this system. :D

This looks exciting! @Dinnerbone, I'm not totally clear on what pack.png.mcmeta refers to, but on the off chance it's the proposed name of this JSON file, can we pretty please use .json instead of inventing new file extensions? 👍 Thanks for the sneak peak!

"...users will be able to apply multiple resource packs at once..."

Errr...and what happens if two resource packs changes the same resource? (for example, the cobblestone block texture). Which one does it load?

I would have also preferred YAML (which supports comments, LOL) over JSON, but close enough I guess.

@shinyquagsire23: Most likely for the downloading. Not sure how we'd do versioning, there is nothing to compare the version with so we'll have to see.
@raws: if we name it .json there is no easy way to make a custom syntax file for it that understand the different structures.
@Dovakhan: The one you've selected to be loaded last will get preference.
@CodeOmar: YAML has lots of user-issues with whitespace as Bukkit has shown over the years :)

@grum, and here I thought that I'd never have any more load order issues when I stopped playing (modded) Skyrim...lol

I hope that at least it'll be easy to edit the load order, or at least to switch up/down the resource packs...

The shifting up and down of ResourcePacks to define load order was exactly how we figured you could it :)

lol, I kinda feel honored that I had the same idea as the devs :D HIRE ME NOW!! (j/k :) ).

Totally use the TOML. That sounds amazing. The resource packs are a good idea. I bet PCLewis will make a tool to convert texture packs not updated to the resource packs to resource packs. They would have to have the new texture pack format thought. Backwards compatibility would be great too!

@grum: Perhaps, but now there will inevitably be problems with missing/stray opening/closing braces and square brackets. A decent text editor will solve both those issues, but people who use notepad.exe will have problems regardless. With JSON, probably less problems initially when they are mostly just swapping out values, but the day someone accidentally deletes a '}', I only hope the error message is more useful than GCC's.

@grum So a resource can be textures, fonts and shaders?
Will there be a way to specify new shaders without mods in the future?

@CodeOmar: GSON gives nice exceptions on parse-errors. We just have to make sure to catch them at the right places.

For example: com.google.gson.stream.MalformedJsonException: Expected name at line 4 column 5

@128keaton: We're sticking with JSON sorry! :D

@02JanDal: Eventually, yes.

@grum Will this change the way sounds are handled for walking on blocks or other entities? possibly a combination of sound/texture packs for the new resource pack system?

@bhsgoclub: There will be a sound event -> file registration system. It's just not documented yet because we haven't got that far ;)

@grum: Good to hear. I used to dread coding in languages that required braces because the parsers would emit pretty useless error messages when you forgot a closing brace somewhere—which used to be all the time! Now we have wonderful things such as auto-brackets and syntax awareness, but it's good to know that the notepad people will not be completely helpless.

How will it handle multiple ResourcePacks changing the same resource?
Who will win?

@hvdklauw: like statted above, it will be the last one that will win.

Will the new resource pack system allow a mod to supply textures in multiple resolutions?
Could there be the possibility for the user to determine the desired texture size.
Would it be possible for textures for higher than 16x be defined for "vanilla" in the base resources.

I think this would be awesome and make life easier for mod/texture makers.

I have mod "Wigit" that defines textures for 64x and 32x.
Mods load and user has selected 128x.
Mods that have 128x textures will load their 128x textures.
When Wigit loads it loads my 64x because there is not a 128x texture, or optionally load the "vanilla" 128x.

Now lets say my Artist friend decides to make new textures for 256x 128x and 64x for Wigit (and other stuff).
When I load his resource second his textures will load for 256x,128x,64x and mine will load for 32x and vanilla for 16x.
When I load his first his textures will load for 256x,128x and mine will load for 32x,64x and vanilla for 16x.

Am I on the right track or am I completely missing the point of this change.

This is a far better use of JSON than the new chat thing. I like it.

Will it be possible for a mod to enumerate all resources in a namespace?
If two or more packs alter the same resource, will there be a way to access both?

I certainly appreciate all the work you have been putting into the modding API, and Minecraft, in general, @grum and @dinnerbone, but I must express my concerns about the lack of a dependency check for the resource packs. You've already mentioned that the load order of the resource packs could be modified by the end user. I have to assume then, that you already have (or have planned out) a system that keeps track of that. Would it not be as simple as adding something along the lines of a 'requires' block to the pack block, so that it ensures that the required resource packs are loaded before the resource pack in question? Something like the following, perhaps?

{
    ...
    "requires": [
        "X",
        "Y",
        "Z"
    ]
}

Where X, Y, and Z are something simple, such as the names of the resource packs that must be loaded before this resource can be loaded, or something a little more complex, such as a unique ID assigned to the resource packs that are required. The second has the obvious benefit of less developer work up front, as any time a resource pack it depends on changes its name, or any other aspect of itself, its ID will stay the same, so the developer doesn't have to launch a new version of their resource pack to account for that. This also means no downtime for the end user.

Additionally, the screen that comes up when you first open Minecraft, that loads all of it's resources, and updates them, if necessary: will a resource pack developer be able to allow their resource pack to be updated during this phase of Minecraft's initialization, or will the end user have to update the resource packs themselves.

And finally, is there going to be any version check that occurs between the resource pack that's being loaded and the version of Minecraft the end user is running? Nix that. I'm a dumb who can't read, apparently.

I hope I didn't ask too many questions. I'm just a curious individual.

Well... i have no idea what this means

@clue1001 Unless you're a developer, this doesn't mean much of anything. To a developer, this means pretty much everything. This file is how new blocks will be defined, how new mobs will be defined, and much more. In a nutshell, this file is the most basic building block of how Minecraft is developed.

So, can I develop my texture pack for 1.5.2? I mean, I don't want it to be broken in 1.6, will it be easy to upgrade to 1.6 system?

Based on the gist's description, I would say yes, @ZadyOne. They said they will write another unstitcher for texture packs, just like the texture pack unstitcher that was written for the 1.5 (1.4?) update.

Will you be able to keep jars as resources in the pack to play on old servers???, how would put a mod into a resource pack and will this change how you install mods ?

mmm... Writing out fonts for languages like Japanese (with thousands of characters) would really suck with this...

How do you download?

@ChoobCoolMan what do you mean?

@NicholasRoge Actually, this format is specifically for the resources used by Minecraft and in the future, mods for Minecraft. This format defines things like textures and sounds, but not the actual mods themselves. So if, for example, the Sphax people moved beyond just redefining textures, they could also replace the sounds in mods using this format (once supported by the modders). It has nothing to do with defining new blocks or mobs.

@moncader the good news is

1. there's a setting for default character dimensions
2. Japanese doesn't have different character widths

if anything, Japanese fonts would be easier to specify than Roman.

@everybody else suggesting YAML, TOML, CSON, whatever

If you really hate writing JSON, write a build script that compiles your format-of-choice to JSON. My texture pack has had a Rakefile from the beginning. I assume if you guys are well versed enough to complain about data serialisation formats you should be able to write a trivial script in your language of choice to do the conversion.

Having a build script is also nice because you can have textures that go together (different sides of TNT, beds, &c.) in a texture atlas that you can edit together and split up at build time. It's also nice for stuff like compositing ores onto your stone texture or what have you.

@erisdiscord I don't think anyone nearly cares that much about it. It's like the indentation wars: everyone has their own preference, but at the end of the day, reasonable people don't complain about adhering to a particular standard. While converting one to another in a build script would be extremely trivial, it's probably not even worth doing.

Most people will be familiar with JSON due the resource packs and other parts of the minecraft client standardizing on it; other formats, not so much. Not everyone who may want to contribute to your mod will know how to code. If your build script uses anything other than JSON, it's just one more thing they will have to learn.

Unless I'm mistaken, @smbarbour, block definitions are considered resources. I understand that this doesn't define the mods. A resource pack will, at its core, be a collection of these files, giving the game a definition of 'what' the resource is. It's up to the modder to define the interaction between the player and that resource in another file, be it in a java class file or something similar.

I am having trouble animating the title image for the main menu (minecraft.png). I have successfully made a resource pack and have resized the original "textures/gui/minecraft.png" from 256x256 to 256x1536 (1536 / 256 = 6 frames). I have made a "textures/gui/minecraft.png.mcmeta" in the same directory as the .png and wrote in the "animation"{..} block. I have checked for syntax errors everywhere. The "width", "height" and "frametime" fields have also been specified. The frame array is specified like so:

"frames": [
0,
1,
2,
3,
4,
5,
4,
3,
2,
1
]

Where have I gone wrong? I used Notepad++ to edit the JSON. The result is the image showing up stuck between two of the frames. No change is observed as the frames are supposed to change.

--Bottom line--
1.6.1 pre: Unable to animate GUI image "minecraft.png" using new JSON format through "minecraft.png.mcmeta".

@Dinnerbone @grum I have to do to change my texture pack to a resource bundle?
my twitter is @dubstepgamer77

I can't begin to explain how pumped I am for the mod api and being able to have simple methods for players to connect to things like a tekkit server without conplicating the lives of average players.

WHOOOOOOOO!