[1.6] Resource Pack Discussion

  • #61
    Ok so I finally discovered the mouth of the horse where people are getting the info from.
    https://gist.github.com/Dinnerbone/5662824

    So now we know, and knowing is half the battle.
    Tis far better to be a witty fool than a foolish wit.
  • #62
    Quote from FabooGuy

    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.....
    If you would like to follow the progress of my WIP texture pack, click above.
    I really need feedback!
  • #63
    Quote from The_Fool76

    Ok so I finally discovered the mouth of the horse where people are getting the info from.
    https://gist.github....nerbone/5662824

    So now we know, and knowing is half the battle.


    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.
    Last edited by Rayvolution: 5/31/2013 12:57:54 PM
  • #64
    Quote from Rayvolution


    Snip


    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 :)

    Thank you for well over 1,500,000 downloads! Official Chroma Hills server IP Chromahills.net
  • #65
    Quote from SycloneSJS

    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 :)


    I just really hope Kahr (MCPatcher guy) realizes this and does this himself, he could easily release MCPatcher as a loadable pack into texture packs overnight, it would be the best option for all of us because all packs that need MCPatcher will natively work with the "installable version". People like us wouldn't even have to worry about programming anything. We'd just drop in the files and keep going.. business as usual.

    I don't know Kahr at all, so I'm *not* speaking from any experience what so ever. He could be the best guy here or the biggest d**khead in all of Minecraft. So I hope he's a "for the community" kinda guy, not a "for himself" kinda guy. Because releasing MCPatcher as a texture-pack-installable resource will hurt his download counts and his "fame/status". It'll become a "tool for artists" not a "tool for users", crippling his core user base numbers.

    But, if he did do this I would no doubt give him credit directly in the texture pack somewhere. (Maybe on the Mojang splash screen?). In fact, if he wants credit that would be a totally acceptable requirement that we put "This pack uses
    MCPatcher Tools by Kahr - (URL Here)" on the mojang splash screen.
  • #66
    Hopefully I wasnt too direct, but I PM'ed Kahr and asked him to read this thread, so we'll see what happens:
    A lot of the texture artists in Texture Discussion have been discussing the future of Minecraft and tools like MCPatcher in the future when Mojang adds resource packs. I highly recommend you please read the thread, specifically where we are talking about writing our own modular CTM packages to *replace* MCPatcher. Specifically around page 3-4.

    http://www.minecraftforum.net/topic/1827761-

    Please read the thread and get back to us. If we don't get reassurance that MCPatcher may take the route we're discussing, it is an actual possibility that we may write our own tools in it's place that could potentially completely replace MCPatcher. I don't think any of us really want that to happen, most everyone loves MCPatcher. But, no one will want to use it if we can just load texture mods directly into our packs in the future. :)
  • #67
    Quote from Rayvolution

    I just really hope Kahr (MCPatcher guy) realizes this and does this himself, he could easily release MCPatcher as a loadable pack into texture packs overnight, it would be the best option for all of us because all packs that need MCPatcher will natively work with the "installable version". People like us wouldn't even have to worry about programming anything. We'd just drop in the files and keep going.. business as usual.

    I don't know Kahr at all, so I'm *not* speaking from any experience what so ever. He could be the best guy here or the biggest d**khead in all of Minecraft. So I hope he's a "for the community" kinda guy, not a "for himself" kinda guy. Because releasing MCPatcher as a texture-pack-installable resource will hurt his download counts and his "fame/status". It'll become a "tool for artists" not a "tool for users", crippling his core user base numbers.

    But, if he did do this I would no doubt give him credit directly in the texture pack somewhere. (Maybe on the Mojang splash screen?). In fact, if he wants credit that would be a totally acceptable requirement that we put "This pack uses
    MCPatcher Tools by Kahr - (URL Here)" on the mojang splash screen.

    Well, we already know that optifine won't do it, as [strange list of numbers and letters] refused optifine to be included in the game.
    If you would like to follow the progress of my WIP texture pack, click above.
    I really need feedback!
  • #68
    I don't necessarily agree that Kahr just giving up control of MCPatcher is a good idea. If he wants to, that's fine. But even assuming he does we're making a LOT of assumptions about how this whole system is even doing to work. While the daydreaming is nice, there's no telling what shape this system will ultimately take and the idea of a texture pack with it's own built-in mod might not even be possible. <_<

    Also, I can't help but think it's kinda dickish to say "If you don't do it our way we'll make something better." No offense Ray, but "put up or shut up" applies here. If any of us could make something better than either MCPatcher or Optifine, it would have been done by now. If you've got the skills, go for it man! Don't wait around to see what Kahr is doing. Otherwise, let the man run his mod as he sees fit. :(

    Finally, as I said, I don't really agree that everyone having their own stand-alone version is a good idea. We don't know how well the Modding API is going to work for that sort of thing. Dinnerbone and Jeb have both said it's mainly going to make it easier to add new blocks and items... not replace Forge or Bukkit as the be-all end-all of modding. <_<

    Edit: According to Rhodox's Twitter, the change to the 1.6 format is less radical than the change to the 1.5 format. Good to know the conversion won't be horrible then. :)
  • #69
    Quote from Alvoria

    Edit: According to Rhodox's Twitter, the change to the 1.6 format is less radical than the change to the 1.5 format. Good to know the conversion won't be horrible then. :)

    It's still probably going to be horrible. Maybe just not as horrible.
    If you would like to follow the progress of my WIP texture pack, click above.
    I really need feedback!
  • #70
    Quote from blue_dragon360
    It's still probably going to be horrible. Maybe just not as horrible.
    Sheesh, and I thought I was a pessimist. :(
  • #71
    Quote from blue_dragon360

    It's still probably going to be horrible. Maybe just not as horrible.


    Everyone made such a big fuss over that, and it wasn't even hard to convert them. With all the tools that were released within a few weeks after the 1.5 format was announced, I could literally convert a pack in 10 seconds. I doubt this change will be any more difficult.
    Last edited by samohtj: 5/31/2013 6:31:46 PM
  • #72
    Quote from Alvoria

    I don't necessarily agree that Kahr just giving up control of MCPatcher is a good idea. If he wants to, that's fine. But even assuming he does we're making a LOT of assumptions about how this whole system is even doing to work. While the daydreaming is nice, there's no telling what shape this system will ultimately take and the idea of a texture pack with it's own built-in mod might not even be possible. <_<

    Also, I can't help but think it's kinda dickish to say "If you don't do it our way we'll make something better." No offense Ray, but "put up or shut up" applies here. If any of us could make something better than either MCPatcher or Optifine, it would have been done by now. If you've got the skills, go for it man! Don't wait around to see what Kahr is doing. Otherwise, let the man run his mod as he sees fit. :(


    oh no, I wasn't at all thinking he should go open source and give away control or anything. He just needs to offer permission to allow us to bundle the already complied classes in our packs. I think he should keep it all closed source, else people will try to make "MCPatcher Tweak Packs" and crap, we don't need any of that floating around. :/

    Although you may be right about the "put up or shut up". I didn't mean it to sound that way, I was just giving him a heads up that times may be changing and he may want to look into what we are discussing. I'm a pretty blunt/direct person and I hate tiptoeing, and quite honestly what I said is still true. If he doesn't do it, someone else will. (regardless who it is) It's really the only logical step/direction it could go if resource packs work like we're assuming they will. So even if he doesn't want to hear it, it's still facts he'll have to face. This way he has more time to plan his direction. :P

    He can be mad at me, but I think it's for his own good he listens to us. :P

    Quote from samohtj

    Everyone made such a big fuss over that, and it wasn't even hard to convert them. With all the tools that were released within a few weeks after the 1.5 format was announced, I could literally convert a pack in 10 seconds. I doubt this change will be any more difficult.


    Whats funny is I actually converted my entire pack by hand and it only took 6 hours.. that includes the (at the time) like 50 or so CTM texture sets I had to switch over. Wasn't too bad to be honest.
    Last edited by Rayvolution: 5/31/2013 8:17:25 PM
  • #73
    Quote from Rayvolution »

    ... snip ...

    Frankly, I resent the insinuation that I'm not "for the community" if I don't drop everything to cater to your needs. It is a major effort on my part to keep MCPatcher updated for snapshots -- something most mods don't even attempt -- and without which texture pack artists would be dead in the water between MC releases. On top of that, MCPatcher is open source (bitbucket page), again, unlike many other mods, and if that's not good enough for you I don't know what else to say.

    Moving on, your proposal simply makes no sense. Resource packs are just a slightly generalized implementation of texture packs. They can include sounds and other assets and allow for multiple packs to be active at once. That's it. They are data, not code. What you're looking for is the mod API, but there are two problems there: First, the API is likely intended for gameplay elements (new blocks, items, etc.) and it's doubtful that it will expose the low-level rendering elements that MCPatcher allows artists to change.

    Second, and more to the point, is the small fact that the API is pure vaporware with an expected release just shy of the heat death of the universe. It's the vaporware of vaporware, collapsed by 3+ years of community pressure, wishful thinking, and sheer nonsense into a supermassive vaporware singularity from which no realistic expectation or competent software design can escape. I would be a complete fool to look at Minecraft's development history and base any plans on the existence or usefulness of their official API.

    If you want to try this again, I would suggest you spend some time looking over the MCPatcher source I linked. Then decompile a 13w22a jar and look at the obfuscated source (classes bhv through bhz are of particular interest). When you've done that and come back with a concrete plan to replace the former with the latter, I'll take you seriously.
  • #74
    {this is all just speculation and thoughtful guessing, please take this with a pinch of wild imagination)

    If I get this right, pretty much it's going to be like the .esm and .esp files for Bethesda type mods...

    So in theory what will happen is that we'll have our 'master' type mods that will deal with the game itself and major mods/addons... This is the road I think MCPatcher might have to take and maybe a greater deal of the mods... However it would eliminate the need of MCPatcher as a mod injector and simply dedicate to the actual mods it has.

    And then we'll have our 'package' type of mod that will when selected will override the masters according to their list position. In our case with texture packs, we modify the images and utilize assets from the other mods and probably be late in the 'mod order.'

    Or I could be completely wrong and shiz gonna get all fugs up in har!

    But I wouldn't wanna make any assumptions until the actual methods of use are released. This way we're all on the same page and we don't have to make wild guesses...

    -Shawn
  • #75
    Quote from Kahr
    - snip -
    * Alvoria give Kahr Fist Bump of Maximum Respect for summing that up so well. *

    Yea, this entire thing has been based on a lot of assumptions and guessing. Not to mention more than a little imagination. Hopefully going forward we can restrain both optimism and pessimism a little better, and think a little more realistically about moving forward.

    Thanks for taking time from your busy schedule to come and address this Kahr. Sorry it put your off. :(
  • #76
    Quote from Kahr

    Frankly, I resent the insinuation that I'm not "for the community" if I don't drop everything to cater to your needs. It is a major effort on my part to keep MCPatcher updated for snapshots -- something most mods don't even attempt -- and without which texture pack artists would be dead in the water between MC releases. On top of that, MCPatcher is open source (bitbucket page), again, unlike many other mods, and if that's not good enough for you I don't know what else to say.

    Moving on, your proposal simply makes no sense. Resource packs are just a slightly generalized implementation of texture packs. They can include sounds and other assets and allow for multiple packs to be active at once. That's it. They are data, not code. What you're looking for is the mod API, but there are two problems there: First, the API is likely intended for gameplay elements (new blocks, items, etc.) and it's doubtful that it will expose the low-level rendering elements that MCPatcher allows artists to change.

    Second, and more to the point, is the small fact that the API is pure vaporware with an expected release just shy of the heat death of the universe. It's the vaporware of vaporware, collapsed by 3+ years of community pressure, wishful thinking, and sheer nonsense into a supermassive vaporware singularity from which no realistic expectation or competent software design can escape. I would be a complete fool to look at Minecraft's development history and base any plans on the existence or usefulness of their official API.

    If you want to try this again, I would suggest you spend some time looking over the MCPatcher source I linked. Then decompile a 13w22a jar and look at the obfuscated source (classes bhv through bhz are of particular interest). When you've done that and come back with a concrete plan to replace the former with the latter, I'll take you seriously.


    I never claimed you were not for the community, I claimed I have no idea what kind of a person you are, so I don't know if you're for the community or just another one of those selfish in-for-himself coders. So please, don't think I thought you were some a**hat or anything. I don't think that at all. ;)

    You seem to miss the point of this thread. We *don't* know what the future holds, but it sounds like we will be able to have directly modified code and have it packaged in our texture packs, meaning we *could* include MCPatcher's texture features directly in our packs. That's the problem that should be looked at.

    You can be mad at the community all you want, we all get that way. Everyone always makes ridiculous demands to all of us (Artists and coders alike), it's something we just deal with. But in this case if dinnerbone goes through with what it sounds like he's doing.. it sounds like a good direction for MCPatcher to transition from a "Users" tool to an "Artist" tool that can be bundled into the pack. My example was to allow us artists to package your work directly into our texture packs and then link-back credit to you as deserved. Your patcher is great, and shouldn't be replaced and of course we all appreciate the work put into it. I'm just making the point that if the artists *can* embed mods in the future directly into our resource packs MCPatcher may become obsolete if someone makes a like-set of tools that can be put directly into texture packs.

    We also can't assume the latest snapshot has anything dinnerbone suggested, or that any of us are right. More or less, this is just a direction you should probably look at and consider in the future.

    EDIT: I also never realized MCPatcher was open source. I thought it was closed source. My mistake. ;)
    Last edited by Rayvolution: 5/31/2013 9:26:04 PM
  • #77
    Quote from Kahr

    Second, and more to the point, is the small fact that the API is pure vaporware with an expected release just shy of the heat death of the universe. It's the vaporware of vaporware, collapsed by 3+ years of community pressure, wishful thinking, and sheer nonsense into a supermassive vaporware singularity from which no realistic expectation or competent software design can escape. I would be a complete fool to look at Minecraft's development history and base any plans on the existence or usefulness of their official API.


    I have to agree with this. Sorry, Mojang, but I don't see this happening any time soon.

  • #78
    Quote from carollwood

    I have to agree with this. Sorry, Mojang, but I don't see this happening any time soon.


    I partially agree, Mojang is known for being retarded half-**** coders with A.D.D. *dodges fanboys throwing bricks* but in this case, it looks like the resource packs are becoming a reality. So an actual discussion about them is totally warranted in this situation.
  • #79
    I don't feel like mods will be able to be in resource packs. Reading through the gist The_Fool76 linked to (including the comments) I don't see much about it involving mods besides making RESOURCES for mods and adding SHADERS without using mods.

    This makes sense with what happened a while ago, as I made a suggestion for texture packs to include their own code to accomplish certain things (like mcpatcher or optifine does, but often more specific things) and Grum pretty much responded with "no, modding game code is dirty and we can't allow it, use a plugin (but plugins will only be server-side) or shader instead!".

    I personally don't know how things are going to turn out anymore, and I don't think Mojang knows, either...
  • #80
    Quote from insomniac_lemon

    I don't feel like mods will be able to be in resource packs. Reading through the gist The_Fool76 linked to (including the comments) I don't see much about it involving mods besides making RESOURCES for mods and adding SHADERS without using mods.

    This makes sense with what happened a while ago, as I made a suggestion for texture packs to include their own code to accomplish certain things (like mcpatcher or optifine does, but often more specific things) and Grum pretty much responded with "no, modding game code is dirty and we can't allow it, use a plugin (but plugins will only be server-side) or shader instead!".

    I personally don't know how things are going to turn out anymore, and I don't think Mojang knows, either...
    Huh, well, this contradicts a load of stuff that I've heard. Doesn't surprise me, though. <_< Yea, I don't think Mojang really knows where they're doing with this one. :(

    Here's my thought: Let's just roll with the punches on this one. What say you all? ^_^
  • To post a comment, please or register a new account.
Posts Quoted:
Reply
Clear All Quotes