-
-
Save Dinnerbone/5662824 to your computer and use it in GitHub Desktop.
| { | |
| "//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" | |
| } |
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!
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.