I'm not sure how it will work. Dinnerbone also didn't say that it was definitely going to happen, just that it would be possible. I imagine that it'll be optional, or will require that you set something up with your download service. That is, those of us who use free hosting will probably not be able to use it, but big mods like Forge that have their own websites probably could.
Hopefully it'll ask before it downloads a load of stuff.
I own a webserver; be kinda nice to have SixtyGig auto update. I'd even be willing to host some other people's packs if need be. That could be a fun little mini-service I could setup someday.
In regards to packs containing possibly malicious code, any code that's in a pack should be sandboxed (At least if Mojang does it right). What that means is that it will have a very restricted set of things it can access and do. Things like opening network sockets and the like probably won't be possible with whatever they give us. (At least I hope not anyway.)
Rollback Post to RevisionRollBack
Tis far better to be a witty fool than a foolish wit.
In regards to packs containing possibly malicious code, any code that's in a pack should be sandboxed (At least if Mojang does it right). What that means is that it will have a very restricted set of things it can access and do. Things like opening network sockets and the like probably won't be possible with whatever they give us. (At least I hope not anyway.)
The problem is that Mojang has a history of giving fuss-all about security. It's been commented on that Minecraft is one of the easiest games to cheat in because there's no in-game protection. Heck, most servers still run Bukkit just for the anti-cheat stuff if nothing else... and even that's not foolproof because of how Minecraft is coded.
While I'd like to believe that they'll make an effort to clean up their security problems with this reorganization... I'd be surprised if they did.
The problem is that Mojang has a history of giving fuss-all about security. It's been commented on that Minecraft is one of the easiest games to cheat in because there's no in-game protection. Heck, most servers still run Bukkit just for the anti-cheat stuff if nothing else... and even that's not foolproof because of how Minecraft is coded.
While I'd like to believe that they'll make an effort to clean up their security problems with this reorganization... I'd be surprised if they did.
Cheating != security vulnerability.
There's a massive difference about caring whether people cheat and get diamonds on a server, and whether they want people using Minecraft as a trojan horse.
Well, guys, tell me if I am wrong, but does this new system mean that you won't be able to switch freely between packs and still have the same mods.
I think I might be misinterpreting the whole idea, and thinking that the mods and the textures will have to be in the same file.
Rollback Post to RevisionRollBack
The official Bluebird continuation is underway! Please come and help keep the pack alive!
There's a massive difference about caring whether people cheat and get diamonds on a server, and whether they want people using Minecraft as a trojan horse.
True, and they have closed holes in the game that allow people to borrow other player's identities by exploiting loopholes.
Well, guys, tell me if I am wrong, but does this new system mean that you won't be able to switch freely between packs and still have the same mods.
I think I might be misinterpreting the whole idea, and thinking that the mods and the textures will have to be in the same file.
Mods and texture packs will likely be different resource packs that you are using next to each other. Even if they aren't you can drag the mod files over into the resource pack of your choosing.
From what I get from it, modding it is optional. I would think you could create just textures.
There are a few things that will require just a tiny little eensy weensy bit of java knowledge, though writing a json file should be the easiest programming thing to learn ever. (I mean, theoretically.)
There are a few things that will require just a tiny little eensy weensy bit of java knowledge, though writing a json file should be the easiest programming thing to learn ever. (I mean, theoretically.)
Ok, this is it. PYTHON, I"M DUMPING YOU! Time to learn java...
***COMPLAINT ALERT!***
I wish that they'd keep everything separate. Sound packs are a great idea, but to combine them with mods and textures, no, just no. What I foresee is that texture artists who don't have a good mic/good zombie grunt/coding skills will start losing reputation, and people will be less likely to download the texture pack, as it is "incomplete". I will continue to call them texture packs, no matter what. I'm going to have to learn java soon....
Orrrrr....
We will see some talented texturers banding up with great coders/ musicians/ Voice Actors to create some of the best content packs ever to grace minecraft...
Only unlike mods currently this content wont be cloistered in a tiny demographic of players that could be bothered to mod their games.
I hate to burst anyone's bubble, but I don't think the idea of including MCPatcher components in texture packs is a good idea. The main reason is that doing so assumes that everyone will keep their code up to date. I mean, what happens when someone includes a broken version, and then that code gets installed last in a sequence of packs. The 'pack' is the most recent, so Minecraft wouldn't logically try to check for a newer version. All this would do would be to break every other pack that relies on that same system.
Also, remember that the Resource Pack System is NOT the Modding API. Just because everything will use that system going forward does not mean that Minecraft is suddenly an openly mod-able platform. A pack that includes MCPatcher components will suddenly crash Snapshots and any version other than what it's designed to work on. Now this will probably improve once the Modding API comes out... but in the meantime it'll be impossible to keep a pack that works on multiple versions which is one of the strengths of the current system.
Of course, when the Modding API comes out there's still no guarantee that they won't obfuscate the code (and just give modders the keys outright), meaning that a version-independant texture pack would still be impossible and backwards-compatibility non-existent.
There are a few things that will require just a tiny little eensy weensy bit of java knowledge, though writing a json file should be the easiest programming thing to learn ever. (I mean, theoretically.)
Nitpick alert!
Json is JavaScript not Java.
It does tend to get used a fair bit as a human readable serialization method though so I can understand the confusion. End nitpick.
Personally, I'm hoping the package structure is an all purpose structure that can contain either data or code or both. That way mods that do stuff like add blocks and creatures can bundle the textures for them along with the code to make them work.
If I was going to design the system I'd include a manifest file within the packages that describes all of the contents of the package and have a UI in the game for letting users pick what packages to apply and in what order. Conflicting entries in the manifests would overwrite each other based on the order in which they were applied. Course I'm not designing the system so I guess we will wait and see what we get.
Okay, I'm totally excited about this now.
Imagine offering OptiFine + custom tweaked shaders + your TP within a single download. Nobody would suffer from not having CTM, installation would be so much easier, we could easily customize our own variants of CTM methods.
I really hope Kahr or the OptiFine guy make their code available for us texture artists. And if not, I'm sure Ray/Syclone will do a great job. I'd love to help out, but my java knowledge is very limited.
But let's see how this all turns out, I don't think 1.6 will be released soon...
They don't even have a release date up on the wiki. That means not soon, because the wiki knows everything.
Hold your horses! Shaders!? That would be a very bad idea. People like me, who can't use the shaders, would be forced? see what I did? haha^^^^
Unless you offered multiple downloads.....
It really does sound like they're going with a Skyrim-like system, basically you download various "Resource Packs" and pick what order they load in. So, to translate what we do now to what they're planning.. if say, a texture pack needed MCPatcher, they would download the MCPatcher resource pack, and the texture pack that requires it. Then, tell Minecraft to load MCPatcher first, then the texture pack.
Although this is sounding like *all* mods are going to break. This could be a serious problem with MCPatcher/Optifine users for the first leg of 1.6 until they convert their mod to a resource pack. I hope the MCPatcher guys realize they should allow us the bundle their code directly into our texture packs though. That would be a much greater community service. But some people are stuck on the "fame" and will probably figure that will result in less direct downloads from them if it can be bundled.. because only texture artists will technically need to download MCPatcher at that point.
MCPatcher really needs to seriously consider making modular texture pack tools to be put directly in texture packs, if they don't, they'll be left in the dust as soon as someone else (IE: Our team if we make one) releases "modular tools" that can be injected directly into people's packs. No texture artist anywhere will continue to use MCPatcher if there's a built-in option that takes the need away.
At the absolute very least, if MCPatcher doesn't allow me to put the mod directly in my texture pack, I'm going to start writing some basic CTM specifically for my pack and release it as I write it. Doing it alone it'll be a *very* long time before I match MCPatcher's features, but just my general knowledge of programming tells me stuff like Random Mods and Random Method CTM are a cakewalk. The complicated stuff I see is the regular CTM (Like glass). But writing something to slap a random texture on a block instead of a specific one? Cake.
Bit pushed for time so very short. Yeah fully agree random would be the simplest to implement first......and rather good to get things going and in for test as its one of the more useful/widely used types that can quickly change the look of the land for the better
I own a webserver; be kinda nice to have SixtyGig auto update. I'd even be willing to host some other people's packs if need be. That could be a fun little mini-service I could setup someday.
While I'd like to believe that they'll make an effort to clean up their security problems with this reorganization... I'd be surprised if they did.
Cheating != security vulnerability.
There's a massive difference about caring whether people cheat and get diamonds on a server, and whether they want people using Minecraft as a trojan horse.
I think I might be misinterpreting the whole idea, and thinking that the mods and the textures will have to be in the same file.
I withdraw my cynicism.
Mods and texture packs will likely be different resource packs that you are using next to each other. Even if they aren't you can drag the mod files over into the resource pack of your choosing.
From what I get from it, modding it is optional. I would think you could create just textures.
There are a few things that will require just a tiny little eensy weensy bit of java knowledge, though writing a json file should be the easiest programming thing to learn ever. (I mean, theoretically.)
Ok, this is it. PYTHON, I"M DUMPING YOU! Time to learn java...
Orrrrr....
We will see some talented texturers banding up with great coders/ musicians/ Voice Actors to create some of the best content packs ever to grace minecraft...
Only unlike mods currently this content wont be cloistered in a tiny demographic of players that could be bothered to mod their games.
Also, remember that the Resource Pack System is NOT the Modding API. Just because everything will use that system going forward does not mean that Minecraft is suddenly an openly mod-able platform. A pack that includes MCPatcher components will suddenly crash Snapshots and any version other than what it's designed to work on. Now this will probably improve once the Modding API comes out... but in the meantime it'll be impossible to keep a pack that works on multiple versions which is one of the strengths of the current system.
Of course, when the Modding API comes out there's still no guarantee that they won't obfuscate the code (and just give modders the keys outright), meaning that a version-independant texture pack would still be impossible and backwards-compatibility non-existent.
Then I don't really see much use for it over the current system.
...But that's just my opinion.
My DeviantART, requests welcome.
B14 - My Texture Pack!
Need textures for your mod? Inquire within, just read the rules.
Json is JavaScript not Java.
It does tend to get used a fair bit as a human readable serialization method though so I can understand the confusion.
End nitpick.
Personally, I'm hoping the package structure is an all purpose structure that can contain either data or code or both. That way mods that do stuff like add blocks and creatures can bundle the textures for them along with the code to make them work.
If I was going to design the system I'd include a manifest file within the packages that describes all of the contents of the package and have a UI in the game for letting users pick what packages to apply and in what order. Conflicting entries in the manifests would overwrite each other based on the order in which they were applied. Course I'm not designing the system so I guess we will wait and see what we get.
https://gist.github.com/Dinnerbone/5662824
So now we know, and knowing is half the battle.
They don't even have a release date up on the wiki. That means not soon, because the wiki knows everything.
Hold your horses! Shaders!? That would be a very bad idea. People like me, who can't use the shaders, would be forced?
see what I did? haha^^^^
Unless you offered multiple downloads.....
It really does sound like they're going with a Skyrim-like system, basically you download various "Resource Packs" and pick what order they load in. So, to translate what we do now to what they're planning.. if say, a texture pack needed MCPatcher, they would download the MCPatcher resource pack, and the texture pack that requires it. Then, tell Minecraft to load MCPatcher first, then the texture pack.
Although this is sounding like *all* mods are going to break. This could be a serious problem with MCPatcher/Optifine users for the first leg of 1.6 until they convert their mod to a resource pack. I hope the MCPatcher guys realize they should allow us the bundle their code directly into our texture packs though. That would be a much greater community service. But some people are stuck on the "fame" and will probably figure that will result in less direct downloads from them if it can be bundled.. because only texture artists will technically need to download MCPatcher at that point.
MCPatcher really needs to seriously consider making modular texture pack tools to be put directly in texture packs, if they don't, they'll be left in the dust as soon as someone else (IE: Our team if we make one) releases "modular tools" that can be injected directly into people's packs. No texture artist anywhere will continue to use MCPatcher if there's a built-in option that takes the need away.
At the absolute very least, if MCPatcher doesn't allow me to put the mod directly in my texture pack, I'm going to start writing some basic CTM specifically for my pack and release it as I write it. Doing it alone it'll be a *very* long time before I match MCPatcher's features, but just my general knowledge of programming tells me stuff like Random Mods and Random Method CTM are a cakewalk. The complicated stuff I see is the regular CTM (Like glass). But writing something to slap a random texture on a block instead of a specific one? Cake.
Bit pushed for time so very short. Yeah fully agree random would be the simplest to implement first......and rather good to get things going and in for test as its one of the more useful/widely used types that can quickly change the look of the land for the better
win/win for a ball roller