I've been busily working on MCPatcher. Normally I try to have something ready on or soon after Mojang's releases, but this update is particularly difficult. Progress is happening, but I can't make any promises or offer an ETA yet, so please be patient.
Here's the current (Sep 2) status:
Custom animations, font sizing, analog compass/watch - Done.
Random Mobs - Done.
Better Skies - Done.
Custom Colors - Mostly done. A few odds and ends like armor dyes remain. (Someone actually went through the trouble of rewriting that piece of code and still didn't bother to make the RGB values customizable in vanilla.)
CTM - About 40% done. Some basic CTM features can be now done in vanilla with custom models, so I'm still working through what needs to be done here. A lot of special cases I had in place for things like doors, beds, and rotated logs will have to be completely rethought for 1.8.
Side grass texture (Better Grass) - Not started.
Extra render passes (Better Glass) - Not started, may not even be possible anymore.
CIT - Not started.
An important change for texture pack artists:
The old 0-15 values for block metadata are no longer meaningful in 1.8. So there's a need for a new syntax for applying CTM and custom colormaps to subblocks. The new syntax is based on the block info shown on the F3 screen. Instead of
minecraft:leaves:0,4,8,12
use
minecraft:leaves:variant=oak
For compatibility, these can be combined into:
minecraft:leaves:0,4,8,12:variant=oak
1.7 and earlier will ignore the variant=oak part and 1.8 will ignore the metadata values. Both multiple properties:
minecraft:leaves:variant=oak:decayable=false
and values
minecraft:leaves:variant=oak,spruce
are supported. Integer properties also support ranges (0-3 is the same as 0,1,2,3).
Oh, and if you are still using numerical block IDs anywhere, please use this as an opportunity to switch to names, as the text parser can only do so much.
With that out of the way, pardon me while I vent for a bit.
Warning: Programmer's rant ahead:
This has been by far the most difficult and frustrating update to work with. Notch's code was messy but fairly straightforward once you understood a few basic classes. This new design is so twisted up in endless abstractions and theoretical wankery that I can barely follow it, let alone modify it with any confidence. The number of temporary objects that get allocated and immediately thrown away in the game's critical rendering path is appalling. You can see for yourself on the F3 screen; the Java memory usage is a meaningless blur while the game mercilessly flogs the garbage collector every second. I can't tell you how many times I unironically, reflexively facepalmed upon encountering some new bit of code for the first time.
Several times during this update cycle I've come close to throwing up my hands and walking away from the project altogether, and I still make no guarantees that I won't. I know many artists depend on MCPatcher's features, and I would feel awful if all their hard work and creativity went to waste, but my patience and motivation are really being stretched thin by Mojang's inability to provide a stable platform to build on.
CTM - About 40% done. Some basic CTM features can be now done in vanilla with custom models, so I'm still working through what needs to be done here. A lot of special cases I had in place for things like doors, beds, and rotated logs will have to be completely rethought for 1.8.
...
Extra render passes (Better Glass) - Not started, may not even be possible anymore.
I don't know if it helps the workload at all, but i think anyone with a clue will understand if MCPatcher for 1.8 doesn't have the same feature set as previous versions. Some stuff may no longer be possible. Some stuff may no longer be necessary, or at least as neccesary.
We texture artists love our fancy MCPatcher features, but we'd rather have a happy Kahr, and a more modest and/or delayed MCPatcher, than a full update that might be the last.
Thanks for letting us know what's going on. We really appreciate it.
All I can say is take your time. 1.8 is a HUGE shift. It's obvious even to those of us who haven't waded through Mojang's code. While of course we all want it to be finished right now, anyone with the slightest consideration for others will say that it's better for you to work through at your own pace and not get fed up with it rather than plow through. That wouldn't end well for anyone.
I think it's kind of funny (not in a 'ha ha' way) that this was all done for the modding API... but it seems like all it's done is made modding more of a mess than it already was.
We texture artists love our fancy MCPatcher features, but we'd rather have a happy Kahr, and a more modest MCPatcher, than a full update that might be the last.
This. Absolutely this. I recommend reading these words and living by them.
Believe me, we'll wait. Take your time, do it right, sort through it at your own pace, and when it's ready we'll all be here waiting for you.
Quote from Kahr»
With that out of the way, pardon me while I vent for a bit.
Warning: Programmer's rant ahead:
This has been by far the most difficult and frustrating update to work with. Notch's code was messy but fairly straightforward once you understood a few basic classes. This new design is so twisted up in endless abstractions and theoretical wankery that I can barely follow it, let alone modify it with any confidence. The number of temporary objects that get allocated and immediately thrown away in the game's critical rendering path is appalling. You can see for yourself on the F3 screen; the Java memory usage is a meaningless blur while the game mercilessly flogs the garbage collector every second. I can't tell you how many times I unironically, reflexively facepalmed upon encountering some new bit of code for the first time.
Several times during this update cycle I've come close to throwing up my hands and walking away from the project altogether, and I still make no guarantees that I won't. I know many artists depend on MCPatcher's features, and I would feel awful if all their hard work and creativity went to waste, but my patience and motivation are really being stretched thin by Mojang's inability to provide a stable platform to build on.
Why is it throwing away temporary objects so quickly? That doesn't make sense to me (but then again I barely understand Minecraft's code).
But anyways, thanks for still continuing MCPatcher. I don't want to see this project be stopped. Thanks for being such a great person & keeping this project going.
I don't want to MCPatcher to be discontinued as MCPatcher is so much better than Optifine (texturing wise). But if you truly can't continue the project, I full understand. I will respect your choice.
Thanks for the heads-up. And I also wished something like the API was already out. I honestly believed that 1.8 would have been the "API update", having in mind how long it took :/
The API they said they were going to make was suppose to come out in 1.3, but they postponed it. 1.8 might be a step to them starting creating the API, but I doubt the API will ever come out. I think the API is just a myth that Mojang keeps saying so people will keep playing Minecraft. The API has been rumored for since around Alpha. Notch said he will create a Modding API since Alpha, but look. It's been about 3(or 4?) years since Alpha & still no API.
The API they said they were going to make was suppose to come out in 1.3, but they postponed it. 1.8 might be a step to them starting creating the API, but I doubt the API will ever come out. I think the API is just a myth that Mojang keeps saying so people will keep playing Minecraft. The API has been rumored for since around Alpha. Notch said he will create a Modding API since Alpha, but look. It's been about 3(or 4?) years since Alpha & still no API.
Yeah, Notch did give an API target date long ago before he has started working on it, or (apparently) even had much of an idea what it would entail. Then Mojang stopped promising it on specific dates and hired the developers of Bukkit to make it happen. What they decided was to make a Plugin API that wouldn't break every update, and to do that they needed to regularize, streamline or rebuild most of Minecraft's systems.
If you pay attention most of the work that goes on at Mojang is not user-facing, but improvements to MC's insides. Some of these may merely improve performance, but most are steps toward making a good API possible. Switching from block IDs to ID names is one piece of important ground-work they laid with 1.8. Control of block and item geometry moving from hard-coding to accessible script files is another.
If you pay attention most of the work that goes on at Mojang is not user-facing, but improvements to MC's insides. Some of these may merely improve performance, but most are steps toward making a good API possible. Switching from block IDs to ID names is one piece of important ground-work they laid with 1.8. Control of block and item geometry moving from hard-coding to accessible script files is another.
Yeah I knew this. I understand all the changes to the game are to help create an API, but there are a lot more stuff they can add to the game to make the API faster then adding stuff like Banners or Rabbits. Don't get me wrong, I love that they add new stuff, but I would worry more about the API then additions.
I agree with that. Up until the snapshot that introduced the Sea Temples, I believed that 1.8 wouldn't have anything special added to it except commands, a few new blocks and hopefully the API, and I was OK with that. Yeah, I absolutely LOVE the new stuff, but it wouldn't have been a trauma for me if they dedicated an entire new version on rearranging the game's insides (OK, that sounded a bit...visceral :D), fixing bugs and releasing the API...
I hope it doesn't get much further than in 1.9...
True, if they didn't add anything in an update that would be annoying, but understandable. The Smaller updates (1.7.9, 1.7.10, & updates that change the last number) are really just bug fixes. So I guess when Mojang adds stuff to updates it's not that bad.
Yeah I knew this. I understand all the changes to the game are to help create an API, but there are a lot more stuff they can add to the game to make the API faster then adding stuff like Banners or Rabbits.
If you pay attention to the timeline you'll get nothing user visible from a dev for weeks and even months, and then for a few days they'll be posting screenshots of a new blocks or mob. I doubt any one of them (except possibly Jeb) spent more than a couple weeks of work hours during 1.8 on anything external.
Skipping any new features wouldn't do much to speed up the API, would annoy lots of players, and would deprive the Mojang coders of a nice break from the unglamorous, gritty coding they spend most of their time doing.
If you pay attention to the timeline you'll get nothing user visible from a dev for weeks and even months, and then for a few days they'll be posting screenshots of a new blocks or mob. I doubt any one of them (except possibly Jeb) spent more than a couple weeks of work hours during 1.8 on anything external.
Skipping any new features wouldn't do much to speed up the API, would annoy lots of players, and would deprive the Mojang coders of a nice break from the unglamorous, gritty coding they spend most of their time doing.
Notch's code was messy but fairly straightforward once you understood a few basic classes. This new design is so twisted up in endless abstractions and theoretical wankery that I can barely follow it, let alone modify it with any confidence
I saw this quoted elsewhere, and I just wanted to pop into this thread to say that I agree 100%. I'm someone who doesn't normally do deobfuscation, I only once did it for fun to an old alpha version of the game, taking it apart fairly completely and then modding it a bit. It was one of the best puzzles I ever "solved" because there was solid method to the madness. Lately I decided to try my hand at it again, and have been working with the 1.8 pre-releases, writing my own tools to help with the process along the way, having gotten the client remapped to generic names, eventually clearing up the remaining errors to successfully recompile and run. But I'm still left facing a monster of almost 2500 classes, all intertwined and relying on third-party libraries, all of which I'm convinced I wouldn't even be able to deobfuscate half of by myself. The version I took apart was just shy of 400 classes, for reference. It was old, certainly, but when you consider that even 1.6.4 had almost a thousand less classes than 1.8, I think that's saying something. And you're in rendering code that's a far scarier place than where I've been looking so far!
Anyway, I don't want to crap on Mojang, I mostly just want to say that you said exactly what I've been thinking, but you worded it better than I would have.
@Kahr: thanks for trying to stick with it bud. you have been a driving force in minecraft since you took over this project oh so long ago. I am honestly amazed that you are still trying this hard. I still remember the early days when I would come to you with "is it possible to do this" questions, and you replying with " no, but I have an idea" and seeing it possible in the next update. (or nudging Misa to ask you...lol) it would be a shame to see this come to an end... I can only hope that if you do walk away from it out of frustration that the community raises a bigger stink about it than Doku's war against mixpacks.
edit: I'm also with eleazzaar & XSSheep on this one. A smaller feature package over a full update may be the best way to go. With all the changes to what we can accomplish in vanilla maybe it's time to take a step back from ctm to give yourself more time to fiddle with it and see what actually needs to be implemented in the patcher as a full feature, and what can just be made to work with the ability to add some of it's functionality with the custom models.
I agree with eleazzaar, would much prefer a simpler feature set and a happy kahr over the full mcpatcher feature set and a sad kahr. In any case, big thanks for sticking with this as long as you have and another huge thanks for working on an update for 1.8!
EDIT: Your donate link seems to be broken. Will chuck some thanks money your way as thanks when you get it up and working again.
Yep. As I said, if I were in charge in Mojang, my roadmap for 1.9 would be entirely:
- Finish rewriting the parts of the game that needs rewriting.
- Bugfixing. Tons and tons of bugfixing, cleaning and optimizing code, etc.
- Finishing and releasing the API.
- (Optional, and only if they doesn't introduce any more problems or bugs): Add some small funny blocks/stuff.
I think the community can handle a single version without new features (AFAIK, it'd be the very first one doing so since the game's beginning). Minecraft needs it, and the modding community would take a biiiig respite.
So please, Mojang. Make a pause in adding stuff and make 1.9 "The Bugfix/API Update" once and for all. If all the new versions of the game would be released on console as well as on PC, I'd understand releasing new stuff with every version, as console users care nothing about mods and API's. But I dare to say that most of the MC PC users are dependant on Bukkit/Spigot (I can't enter my favourite server with 1.8 right now, for example), and also a LOT of PC users uses one mod or another. And all these people have to wait 3-6 months since release to "fully" enjoy their game again.
I'm not against big changes if they're needed. But I think what Mojang has done is more:
- Rewrite a bit of code (= Nightmare for modders).
(Next version):
- Rewrite a bit of code (= Nightmare for modders).
(Next version):
- Rewrite a bit of code (= Nightmare for modders).
(Next version):
Instead of:
- After X months of work, a big rewrite of the game (= Nightmare for modders).
(Period).
I think it's not a matter of rewriting stuff, but how they've planned it. Instead of making it a single pain in the ****, they split it up and made it a pain in the **** for every version they released.
The API they said they were going to make was suppose to come out in 1.3, but they postponed it. 1.8 might be a step to them starting creating the API, but I doubt the API will ever come out. I think the API is just a myth that Mojang keeps saying so people will keep playing Minecraft. The API has been rumored for since around Alpha. Notch said he will create a Modding API since Alpha, but look. It's been about 3(or 4?) years since Alpha & still no API.
The API's been "just over the next hill" for a long time now, and yeah, I'm pretty pessimistic on it actually seeing the light of day too. I think Mojang thinks they're working toward the API, but I'm afraid that (1) all these architectural changes are driving away their experienced modders, and (2) assuming Mojang finishes it at all, their API will be so over-engineered as to be unapproachable to newcomers.
Thanks for posting that, I really enjoyed reading it! I have a similar process that also starts with a decompiled (no MCP, just JAD) version of the latest snapshot or release. But I don't bother getting it to compile as it's just a reference. After I figure out what an obfuscated class does and assign it a name, I write one or more signatures (bytecode-aware regular expressions, basically) to identify the same class in the later versions. That's how MCPatcher can often work on newer Minecraft versions than it was written for.
I am sorry to hear what you are going through, mojang's code has given a lot of troubles to the coders in my community as well. I even had this half serious joke about bukkit being screwed now that Mojang will be updating it.
I came to realize how long I have been using your mod without even thanking you. Back when I was a texturepack developer for The Voxel Box, I remember how your mod revolutionized the possibilities for us in our creative community. Without your mod, our servers wouldn't be the same I won't forget to thank you this time however.
Thank you! On behalf of me, but also the community I am currently a part of: The Dream Sanctuary =)
Kahr, you take a big heaping pile of code that Mojang gives and tweak and manipulate the wired mess of weird to make a platform that us artists can create epic awesomeness. Your work is an excellent foundation for artists (and honestly I wonder why Mojang didn't actually hire you into the texture coding department. You could have a 'plugin api' done that would make their heads spin because you actually listen to the artists who make packs.) I have always been happy with the work you have done to ensure the Patcher's success. I truly appreciate your hard work and dedication. Your MCPatcher has been around almost as long as some of the longest running packs in this forum and PMC.
Do what you can and hopefully Mojang will simply keep their cool for the next few months aside from small bug fixes so all the coders can untangle the web of 'What the...' they have given us.
Here's the current (Sep 2) status:
An important change for texture pack artists:
The old 0-15 values for block metadata are no longer meaningful in 1.8. So there's a need for a new syntax for applying CTM and custom colormaps to subblocks. The new syntax is based on the block info shown on the F3 screen. Instead of
use
For compatibility, these can be combined into:
1.7 and earlier will ignore the variant=oak part and 1.8 will ignore the metadata values. Both multiple properties:
and values
are supported. Integer properties also support ranges (0-3 is the same as 0,1,2,3).
Oh, and if you are still using numerical block IDs anywhere, please use this as an opportunity to switch to names, as the text parser can only do so much.
With that out of the way, pardon me while I vent for a bit.
Warning: Programmer's rant ahead:
This has been by far the most difficult and frustrating update to work with. Notch's code was messy but fairly straightforward once you understood a few basic classes. This new design is so twisted up in endless abstractions and theoretical wankery that I can barely follow it, let alone modify it with any confidence. The number of temporary objects that get allocated and immediately thrown away in the game's critical rendering path is appalling. You can see for yourself on the F3 screen; the Java memory usage is a meaningless blur while the game mercilessly flogs the garbage collector every second. I can't tell you how many times I unironically, reflexively facepalmed upon encountering some new bit of code for the first time.
Several times during this update cycle I've come close to throwing up my hands and walking away from the project altogether, and I still make no guarantees that I won't. I know many artists depend on MCPatcher's features, and I would feel awful if all their hard work and creativity went to waste, but my patience and motivation are really being stretched thin by Mojang's inability to provide a stable platform to build on.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumJust a simple thank you for all the hard work. That's all. I know you will get 1.8 out as soon as you can.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumWe texture artists love our fancy MCPatcher features, but we'd rather have a happy Kahr, and a more modest and/or delayed MCPatcher, than a full update that might be the last.
Hats off to you for sticking with it this long!
• Follow Lithos on Twitter for release announcments
* Join the Lithos Discord for previews and to help
-
View User Profile
-
View Posts
-
Send Message
Retired StaffThanks for letting us know what's going on. We really appreciate it.
All I can say is take your time. 1.8 is a HUGE shift. It's obvious even to those of us who haven't waded through Mojang's code. While of course we all want it to be finished right now, anyone with the slightest consideration for others will say that it's better for you to work through at your own pace and not get fed up with it rather than plow through.
I think it's kind of funny (not in a 'ha ha' way) that this was all done for the modding API... but it seems like all it's done is made modding more of a mess than it already was.
This. Absolutely this. I recommend reading these words and living by them.
Believe me, we'll wait. Take your time, do it right, sort through it at your own pace, and when it's ready we'll all be here waiting for you.
Why is it throwing away temporary objects so quickly? That doesn't make sense to me (but then again I barely understand Minecraft's code).
But anyways, thanks for still continuing MCPatcher. I don't want to see this project be stopped. Thanks for being such a great person & keeping this project going.
I don't want to MCPatcher to be discontinued as MCPatcher is so much better than Optifine (texturing wise). But if you truly can't continue the project, I full understand. I will respect your choice.
The API they said they were going to make was suppose to come out in 1.3, but they postponed it. 1.8 might be a step to them starting creating the API, but I doubt the API will ever come out. I think the API is just a myth that Mojang keeps saying so people will keep playing Minecraft. The API has been rumored for since around Alpha. Notch said he will create a Modding API since Alpha, but look. It's been about 3(or 4?) years since Alpha & still no API.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumYeah, Notch did give an API target date long ago before he has started working on it, or (apparently) even had much of an idea what it would entail. Then Mojang stopped promising it on specific dates and hired the developers of Bukkit to make it happen. What they decided was to make a Plugin API that wouldn't break every update, and to do that they needed to regularize, streamline or rebuild most of Minecraft's systems.
If you pay attention most of the work that goes on at Mojang is not user-facing, but improvements to MC's insides. Some of these may merely improve performance, but most are steps toward making a good API possible. Switching from block IDs to ID names is one piece of important ground-work they laid with 1.8. Control of block and item geometry moving from hard-coding to accessible script files is another.
• Follow Lithos on Twitter for release announcments
* Join the Lithos Discord for previews and to help
Yeah I knew this. I understand all the changes to the game are to help create an API, but there are a lot more stuff they can add to the game to make the API faster then adding stuff like Banners or Rabbits. Don't get me wrong, I love that they add new stuff, but I would worry more about the API then additions.
True, if they didn't add anything in an update that would be annoying, but understandable. The Smaller updates (1.7.9, 1.7.10, & updates that change the last number) are really just bug fixes. So I guess when Mojang adds stuff to updates it's not that bad.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumIf you pay attention to the timeline you'll get nothing user visible from a dev for weeks and even months, and then for a few days they'll be posting screenshots of a new blocks or mob. I doubt any one of them (except possibly Jeb) spent more than a couple weeks of work hours during 1.8 on anything external.
Skipping any new features wouldn't do much to speed up the API, would annoy lots of players, and would deprive the Mojang coders of a nice break from the unglamorous, gritty coding they spend most of their time doing.
At least that's how i interpret things.
• Follow Lithos on Twitter for release announcments
* Join the Lithos Discord for previews and to help
True
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI saw this quoted elsewhere, and I just wanted to pop into this thread to say that I agree 100%. I'm someone who doesn't normally do deobfuscation, I only once did it for fun to an old alpha version of the game, taking it apart fairly completely and then modding it a bit. It was one of the best puzzles I ever "solved" because there was solid method to the madness. Lately I decided to try my hand at it again, and have been working with the 1.8 pre-releases, writing my own tools to help with the process along the way, having gotten the client remapped to generic names, eventually clearing up the remaining errors to successfully recompile and run. But I'm still left facing a monster of almost 2500 classes, all intertwined and relying on third-party libraries, all of which I'm convinced I wouldn't even be able to deobfuscate half of by myself. The version I took apart was just shy of 400 classes, for reference. It was old, certainly, but when you consider that even 1.6.4 had almost a thousand less classes than 1.8, I think that's saying something. And you're in rendering code that's a far scarier place than where I've been looking so far!
Anyway, I don't want to crap on Mojang, I mostly just want to say that you said exactly what I've been thinking, but you worded it better than I would have.
WIP site for my mods / Intermediary / FMC / Redstone Paste / Hopper Ducts / Model Citizens / Simple Refinement / Endermanage / Fycraft / etc
-
View User Profile
-
View Posts
-
Send Message
Curse Premiumedit: I'm also with eleazzaar & XSSheep on this one. A smaller feature package over a full update may be the best way to go. With all the changes to what we can accomplish in vanilla maybe it's time to take a step back from ctm to give yourself more time to fiddle with it and see what actually needs to be implemented in the patcher as a full feature, and what can just be made to work with the ability to add some of it's functionality with the custom models.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumEDIT: Your donate link seems to be broken. Will chuck some thanks money your way as thanks when you get it up and working again.
Agree on both
The API's been "just over the next hill" for a long time now, and yeah, I'm pretty pessimistic on it actually seeing the light of day too. I think Mojang thinks they're working toward the API, but I'm afraid that (1) all these architectural changes are driving away their experienced modders, and (2) assuming Mojang finishes it at all, their API will be so over-engineered as to be unapproachable to newcomers.
Thanks for posting that, I really enjoyed reading it! I have a similar process that also starts with a decompiled (no MCP, just JAD) version of the latest snapshot or release. But I don't bother getting it to compile as it's just a reference. After I figure out what an obfuscated class does and assign it a name, I write one or more signatures (bytecode-aware regular expressions, basically) to identify the same class in the later versions. That's how MCPatcher can often work on newer Minecraft versions than it was written for.
Thanks, should be working now. It must have gotten mangled by one of the forum software upgrades. I don't get many donations, so I just never noticed.
I came to realize how long I have been using your mod without even thanking you. Back when I was a texturepack developer for The Voxel Box, I remember how your mod revolutionized the possibilities for us in our creative community. Without your mod, our servers wouldn't be the same
Thank you! On behalf of me, but also the community I am currently a part of: The Dream Sanctuary =)
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumDo what you can and hopefully Mojang will simply keep their cool for the next few months aside from small bug fixes so all the coders can untangle the web of 'What the...' they have given us.
Thank you again for all the hard work man-SRD