| { | |
| "//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" | |
| } |
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
- there's a setting for default character dimensions
- 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!
The shifting up and down of ResourcePacks to define load order was exactly how we figured you could it :)