Nick, chill please. He's right, MC patcher works by shipping patches in the form of functional diffs, applied to classes in the jar file. FML/Forge's changes to use a runtime binary diffing strategy pretty much break his model entirely.
lol, I am calm, and I wasn't questioning the issue at hand, nor his correction. I was responding to the remark he made about not giving in to requests.
But painting it as some kind of jihad move is frankly kool-aid.
I wouldn't use the word jihad. It's more like Forge choosing to take advantage of a mojang change to do what mojang ASKED (yes, ASKED) them to do. And the anti-Forge, base class editing modders are just taking the opportunity to score points against forge, when in fact forge has done nothing wrong (in the eyes of mojang at least). So I don't see why Forge should cater to a vocal minority, and as cpw's repeatedly stated in the past, he's welcome to discussion, suggestions and negotiation, as long as you go in with an open mind and not "FORGE IS EVIL I DONT WANNA GO NEAR IT", as I've seen is some of the attitudes of base-modding people..
I never said that the new Forge distribution method wouldn't go smoothly with MCPatcher.
I see that the problem is pretty big, and difficult to solve. For as much as I care, they can be incompatible, as I don't use Forge mods and MCPatcher toghether (it's impossible to find a TP of my taste with all the texture needed for the mods I use). However I see the problem for others, and I thought that OF, that's still forge compatible can ship the custom texture support for Forge.
After all, most of the people still don't use mods use MCPatcher for TPs, while people who use Forge usually run Optifine. In terms of costs/benefits this seems a much more sensible way.
@nickhawaii sorry if that came out blunt, I forget how some people don't have a minimum of computer science background, so what was obvius to me wasn't to you. Anyway, to respond to your question, Mojang cannot, at least to my knowledge, make legal claims on MCPatcher, as it is all Kahr work. Morally he should oblige, and if I was him, I would say a f*ck you to them, considering I was doing a free service to the community...
Sage, as far as I am aware, MC patcher isn't and never has been in violation of the MC ToU. Which is more than FML and Forge could say until recently. I have no problem with what he is doing - as you can see, FML is now in some ways emulating MC patcher, except it's doing it at runtime, rather than "pre-runtime". My problems with MC patcher were always and remain technical in nature - his method of class patching was causing FML and Forge to have a hard time functioning, and it was NOT obvious why this was the case, and the fact MC patched classes failed to decompile meant it was very difficult to diagnose.
Speaking of optifine, I am working with sp614x on something that many forge and non-forge users should enjoy, more to come on that (hints exist in the FML github!). However that's not relevant for this thread, please ask on twitter or somewhere else, or better yet, just wait.
Kahr, if you wish to work something out, so that we can resume coexistence, I am always available to talk, via twitter, IRC, or even here on PM (though I don't check in as often as I should here).
First with BTW, then with Modloader... and now this. Crap man... where did it all go so horribly wrong?
What do you mean "First with BTW, then with Modloader"??? Sorry I don't use Forge that much so I'm slow when it comes to this stuff. But also doesn't Forge Support Modloader mods???
Well, wouldn't the problem of Texture Pack features or mod support be (kinda) fixed because of Optifine??? I mean they do have some of MCPatcher's Texture Pack features, NOT ALL, BUT most of them. So, theoretically, would players still in, some ways can get great textures while they use mods??? AGAIN, not all features, but some ... well from a theoretical stand point.
And couldn't we, again from a theoretical stand point, make a mod version of MCPatcher, & then it would work? I mean edit some of the inside code(I don't know java that much so I don't know much editting that means that would have to be done), & then boom, (maybe) instant compatibility???
What do you mean "First with BTW, then with Modloader"??? Sorry I don't use Forge that much so I'm slow when it comes to this stuff. But also doesn't Forge Support Modloader mods???
Read the thread between that post and this one. Click a few of the "Resistance is... essential" banners. You'll learn quite a bit about the sordid history of how Forge has evolved.
As a show of respect to all involved, please DO NOT bring any of it up as arguments here. Just educate yourself to find out why this has stirred up a lot of bad blood.
Well, wouldn't the problem of Texture Pack features or mod support be (kinda) fixed because of Optifine??? I mean they do have some of MCPatcher's Texture Pack features, NOT ALL, BUT most of them.
No, not most of them. Optifine has fallen quite far behind MCPatcher in terms of features. I would honestly be surprised of it ever caught up to the point where it was equal with MCPatcher for use by artists.
So, theoretically, would players still in, some ways can get great textures while they use mods??? AGAIN, not all features, but some ... well from a theoretical stand point.
Yes, if Optifine ever caught up to MCPatcher. It's never happened, and I doubt it'll suddenly happen now..
And couldn't we, again from a theoretical stand point, make a mod version of MCPatcher, & then it would work? I mean edit some of the inside code(I don't know java that much so I don't know much editting that means that would have to be done), & then boom, (maybe) instant compatibility???
It's not that simple. Again, read the thread between my last post and this one. Particularly the last two pages. You'll see CPW post a load of reasons why he believes that Forge compatibility with MCPatcher doesn't work well. Likewise, you'll find out why MCPatcher uses an actual patcher rather than just being a drop-in mod: it avoids shipping Minecraft base classes by using this method. Forge is now doing the same thing, in a very different way, and it's causing this issue.
That's what I'm getting out of this entire thing, anyway. Admittedly I'm just an artist caught in the crossfire here, so my understanding may not be perfect. Apologies to everyone who's offended by my attempts to sum up the situation as fairly as I'm able.
Read the thread between that post and this one. Click a few of the "Resistance is... essential" banners. You'll learn quite a bit about the sordid history of how Forge has evolved.
No, not most of them. Optifine has fallen quite far behind MCPatcher in terms of features. I would honestly be surprised of it ever caught up to the point where it was equal with MCPatcher for use by artists.
Yes, if Optifine ever caught up to MCPatcher. It's never happened, and I doubt it'll suddenly happen now..
Yes this I know. But really the only thing that they don't HAVE is CIT & Biome&Height Based CTM & I think either Better Glass or Better Skies. They also don't have the new V+H & H+V CTM Methods. But other than that, I think they still have all the other texturing features(it's been a while since I lasted checked, so I don't know for sure). Now I know Optifine will NEVER catch up to MCPatcher, as MCPatcher has the advantage of building against the snapshots while Optifine doesn't. This means that MCPatcher can do updates quicker(But then again this means that Optifine has to only update once while MCPatcher does it multiple times, so it's both about the same, BUT STILL). While yes, they don't have all the features of MCPatcher, I want to point out to the people that have said it's either "Good Textures or Mods"(or anything like that), that it is still possible to have both. Maybe not as good as MCPatcher, but still can be done.
It's not that simple. Again, read the thread between my last post and this one. Particularly the last two pages. You'll see CPW post a load of reasons why he believes that Forge compatibility with MCPatcher doesn't work well with Forge. Likewise, you'll find out why MCPatcher uses an actual patcher rather than just being a drop-in mod: it avoids shipping Minecraft base classes by using this method. Forge is now doing the same thing, in a very different way, and it's causing this issue.
While yes I do know all this, I was just talk from a theoretical stand point.
Well obviously everyone has a valid point and will stand by their decisions and methods, so it's safe to say that stuff will go A-wire.
What I do not understand is why Forge, which I believed was a community project for the community will now basically enforce implementation onto it's users and developers of mods that is asked for by the Minecraft Development team. What in the world do they actually have to do with the modding community, the most awesome mods came to life thru base edits simple functions better rendering, which the Mojang dev team could have added years ago, but never did.
Some of these great ideas has turned into even more spectacular work from mod developers, but now all off a sudden no more base edits. Personally I'm against base edits it's just sometimes really bad, but I do not go and force my views of base edits onto everyone else, however this means huge and successful mods that uses base edits have to now work twice as hard on the same thing they already accomplished a year or more ago instead of spending time expanding there work.
Forge is loosing face, and I can't really see how Forge in anyway can be seen as a community mod for the community when the implementation of the API is being done in such a way that developers is force to adapt to new code styles and new methods and that happens just about all the time, whats even worse is that not only are we force to comply, but every single method lex adds or changes nobody at first has any clue or idea how to use, you have to spend time on figuring out what the heck he just changed and how it affects your mod. Just for the record cpw this is where I have to say your are really good at when I open up a FML class file I can read exactly what I need to do to change and update my mod, unfortunately you group yourself with lex and he does exactly the opposite not to mention the way he talks to people that alone is actually sad.
Anyways cpw your work is inspired, but Forge I'm sorry this last 1.6.2 update was like the cherry on top of the cake, the sad thing is I'm stuck with forge and stuck to abiding by the changes all the time, but Forge is in no ways for the public, it's just an API that helps and if you use it get use to code changes all the time, it never stops.
So with that said freedom to do what we want with the code is what makes modding great for minecraft, start applying rules and crap whether it's for good intentions or not is taking away that freedom and theirs no other way to see this and this is going to split the community down the middle.
Conraad, this is absurdly off topic, so I will not discuss it further here. If you have a beef with FML or Forge or any "perceived changes", you know where I am : IRC, twitter or PM here.
Yes this I know. But really the only thing that they don't HAVE is CIT & Biome&Height Based CTM & I think either Better Glass or Better Skies. They also don't have the new V+H & H+V CTM Methods.
You forgot half the features of Custom Colors, as well as a few other bits and bobs here and there. Basically the short version is that every graphics feature of Optifine is half-featured compared to MCPatcher. Also... I think it has Better Skies now, albeit in a somewhat still buggy form.
Maybe not as good as MCPatcher, but still can be done.
Almost every graphics feature I have in my pack is not supported by Optifine. If you're after the graphics enhancements, Optifine does next to nothing for users of my work. This isn't because of any anti-optifine stance on my part (I love Optifine for what it does), but just because the features that appeal to me aren't included in that mod. From my standpoint, there's very little difference between viewing my pack in strait vanilla and viewing it with Optifine.
This has gone off-topic at this point, though, so the discussion should probably end here. If you want to continue to bat it around, either send me a PM or start a thread in Texture Discussion. Thanks.
You forgot half the features of Custom Colors, as well as a few other bits and bobs here and there. Basically the short version is that every graphics feature of Optifine is half-featured compared to MCPatcher. Also... I think it has Better Skies now, albeit in a somewhat still buggy form.
AAAHHH, yes Custom Colors!!! Forgot about that. I JUST checked it too. I always look at what Optifine has & don't really look at what's in the files. I just see "Custom Colors" & I'm like OH OK good. I just checked(for the first time)how much of Custom Colors they have & yeah ...
Almost every graphics feature I have in my pack is not supported by Optifine. If you're after the graphics enhancements, Optifine does next to nothing for users of my work. This isn't because of any anti-optifine stance on my part (I love Optifine for what it does), but just because the features that appeal to me aren't included in that mod. From my standpoint, there's very little difference between viewing my pack in strait vanilla and viewing it with Optifine.
Oh ok. I forgot about that some packs use MCPatcher's way of doing stuff. I was just thinking about my pack(which, because it's NOWHERE close to done, mostly works with Optifine), I forgot about your pack(which by the way, is great! I love it) & other's pack(which I don't usually,expect on rare occasions I test with Optifine).
I love Optifine for what it does too, & I think that's why it's not doing so good in the Tetxure Pack Features area, because it's designed for Lag Reduction & not Texture Packs, unlike MCPatcher.
This has gone off-topic at this point, though, so the discussion should probably end here. If you want to continue to bat it around, either send me a PM or start a thread in Texture Discussion. Thanks.
I totally support the stance on Forge. Not a fan of what is happening there. It's like some sort of move to a dictatorial situation. The whole point of the Mod community is that it has been open and flexible. So if the Forge guys are going against that, I'll be sticking with Mod Loader.
Looking forward to some of the remaining bugs in MC Patcher to be fixed so fonts, etc. all look and work right in Sphax.
Thanks for standing up for what you believe in, and for the work you do on this mod.
I totally support the stance on Forge. Not a fan of what is happening there. It's like some sort of move to a dictatorial situation. The whole point of the Mod community is that it has been open and flexible. So if the Forge guys are going against that, I'll be sticking with Mod Loader.
Looking forward to some of the remaining bugs in MC Patcher to be fixed so fonts, etc. all look and work right in Sphax.
Thanks for standing up for what you believe in, and for the work you do on this mod.
Fonts work for me usually, but ill try out the Sphax Texture Pack & if it works or not for me
Thanks to everyone who posted their support. I haven't made any final decisions yet.
I would also like to thank cpw for his measured responses. My post was obviously made in frustration and I appreciate his willingness to keep things from getting out of hand.
I wasn't aware of Grum's statement regarding distribution of modified class files. You'd think an announcement of that magnitude would be a little more prominent than a few tweets, but that's Mojang's professionalism for you. I can see how that puts you in a difficult position and it helps knowing you didn't make this change on a whim.
Still, in my defense, and please take this as constructive criticism, you really could have handled this better. A request is not a requirement, and the best response to Grum is -- well the BEST response is "Sure, give us a proper API and we'll get right on that". But barring that, at the very least you could have waited until you had a more fully-featured patching system in place before springing this on everyone.
Telling people "Sure you can modify base classes, just not any of these: *insert list of every base class anyone cares about*" comes across as glib and insulting. Forge has a spotty reputation as it is, one that goes well beyond one particular mod, and you didn't do yourself any favors here.
I also apologize for missing your PM last year. No slight intended at all. I either missed it entirely in the deluge of PMs I get, or I saw it, put it aside because it was a complex question and simply forgot about it. I rely on decompilation in my own debugging, so I can fully sympathize with your frustration when it isn't working.
I'm willing to work with you on possible compatibility between MCPatcher and forge, but I do insist on maintaining my independence. I have this weekend slated for the backlog of bug reports and remaining 1.6 issues, but I will PM you once I catch up.
I think I may be missing something here, but the birchcolor.png and pinecolor.png of my texture pack have stopped working in 1.6.2. I've spent a very long time making sure everything works perfectly, and now these are the only things that won't--but I've yet to find any simple discussion on simply where I'm supposed to put them now. I've tried colormap and misc, but no matter where I put them, the trees are not affected.
It used to be that I just kept the files in misc with the other biome gradients. What's going on? Where am I supposed to put these images now? I'd greatly appreciate if someone could please explain this to me as if I'm a complete newbie, because all the other discussions seem to be going over my head, and my mind is all mashed up from hours of reworking my pack >.<
Thanks to everyone who posted their support. I haven't made any final decisions yet.
I would also like to thank cpw for his measured responses. My post was obviously made in frustration and I appreciate his willingness to keep things from getting out of hand.
I wasn't aware of Grum's statement regarding distribution of modified class files. You'd think an announcement of that magnitude would be a little more prominent than a few tweets, but that's Mojang's professionalism for you. I can see how that puts you in a difficult position and it helps knowing you didn't make this change on a whim.
Still, in my defense, and please take this as constructive criticism, you really could have handled this better. A request is not a requirement, and the best response to Grum is -- well the BEST response is "Sure, give us a proper API and we'll get right on that". But barring that, at the very least you could have waited until you had a more fully-featured patching system in place before springing this on everyone.
Telling people "Sure you can modify base classes, just not any of these: *insert list of every base class anyone cares about*" comes across as glib and insulting. Forge has a spotty reputation as it is, one that goes well beyond one particular mod, and you didn't do yourself any favors here.
I also apologize for missing your PM last year. No slight intended at all. I either missed it entirely in the deluge of PMs I get, or I saw it, put it aside because it was a complex question and simply forgot about it. I rely on decompilation in my own debugging, so I can fully sympathize with your frustration when it isn't working.
I'm willing to work with you on possible compatibility between MCPatcher and forge, but I do insist on maintaining my independence. I have this weekend slated for the backlog of bug reports and remaining 1.6 issues, but I will PM you once I catch up.
Well,thank you for your reply.
Firstly, a request from Mojang, really should be considered an expectation of delivering results.
The new launcher was sort of (not that I'm claiming responsibility) in response to "we need to be able to control how minecraft runs", which is a prerequirement for any runtime monkey patching.
Note one of it's key capabilities is being able to direct other things to run, not just "vanilla", directly from configuration.
As to timing, well, I promised to myself that as soon as no base class edits were needed, NONE would be distributed, and I try to keep my promises. I made public this intention about 6-7 months ago, when I first figured out how I could monkey patch Minecraft at runtime. This is NOT new news. I have tweet about it repeatedly as pieces of tech falled into place. Sadly, time and resources meant I couldn't complete the "sophisticated" system to my satisfaction, so the "crappy diffs" are the fallback position, but I intended to keep my word.
On "changing classes", we do have a couple of systems we're working out with sp614x, and "don't change these classes" isn't actually mandatory- if you can patch in what fml/forge needs, there's a simple flag that stops the "crash and burn" behaviour and tries to soldier on (sp614x is already using it in optifine, though we have already come up with better ideas).
Finally, editing the minecraft jar is simply a no-no for us, because again, Mojang is gonna start sig checking that thing. It took me a while to convince them not to straight out in 1.6. You can prepend any "modifications" even to base classes, to the classpath right from the launcher, so changing the actual jar should never be considered a necessary step (if you're worried about signature violations, Mojang has code at github.com/Mojang/LegacyLauncher that will step around signature violation checks in normal Java).
I'm certain you could create a "modded.jar" file, and the json to go with it, from mcpatcher very easily (and probably install that version into the launcher while you're at it ).
Anyway, this is of course, your choice. I'm happy to work with you to try and figure out how mcpatcher and forge can coexist in the future, just as I'm working with sp614x. I suggest following me on twitter (minecraftcpw) if you don't want to be blindsided by these things in the future. Also, if you have any questions, just ping me on twitter, PM or IRC (cpw@esper), if you want to talk further, I'm always happy to engage and solve problems..
...snip...
I'm willing to work with you on possible compatibility between MCPatcher and forge, but I do insist on maintaining my independence. I have this weekend slated for the backlog of bug reports and remaining 1.6 issues, but I will PM you once I catch up.
I would expect nothing less than complete independence from anything forge, except maybe inside a 'forge compatibility module'.
lol, I am calm, and I wasn't questioning the issue at hand, nor his correction. I was responding to the remark he made about not giving in to requests.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI wouldn't use the word jihad. It's more like Forge choosing to take advantage of a mojang change to do what mojang ASKED (yes, ASKED) them to do. And the anti-Forge, base class editing modders are just taking the opportunity to score points against forge, when in fact forge has done nothing wrong (in the eyes of mojang at least). So I don't see why Forge should cater to a vocal minority, and as cpw's repeatedly stated in the past, he's welcome to discussion, suggestions and negotiation, as long as you go in with an open mind and not "FORGE IS EVIL I DONT WANNA GO NEAR IT", as I've seen is some of the attitudes of base-modding people..
Updates at twitter: https://twitter.com/luacs1998
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumSage, as far as I am aware, MC patcher isn't and never has been in violation of the MC ToU. Which is more than FML and Forge could say until recently. I have no problem with what he is doing - as you can see, FML is now in some ways emulating MC patcher, except it's doing it at runtime, rather than "pre-runtime". My problems with MC patcher were always and remain technical in nature - his method of class patching was causing FML and Forge to have a hard time functioning, and it was NOT obvious why this was the case, and the fact MC patched classes failed to decompile meant it was very difficult to diagnose.
Speaking of optifine, I am working with sp614x on something that many forge and non-forge users should enjoy, more to come on that (hints exist in the FML github!). However that's not relevant for this thread, please ask on twitter or somewhere else, or better yet, just wait.
Kahr, if you wish to work something out, so that we can resume coexistence, I am always available to talk, via twitter, IRC, or even here on PM (though I don't check in as often as I should here).
What do you mean "First with BTW, then with Modloader"??? Sorry I don't use Forge that much so I'm slow when it comes to this stuff. But also doesn't Forge Support Modloader mods???
If I'm wrong, then by all means, tell me
If I wrong about this too, tell me too.
-
View User Profile
-
View Posts
-
Send Message
Retired StaffAs a show of respect to all involved, please DO NOT bring any of it up as arguments here. Just educate yourself to find out why this has stirred up a lot of bad blood.
No, not most of them. Optifine has fallen quite far behind MCPatcher in terms of features. I would honestly be surprised of it ever caught up to the point where it was equal with MCPatcher for use by artists.
Yes, if Optifine ever caught up to MCPatcher. It's never happened, and I doubt it'll suddenly happen now..
No, you're not wrong, but you're talking possibility and not present ability.
It's not that simple. Again, read the thread between my last post and this one. Particularly the last two pages. You'll see CPW post a load of reasons why he believes that Forge compatibility with MCPatcher doesn't work well. Likewise, you'll find out why MCPatcher uses an actual patcher rather than just being a drop-in mod: it avoids shipping Minecraft base classes by using this method. Forge is now doing the same thing, in a very different way, and it's causing this issue.
That's what I'm getting out of this entire thing, anyway. Admittedly I'm just an artist caught in the crossfire here, so my understanding may not be perfect. Apologies to everyone who's offended by my attempts to sum up the situation as fairly as I'm able.
Ok I will do.
Yes this I know. But really the only thing that they don't HAVE is CIT & Biome&Height Based CTM & I think either Better Glass or Better Skies. They also don't have the new V+H & H+V CTM Methods. But other than that, I think they still have all the other texturing features(it's been a while since I lasted checked, so I don't know for sure). Now I know Optifine will NEVER catch up to MCPatcher, as MCPatcher has the advantage of building against the snapshots while Optifine doesn't. This means that MCPatcher can do updates quicker(But then again this means that Optifine has to only update once while MCPatcher does it multiple times, so it's both about the same, BUT STILL). While yes, they don't have all the features of MCPatcher, I want to point out to the people that have said it's either "Good Textures or Mods"(or anything like that), that it is still possible to have both. Maybe not as good as MCPatcher, but still can be done.
While yes I do know all this, I was just talk from a theoretical stand point.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumConraad, this is absurdly off topic, so I will not discuss it further here. If you have a beef with FML or Forge or any "perceived changes", you know where I am : IRC, twitter or PM here.
-
View User Profile
-
View Posts
-
Send Message
Retired StaffAlmost every graphics feature I have in my pack is not supported by Optifine. If you're after the graphics enhancements, Optifine does next to nothing for users of my work. This isn't because of any anti-optifine stance on my part (I love Optifine for what it does), but just because the features that appeal to me aren't included in that mod. From my standpoint, there's very little difference between viewing my pack in strait vanilla and viewing it with Optifine.
This has gone off-topic at this point, though, so the discussion should probably end here. If you want to continue to bat it around, either send me a PM or start a thread in Texture Discussion. Thanks.
AAAHHH, yes Custom Colors!!! Forgot about that. I JUST checked it too. I always look at what Optifine has & don't really look at what's in the files. I just see "Custom Colors" & I'm like OH OK good. I just checked(for the first time)how much of Custom Colors they have & yeah ...
Oh ok. I forgot about that some packs use MCPatcher's way of doing stuff. I was just thinking about my pack(which, because it's NOWHERE close to done, mostly works with Optifine), I forgot about your pack(which by the way, is great! I love it) & other's pack(which I don't usually,expect on rare occasions I test with Optifine).
I love Optifine for what it does too, & I think that's why it's not doing so good in the Tetxure Pack Features area, because it's designed for Lag Reduction & not Texture Packs, unlike MCPatcher.
Yeah we are going off topic. Lol.
Looking forward to some of the remaining bugs in MC Patcher to be fixed so fonts, etc. all look and work right in Sphax.
Thanks for standing up for what you believe in, and for the work you do on this mod.
Visit my Youtube channel here (still empty) if you're a strange gamer!
I'll help you with everything but Lore(cant figure out Lore myself)
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumFonts work for me usually, but ill try out the Sphax Texture Pack & if it works or not for me
I would also like to thank cpw for his measured responses. My post was obviously made in frustration and I appreciate his willingness to keep things from getting out of hand.
I wasn't aware of Grum's statement regarding distribution of modified class files. You'd think an announcement of that magnitude would be a little more prominent than a few tweets, but that's Mojang's professionalism for you. I can see how that puts you in a difficult position and it helps knowing you didn't make this change on a whim.
Still, in my defense, and please take this as constructive criticism, you really could have handled this better. A request is not a requirement, and the best response to Grum is -- well the BEST response is "Sure, give us a proper API and we'll get right on that". But barring that, at the very least you could have waited until you had a more fully-featured patching system in place before springing this on everyone.
Telling people "Sure you can modify base classes, just not any of these: *insert list of every base class anyone cares about*" comes across as glib and insulting. Forge has a spotty reputation as it is, one that goes well beyond one particular mod, and you didn't do yourself any favors here.
I also apologize for missing your PM last year. No slight intended at all. I either missed it entirely in the deluge of PMs I get, or I saw it, put it aside because it was a complex question and simply forgot about it. I rely on decompilation in my own debugging, so I can fully sympathize with your frustration when it isn't working.
I'm willing to work with you on possible compatibility between MCPatcher and forge, but I do insist on maintaining my independence. I have this weekend slated for the backlog of bug reports and remaining 1.6 issues, but I will PM you once I catch up.
I think I may be missing something here, but the birchcolor.png and pinecolor.png of my texture pack have stopped working in 1.6.2. I've spent a very long time making sure everything works perfectly, and now these are the only things that won't--but I've yet to find any simple discussion on simply where I'm supposed to put them now. I've tried colormap and misc, but no matter where I put them, the trees are not affected.
It used to be that I just kept the files in misc with the other biome gradients. What's going on? Where am I supposed to put these images now? I'd greatly appreciate if someone could please explain this to me as if I'm a complete newbie, because all the other discussions seem to be going over my head, and my mind is all mashed up from hours of reworking my pack >.<
Thanks so much to anyone to helps!
-Halley
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumWell,thank you for your reply.
Firstly, a request from Mojang, really should be considered an expectation of delivering results.
The new launcher was sort of (not that I'm claiming responsibility) in response to "we need to be able to control how minecraft runs", which is a prerequirement for any runtime monkey patching.
Note one of it's key capabilities is being able to direct other things to run, not just "vanilla", directly from configuration.
As to timing, well, I promised to myself that as soon as no base class edits were needed, NONE would be distributed, and I try to keep my promises. I made public this intention about 6-7 months ago, when I first figured out how I could monkey patch Minecraft at runtime. This is NOT new news. I have tweet about it repeatedly as pieces of tech falled into place. Sadly, time and resources meant I couldn't complete the "sophisticated" system to my satisfaction, so the "crappy diffs" are the fallback position, but I intended to keep my word.
On "changing classes", we do have a couple of systems we're working out with sp614x, and "don't change these classes" isn't actually mandatory- if you can patch in what fml/forge needs, there's a simple flag that stops the "crash and burn" behaviour and tries to soldier on (sp614x is already using it in optifine, though we have already come up with better ideas).
Finally, editing the minecraft jar is simply a no-no for us, because again, Mojang is gonna start sig checking that thing. It took me a while to convince them not to straight out in 1.6. You can prepend any "modifications" even to base classes, to the classpath right from the launcher, so changing the actual jar should never be considered a necessary step (if you're worried about signature violations, Mojang has code at github.com/Mojang/LegacyLauncher that will step around signature violation checks in normal Java).
I'm certain you could create a "modded.jar" file, and the json to go with it, from mcpatcher very easily (and probably install that version into the launcher while you're at it
Anyway, this is of course, your choice. I'm happy to work with you to try and figure out how mcpatcher and forge can coexist in the future, just as I'm working with sp614x. I suggest following me on twitter (minecraftcpw) if you don't want to be blindsided by these things in the future. Also, if you have any questions, just ping me on twitter, PM or IRC (cpw@esper), if you want to talk further, I'm always happy to engage and solve problems..
I would expect nothing less than complete independence from anything forge, except maybe inside a 'forge compatibility module'.