I also understand that what you're saying roughly amount to awesomeness in a purified and refined form.
That is the most wonderful thing I've seen in a long time GO MINECRAFT! BRILLIANT IDEA!!!!
Rollback Post to RevisionRollBack
Define Cute (choose 1): A) Creepers Aerbunnies C) Herobrine. If you chose A): You appeal to destruction and to stereotypes. If you chose B): You are a perfectly normal person, and enjoy the Aether Mod. If you chose C): Please leave the planet now before you set off a nuclear warhead--no one enjoys mass murders, however nice they might seem to you.
Additionally, changing the load order of the pack is as easy as click-dragging the pack up or down the list. The higher on the list the mod is, the higher the priority of that pack, in cases where packs have conflicting modifications.
Does this mean that resource packs will be able to modify the game? Or are they referring to modifying the textures? Either way, this is awesome! 1.7 is going to be an amazing update!
I'm going to explain the priority thing to people that don't understand. Example: I use the TouhouCraft ressource pack, it modify all the blocks and items, but only modify like 4 mobs. Then I just have to put a texture pack that have all the texture changed, but in a lower priority. It will only modify texture that TouhouCraft don't change, like mobs textures. Pack with lower priority can be seen as ''filler'' for other pack that miss some texture/sound.
yep this would be only good for strict roleplay servers and minigame servers where you have to use a certain resourcepack to understand the game...
well resourcepacks are modifications....but i don't think they are talking about actual mods...^^
I think what he meant was that these resource pack updates are experiments to help mojang get a clear vision of how they should develop the mod API, in which they are now testing the load order concept.
I get it, and it seems handy-dandy and cool and all, but I can't find a use for it :/ (Maybe because I only use the default Minecraft Resource Pack)
I mean, who needs 2 resource packs at once? (Well, I guess Dinnerbone, but...)
I mean, it isn't that hard to drag and drop separate resource pack files into one... unless you're new and don't know how things work, of course.
^ I mean, I do this all the time... and not just resource packs.
Would love to know when Mojang is going add checkboxes next to the resource packs for selection purposes. I am sure I am not the only one frustrated about having to click so many times for MC to register that you are selecting a different pack.
I think some RP creators will like this because many only make specific things but have to include all the other textures so that it is usable. Now, they can just alter the ones they want and leave the rest.
For example, I prefer the default pack, but I do like having a more realistic sun/moon and if I could even get a cool set of night sky stars in there by simply dragging the pack in, that would be awesome!
Back when we still used the terain.jpg that was true, but now packs don't need to include any files that aren't modified (Aside from a txt so MC will see it as a pack), any missing files get replaced by the default automatically.
I fear some server owners would force you to play 16x16 texture packs just because they want to disallow xray packs. Those who would use xray packs would also use cracked clients, almost only legit players would be affected.
For e.g. adventure servers or themed servers, I agree.
Very good point but I still would like the option of forced texture packs just because some younger players don't understand how resource packs work and some servers have themes. I am mostly talking about things like adventure maps. In some of those not using the server side textures would ruin the experience. A good example is a Disney theme park in this server paintings could be re-purposed to be park maps, or furnaces could look like T.V.s.
I hope that Mojang would also eventually release a black out option so admins can put blocks in a list and say if the texture has any transparency black them out so X-ray can not be used. What really needs to happen is admins need to get more options so depending on the type of server the admins can make improvements to reflect on the type of server they host. For any good admin that is the whole point of being a admin.
This is fantastic! I'm making a Star Wars texture pack. With this new system, I can make an upgrade that changes all the mob skins without having to change all the textures and sounds. So, people can load my textures and then load "Cantina texture pack" which replaces all the villager skins to be Cantina creatures. And later, if I come out with a Hoth texture pack, I don't have to redo all the block textures because they will all be the same. Instead, I have another texture pack of just Hoth soldiers for villagers, and Snow Troopers for Skeletons. Brilliant move on Mojang's part.
So you don't see why this is good? Personally, this is one of the few features I'll end up liking since 3D items or tripwires and daylight sensors.
Practical use for pack artists? How about this:
The feature will allow pack makers to design packs modularly. They can offer a single pack that's plain and simple just like good ol' times, no bells and whistles, small file size. Then, separately, make different packs that add more features not everyone will benefit from/like: sounds, music, CTM, random mobs, etc.
Yes, that can be done now, but it's a huge duplication of effort. I you want specific features available separately, you have to make a whole new pack! Not only is that a duplication of effort to keep different versions up-to-date, if users decide they want a different version they will have to redownload much of the same data they already have.
This actually makes me feel better about the direction of Minecraft, even after those doofy horses (and villager sounds) they added.
Wow, CTM and animations and stuff... didn't even think of that. This is going to be great.
Wouldn't it also be usefull if there was a command block command to put a certain resource pack up the list? I've been thinking of making a Wizard of Oz map, but players would have to change resource packs inbetween, which isn't usefull.
That's a sweet idea. Both Wizard of Oz map, and switching texture packs by way of command block. This gets my vote for coolest needed feature. We could switch out all the mob skins at different points in the game.
Let's say i want the textures of pack A, and the sounds of pack B...
Do i put A on top to get the textures and B below to get the sounds?
But what if pack A already has sounds in it?
How does minecraft know wich part of wich Resourcepack i wanna use?
It will just pick everything from A except what A misses, that will be take from B right?
But what if A has everything added but i don'want to use the sky, lava, or sounds but use the ones from B.
How does minecraft know this??? This is not clear to me from the article, can someone enlighten me?
( Alvoria i'm looking at you... where are you?? )
Because if all it does is filling the missing stuff from A with stuff from B, it seems kinda useless.
That would mean i would have to take stuff out of A in order to get stuff from B showing, wich is just as tedious as mixing and matching really...
I only use my own textures nowadays since i'm busy with my own RP, but i'm still curious as to how this is resolved.
Edited because all that A and B made me mess up...
Correct in that most resource pack makers are going to need to release their stuff in several packs, like sound in one, textures in another, mob skins in another. As a resource pack maker, I'll definitely be doing this. Another benefit would be combining partial packs. Like one resource pack only has textures but no mob skins. Currently, there are not many texture packs that only modify mob skins, but with this new feature, expect there will be quite a few. I just released a "armor only" texture pack. When 1.7 comes out, then anybody can use my armor with their favorite texture pack. By placing my armor pack above the other texture packs, the armor skins will be overwritten. This "design philosophy" comes right out of programming, where instead of copy-pasting the same code over and over, the code is simply modified by layers and layers.
I mostly get it and see where it can be useful. But I don't get EXACTLY how it's priorities work. Let's say my first pack had sounds, textures, and language files. And then my second pack had lang files that changed the name of something else, texture files for the exact same items, mobs, and blocks; and a different set of sounds. Would it load everything from pack 1, sounds from pack 2, and merge the language files? If so, can I disable the merging of language files without removing them from a pack? Would this mean I'd need multiple language packs to prioritize over each other?
You could think of it as firstly loading everything from pack 1, and then loading everything from pack 2 and pack 2 stuff will overwrite pack 1 stuff. Since items/mobs/blocks were the same, you wouldn't notice a difference. In fact, you'd get the same result if pack 2 omitted items/mobs/blocks. Yes, the language files would merge, with pack 2 taking presidence, and the sounds would be from pack 2. From the description in the original post, it doesn't look like there will be a pick-and-choose option that allows resources to "not be merged." But that would be a handy feature -- to merge resources by their type, but not necessarily png by png. So to pick one resource pack for wood and use another one for grass would be convoluted. But to pick sounds from one and items from another might not be so difficult.
Wow, CTM and animations and stuff... didn't even think of that. This is going to be great.
Oh yes.
I don't see how so many people here just don't get the point of this feature. Yes, you can combine packs manually. But what you can't do is combine them on the fly. It will not only allow small additions and customizations, but also switching out entire sets of textures. People do things like this all the time on YT and never release it or tell about it, and then we get questions on what it is, or help on how to combine packs because it won't work (because they're doing it wrong). This is going to solve quite a few issues with that.
Pack makers could have interchangeable texture set downloads, without even using painterly. Users can easily make mod-support extension packs.
This is the most revolutionary feature since the introduction of the 1.6 or maybe even 1.5 pack system, and no converting needed!
That's not all! Here's some of the things I plan on doing that will be possible:
Clarity Resource Pack module- removes underwater and darkness screen overlay
CTM glass Resource Pack module- A classic CTM texture that provides visibility but has no invisible tiles. Also allows for cool designs to be made. Users could use this is they were unhappy with 90% of the classic CTM packs have that are horrible for large glass structures.
Optifine compatibility fixes (specific to packs)- packs using features specifically for MCpatcher often have issues with Optifine. This will allow pack makers to fix these issues to give Optifine users a better experience, with minimal effort on the pack maker. Example: my pack uses the renderPass property of CTM to disable backface culling. This is a feature for MCpatcher added with BetterGlass. It seems that due to that fact, Optifine refuses to load the CTM if "renderPass" is present. I could make a RP including only the .properties file with the line removed to fix this issue to allow Optifine users to use the glass CTM.
What if the resource pack has all files, but just changed some of them? So 99% of all files are the vanilla files.
Then it's not going to work right to only override certain textures. The pack will only be good for being overridden. Don't include default files. It's a bad practice and it was never needed (except on texture sheets) anyways. If you wanted to now, you could edit 1 block and have just that in-the game will automatically read the rest of the textures from the .JAR. Including vanilla files just adds bloat and makes it harder to see what you've changed, always has, and now there will actually be incentive not to do this. Only include files you've changed, it's all that's needed.
EDIT2:
For anyone confused on how the ordering works, think about it like layers in an image editor, or if you're not experienced with that, like a stack of cartoon cels, or paper cutouts, something like that.
The topmost packs are what you see first. if everything is done, you won't see anything below it. If it has missing parts, you will see those parts from the next lower pack that has them, and if none do, default. This is useful when you have individual parts of packs (to put at the top), or if needed, you can go into the pack (say, if your goal was to merge two complete packs) and delete files you don't want and they will be loaded from a pack lower. As I say above, the act of loading files (files, not textures, which was one of the reasons the 1.5 texture system was introduced.) missing from the pack from the .JAR is a long-standing feature of Minecraft
"I'm an outsider by choice, but not truly.
It’s the unpleasantness of the system that keeps me out.
I’d rather be in, in a good system. That’s where my discontent comes from:
being forced to choose to stay outside.
My advice: Just keep movin’ straight ahead.
Every now and then you find yourself in a different place."
-George Carlin
I also understand that what you're saying roughly amount to awesomeness in a purified and refined form.
That is the most wonderful thing I've seen in a long time GO MINECRAFT! BRILLIANT IDEA!!!!
Does this mean that resource packs will be able to modify the game? Or are they referring to modifying the textures? Either way, this is awesome! 1.7 is going to be an amazing update!
I think what he meant was that these resource pack updates are experiments to help mojang get a clear vision of how they should develop the mod API, in which they are now testing the load order concept.
I mean, who needs 2 resource packs at once? (Well, I guess Dinnerbone, but...)
I mean, it isn't that hard to drag and drop separate resource pack files into one... unless you're new and don't know how things work, of course.
^ I mean, I do this all the time... and not just resource packs.
Back when we still used the terain.jpg that was true, but now packs don't need to include any files that aren't modified (Aside from a txt so MC will see it as a pack), any missing files get replaced by the default automatically.
Very good point but I still would like the option of forced texture packs just because some younger players don't understand how resource packs work and some servers have themes. I am mostly talking about things like adventure maps. In some of those not using the server side textures would ruin the experience. A good example is a Disney theme park in this server paintings could be re-purposed to be park maps, or furnaces could look like T.V.s.
I hope that Mojang would also eventually release a black out option so admins can put blocks in a list and say if the texture has any transparency black them out so X-ray can not be used. What really needs to happen is admins need to get more options so depending on the type of server the admins can make improvements to reflect on the type of server they host. For any good admin that is the whole point of being a admin.
Wow, CTM and animations and stuff... didn't even think of that. This is going to be great.
That's a sweet idea. Both Wizard of Oz map, and switching texture packs by way of command block. This gets my vote for coolest needed feature. We could switch out all the mob skins at different points in the game.
Correct in that most resource pack makers are going to need to release their stuff in several packs, like sound in one, textures in another, mob skins in another. As a resource pack maker, I'll definitely be doing this. Another benefit would be combining partial packs. Like one resource pack only has textures but no mob skins. Currently, there are not many texture packs that only modify mob skins, but with this new feature, expect there will be quite a few. I just released a "armor only" texture pack. When 1.7 comes out, then anybody can use my armor with their favorite texture pack. By placing my armor pack above the other texture packs, the armor skins will be overwritten. This "design philosophy" comes right out of programming, where instead of copy-pasting the same code over and over, the code is simply modified by layers and layers.
You could think of it as firstly loading everything from pack 1, and then loading everything from pack 2 and pack 2 stuff will overwrite pack 1 stuff. Since items/mobs/blocks were the same, you wouldn't notice a difference. In fact, you'd get the same result if pack 2 omitted items/mobs/blocks. Yes, the language files would merge, with pack 2 taking presidence, and the sounds would be from pack 2. From the description in the original post, it doesn't look like there will be a pick-and-choose option that allows resources to "not be merged." But that would be a handy feature -- to merge resources by their type, but not necessarily png by png. So to pick one resource pack for wood and use another one for grass would be convoluted. But to pick sounds from one and items from another might not be so difficult.
Oh yes.
I don't see how so many people here just don't get the point of this feature. Yes, you can combine packs manually. But what you can't do is combine them on the fly. It will not only allow small additions and customizations, but also switching out entire sets of textures. People do things like this all the time on YT and never release it or tell about it, and then we get questions on what it is, or help on how to combine packs because it won't work (because they're doing it wrong). This is going to solve quite a few issues with that.
Pack makers could have interchangeable texture set downloads, without even using painterly. Users can easily make mod-support extension packs.
This is the most revolutionary feature since the introduction of the 1.6 or maybe even 1.5 pack system, and no converting needed!
That's not all! Here's some of the things I plan on doing that will be possible:
Clarity Resource Pack module- removes underwater and darkness screen overlay
CTM glass Resource Pack module- A classic CTM texture that provides visibility but has no invisible tiles. Also allows for cool designs to be made. Users could use this is they were unhappy with 90% of the classic CTM packs have that are horrible for large glass structures.
Optifine compatibility fixes (specific to packs)- packs using features specifically for MCpatcher often have issues with Optifine. This will allow pack makers to fix these issues to give Optifine users a better experience, with minimal effort on the pack maker. Example: my pack uses the renderPass property of CTM to disable backface culling. This is a feature for MCpatcher added with BetterGlass. It seems that due to that fact, Optifine refuses to load the CTM if "renderPass" is present. I could make a RP including only the .properties file with the line removed to fix this issue to allow Optifine users to use the glass CTM.
EDIT:
Then it's not going to work right to only override certain textures. The pack will only be good for being overridden. Don't include default files. It's a bad practice and it was never needed (except on texture sheets) anyways. If you wanted to now, you could edit 1 block and have just that in-the game will automatically read the rest of the textures from the .JAR. Including vanilla files just adds bloat and makes it harder to see what you've changed, always has, and now there will actually be incentive not to do this. Only include files you've changed, it's all that's needed.
EDIT2:
For anyone confused on how the ordering works, think about it like layers in an image editor, or if you're not experienced with that, like a stack of cartoon cels, or paper cutouts, something like that.
The topmost packs are what you see first. if everything is done, you won't see anything below it. If it has missing parts, you will see those parts from the next lower pack that has them, and if none do, default. This is useful when you have individual parts of packs (to put at the top), or if needed, you can go into the pack (say, if your goal was to merge two complete packs) and delete files you don't want and they will be loaded from a pack lower. As I say above, the act of loading files (files, not textures, which was one of the reasons the 1.5 texture system was introduced.) missing from the pack from the .JAR is a long-standing feature of Minecraft
"I'm an outsider by choice, but not truly.
It’s the unpleasantness of the system that keeps me out.
I’d rather be in, in a good system. That’s where my discontent comes from:
being forced to choose to stay outside.
My advice: Just keep movin’ straight ahead.
Every now and then you find yourself in a different place."
-George Carlin
(I also noticed Broken Anachronism in the texture pack list in the screencap )