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.
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.
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.
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.
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.
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.
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.
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.
He can be mad at me, but I think it's for his own good he listens to us.
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.
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.
{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...
* 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.
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.
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.
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.
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...
Rollback Post to RevisionRollBack
"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 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?
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?
Well, it was late last year(the same one when I asked about using MCpatcher or Optifine and got no response), but maybe their priorities changed. Or maybe Grum isn't a good representative of what Jeb or Dinnerbone plan on implementing.
It might be possible that this will work, but none of the mod/plugin/shader things in a resource pack will load when you play on a server.... and if you're modding specifically for your pack (use it to change derivative blocks, faces, CTM or natural/random textures ect.) then your pack would be broken.
I'm not expecting anything. It'd be cool, but I have the feeling that it'll be limited and won't be finished before July.
Plus, I haven't been involved with Minecraft anymore for a while now.
Rollback Post to RevisionRollBack
"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
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?
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.
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.
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.
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.
He can be mad at me, but I think it's for his own good he listens to us.
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.
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.
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
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.
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.
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.
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...
"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
Here's my thought: Let's just roll with the punches on this one. What say you all?
Well, it was late last year (the same one when I asked about using MCpatcher or Optifine and got no response), but maybe their priorities changed. Or maybe Grum isn't a good representative of what Jeb or Dinnerbone plan on implementing.
It might be possible that this will work, but none of the mod/plugin/shader things in a resource pack will load when you play on a server.... and if you're modding specifically for your pack (use it to change derivative blocks, faces, CTM or natural/random textures ect.) then your pack would be broken.
I'm not expecting anything. It'd be cool, but I have the feeling that it'll be limited and won't be finished before July.
Plus, I haven't been involved with Minecraft anymore for a while now.
"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
Otherwise this could cause a lot of problems if texture packs use the same style as sound pack, mods, etc. will.
Still, I'm looking forward to texturing the hardcoded stuff. Swamps will finally NOT be butt-ugly and I can have custom particle colours! (probably)
Fully agree.