MCPatcher is now updated for 1.8.3. See OP for updated download links. Despite being a only minor release there were some significant under-the-hood changes to the game since 1.8.1, including with the Java obfuscation system they use.
I see that forge has been updated for 1.8, but I still have work to do to make MCPatcher compatible with it again. Getting at least basic compatibility going again is likely next on my to-do list.
Small new bonus feature: colormap/underlava.png - does exactly what it says.
- Registered Member
Member for 10 years, 10 months, and 6 days
Last active Fri, Jun, 5 2015 09:57:53
- 13 Followers
- 355 Total Posts
- 1437 Thanks
Feb 26, 2015 Posted in: Resource Packs
Nov 4, 2014A quick 5.0.0_01 update to fix the crashes several of you reported (all seemed to have the same underlying cause). This also fixes some issues with custom mooshroom overlay rendering.Posted in: Resource Packs
The main Windows download link may take a few hours to update, but the alternate link should take you to the new version.
Nov 2, 2014Rather than do another preview, I'm going to go ahead and make this an official release version 5.0.0. It doesn't make sense for me to continue maintaining two separate MCPatcher versions. A number of features are still incomplete in 1.8 however. Download links are in the OP.Posted in: Resource Packs
Changes from 1.8.preview2:
- Updated to 1.8.1.
- Fixed naming of quartz column properties.
- Apply CTM to held items, item frames.
- Do not apply grass color to reeds by default.
- Prevent "leaking" of last inventory item enchantment.
- Fixed crash when dyeing armor.
- Fixed CIT potions.
- Fixed crash in 1.5.2+BTW rendering bloodwood saplings in inventory.
Still TODO (not a complete list):
- Better Grass (side grass texture).
- Better Glass (extra render passes).
- CTM for fluid blocks.
Oct 20, 2014Posted in: Resource Packs
Use the matchBlocks= (or matchTiles=) property within the file instead of relying on the filename. Then it doesn't matter what the file is called. You can also use the weight= property to specify priority instead of relying on the default sorting. Although tile-based matches are always checked before block-based ones.
You may be mixing up two separate things here. symmetry=all means use the same random texture for all faces (n,s,e,w,u,d) of the same block. linked=true means use the same random seed for both parts of a multipart block so that the two halves are synchronized. The linked property is meaningful only for a handful of block types, double plants being one of them, while symmetry is more useful generally.
Before 1.8, "crossed square"-type models like flowers didn't really have faces as far as the game was concerned, so symmetry=all was automatic. I would recommend using the symmetry property explicitly now. It will fix your problem in 1.8 and won't affect the behavior in 1.7.
Try hitting F3 ingame. They added something in 1.8, so when you look at a block it tells you it's info. Spruce Slab would be wooden_slab:variant=spruce Now...something I need help with...my colormaps aren't being read. They work perfectly in 1.7, but not now. Does palette.format=grid not work anymore?
I hadn't noticed that, but it's possble there's a bug there. Could you turn Custom Colors logging to FINE (MCPatcher Options tab) once and see if it is applying the colormaps to the right blocks?
Oct 13, 2014Posted in: Resource Packs
Thanks. Fixed some and added the rest to the todo list.
No, this is different actually. It's about block metadata rather than block names. You really shouldn't be using numeric block IDs anymore even in 1.7, by the way.
In 1.8 things have changed yet again, this time axing numeric metadata, the 0-15 values that differentiate variants of the same block. Mojang switched to a system of named properties and values. I was able to figure out how to convert numeric metadata to the new system in most cases, but it's not perfect and, like numeric block IDs, I can't promise support for it indefinitely.
# Don't do this anymore! matchBlocks=83:0-3 # 1.7 and earlier minecraft:block_name:numeric metadata e.g., minecraft:reeds:0-3 # 1.8 minecraft:block_name:property1=value1,value2:property2=value:... e.g., minecraft:reeds:age=0-3 # Compatible across all versions minecraft:block_name:numeric metadata:property1=value1,value2:property2=value:... e.g., minecraft:reeds:0-3:age=0-3The last format is the one I recommend, especially for new work. And again, the MCPatcher output window will offer a potential conversion that works in most cases, but it's up to you to double-check and update your properties files.
MCP has certainly helped, although I'd gotten pretty knowledgeable of cln.class and its friends without it. Still pretty much limited to weekends for development. 1.8 is really difficult to work with and I just don't have enough time or energy after a day at work.
Gah, I was sure I fixed that. Ok, now it should really be fixed for next time.
MCPatcher doesn't touch that part of the code, so maybe it's just an artifact of the additional load CTM etc. put on the rendering. Tempting as it is, a proper optimization would require some fundamental rearchitecting of the 1.8 code. Things like having to allocate a new "BlockPosition" object every single time I want to look at a neighboring block simply can't be fixed at the bytecode level.
Oddly, your link didn't work for me until I quoted your post and looked at the raw BB code. Thanks, I'll take a look at it. I often make up test packs with dummy textures, but it always helps to have real-world test cases from the community.
Oct 5, 2014Download MCPatcher for 1.8 Preview 2: exe jarPosted in: Resource Packs
Changes since last preview:
- Basic CIT functionality. Item replacements and enchantments appear to work, but have not been extensively tested.
- CTM now tries to auto-convert block:metadata to property=value format. This should be a great help to artists updating their packs to 1.8, but there are limitations. See below for details.
- On the patcher Options tab, you can set Connected Textures logging to Config to force the game to dump all block properties and their possible values on startup. This is a lot of output, so copy it to a text file for easier reference.
- Reimplement CTM connect=tile.
- Reimplement CTM linked=true.
- Better CTM support for special cases like rotated logs, etc.
- Custom wolf collar, armor, sheep, map colors.
- Current features backported to Minecraft 1.5.2. This needs testing with BTW in particular.
- Patcher now remembers its window size and position.
- Many bug fixes.
NOT working yet (partial TODO list):
- Better Grass (side grass texture).
- Better Glass (extra render passes).
- CTM for fluid blocks.
- Custom font colors.
The block:metadata conversion attempts to interpret old numerical metadata values as block state properties. When you have a block:metadata rule with no properties specified, MCPatcher makes its best guess at a proper 1.8 equivalent. Check the output log for messages like
minecraft:mcpatcher/ctm/granite/base.properties: expanded minecraft:stone:2 to variant=smooth_graniteThis means you should use (in your properties file)
minecraft:stone:2:variant=smooth_graniteThe conversion is not perfect, however, and may require manual tweaking, especially for multipart blocks like beds and double plants.
Here are the default rabbit egg spawn colors for color.properties:
The 1.8 update is still a struggle to work with, hence the slow progress. Understanding the code better hasn't really raised my opinion of it much. I still find it brittle and stubbornly resistant to every attempt to swap out textures dynamically, which is the heart of CTM and CIT. All for the sake of the frankly dubious optimization of baking custom model data into int arrays. Which is likely undone by having to allocate a new object for every replacement texture of every face of every model.
Sep 19, 2014Posted in: Discussion
Hear, hear! While I can't say I'm thrilled about the MS deal, Minecraft has been so poorly managed since Notch left it that I'm willing to give it a shot. The lack of a proper API more than three years after new people were hired specifically to work on it and the completely scatterbrained approach to content development are symptoms of the same lack of adult supervision over at Mojang. Whatever else happens I hope MS will inject some sorely-needed professionalism into the project. Or for all we know, MS has been developing a voxel game in secret for two years now and just wanted the brand name so they could slap a "Minecraft 2" label on it.
Sep 15, 2014It's been a while, but I want to do a preview release. Trust me when I say it's very incomplete. Major features are still not implemented and what is there has many, many edge cases still to be dealt with. No testing has been done except on my own computer and it may not even work for you. But you can play around with it if you want.Posted in: Resource Packs
First thing you'll notice is the Mods list is shorter. Custom Textures and Models (CTM, get it?) is intended to cover Connected Textures, Custom Item Textures, and the custom colormaps feature of Custom Colors. All of those things depend (or will depend in the case of CIT which isn't working yet) heavily on Mojang's model system in 1.8 so it was easier for me to combine them. I may break the features up again later, but for now this is what you'll see.
Featurewise, not much visible progress since my last post, as I was stuck on a severe performance problem for several days. Some change Mojang introduced in 1.8-pre2 interacted badly with custom colormaps and caused the game to stutter and slow to single digits if they were enabled. It was only yesterday that I was able to track the problem down.
tl;dr Download MCPatcher 3-2i, so complex it has imaginary parts! exe jar
For the record, I've never had any contact with anyone at Mojang. As far as I know, they are completely unaware of MCPatcher's existence, or still think its only purpose is to hi-res enable packs on old versions of the game.
That isn't my site or my program posted there. It's some other utility with the same name.
Sep 3, 2014Thanks for the support everyone. It's really appreciated. I'll post when I have more progress to report, but a few specific replies for now:Posted in: Resource Packs
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.
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.
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.
Sep 2, 2014I'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.Posted in: Resource Packs
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:variant=oakFor compatibility, these can be combined into:
minecraft:leaves:0,4,8,12:variant=oak1.7 and earlier will ignore the variant=oak part and 1.8 will ignore the metadata values. Both multiple properties:
minecraft:leaves:variant=oak,spruceare 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.
Jun 27, 2014I'm mostly moved in now and have my computer back together again. So here's a quick update to 4.3.2_03 for compatibility with 1.7.10. I haven't even looked at any of the recent snapshots yet, so don't expect it to work post-14w11b.Posted in: Resource Packs
Jun 9, 2014Sorry for the lack of updates recently. I've been in the process of moving, and with all the work that entails, there wasn't much time or energy left for Minecraft modding.Posted in: Resource Packs
Based on a brief look at the recent snapshots, Mojang is still playing with the model.json stuff, the most likely reason for MCPatcher incompatibilities past 14w11. And there's talk of extending the system to items, so any work I did updating to 14w21b probably would have ended up getting tossed anyway. (Frankly, Mojang's characteristic inability to realistically scope anything is exactly why they have yet to produce a proper API after four years. But I digress.)
Anyway the computer I use for development is in storage, so it will likely be a few weeks still before I can fully catch up. Luckily there should still be a couple months before 1.8 is officially released.
Apr 1, 2014MCPatcher is updated to 4.3.2_02 to fix vertical CTM and a couple other issues. See OP for links.Posted in: Resource Packs
Mar 21, 2014Posted in: Resource PacksQuote from r3g1s
MC 1.6.4 + Forge 965, connected textures are not working, even with latest MCPatcher 4.3.2_01
It's definitely working here. Are you sure you're running the patched version? It should be called 1.6.4-Forge184.108.40.2065-mcpatcher.
Quote from JimStoneCraft
All plants that use the cross pattern display wrong with random textures in 14w11b, works fine in 1.7.5.
An accidental feature it seems. Prior to 1.8, "crossed squares" blocks didn't have faces, so both parts always got the same texture. Now in tallgrass.json, they have n, s, e, w faces, so ctm assigns different random textures to them.
Just add this to each properties file to force all faces to use the same texture:
- To post a comment, please login.
Nov 22, 2013By now we've all gotten used to the cycle of Mojang getting distracted from bugfixes to play with a shiny new toy, but they really raised the bar this time. What exactly was the thought process here?Posted in: News
From a business standpoint, twitch.tv obviously benefits, but what does Mojang get out of it? Is a little ad revenue worth tying their flagship game and their players to another company?
On the technical side, why make your game dependent on a third-party feature that 99% of players will never use? Some players can't even start the snapshots because the twitch library is missing or crashing. And the timing. They delay a much-needed 1.7.3 to cram in a major new third-party library dependency. One that by necessity must hook fairly deeply into the rendering code. Is it any surprise that we're already up to 13w47e?
Even the players who do want to stream won't necessarily want to be locked into one streaming service. And presumably the dedicated LPers will continue to post pre-recorded and edited videos, so again I ask, what is the point of this?
- To post a comment, please login.