Minecraft Forums

Ohh I came here with the same greyed out options issue, so I'm glad someone else already ran into it. I want this so that I can run Glimmar's steampunk pack with full functionality.

Download MCPatcher for 1.8 Preview 2: exe jar

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_granite

This means you should use (in your properties file)

 minecraft:stone:2:variant=smooth_granite

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

egg.shell.Rabbit=995f40
egg.spots.Rabbit=734831

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.

The .jar file fails to create a patched jar.

A few bugs in the pre-release:

• Vertical CTM fails on quartz columns (probably because their axis is not stored as a block state)
• Vertical CTM reeds bug is back
• Glass pane CTM fails when faces are specified/CTM applies to all faces of glass panes
• Pane CTM fails on corner panes when connecting in vertical directions
• Enchantment CIT for multi-texture items (such as bows) fails to apply
• Enchantment CIT turns items' base texture black (affects non-CIT enchanted items if CIT-enchanted items are present)
• useGlint=false for CIT messes with screen overlay/GUI color in world when enchanted item is in hotbar
• blend=replace for CIT fails to create side pixels for items when enchantment overlay goes outside item bounds
• Custom colormaps fail to apply to held items/fail to respect block model

I know that many people might already have said this, but, I'm very excited for the 1.8 version of this.

It's all that I need to complete my Resource Pack's development.

So if I'm correct about the naming new naming system, changing the [code] matchBlocks=47 [/code] in the bookshelf properties will now be changed to code] matchBlocks=minecraft:bookshelf [code/] and glass panes will be matchBlocks=minecraft:glass_pane [/code]?[/code]

/\ I hope it is that easy.

Is/Will it posible to change the block/item models for items/blocks using CIT/CTM?

I'm new to color mapping and I was wondering how you do custom wolf collar colors and custom banner colors?

Any help would be appreciated!

cool

Hi! I'm having a lot of fun messing around with the 1.8 preview, so I thought I'd let you know of a few interesting issues I bumped into! I'm not sure all of these are necessarily caused by the patcher, but I figured the more information the better.

Firstly, I noticed that I started experiencing a lot of lag after patching. It was very similar to server lag, except I was in singleplayer. I'd break a block, and it would drop its items, and I could walk over the spot where it had been, except the block would still be there! It would often take several seconds for the block to disappear, and sometimes I'd get to see through the world for a few seconds where it used to be before the textures behind it updated.

Secondly, and way more interestingly, I discovered a weird world generation glitch. I've been playing 1.8 a lot since it came out and did not experience this glitch until after I installed MCPatcher, but I think this may have been a coincidence. However, I'll put it here just in case! I was exploring my recently-generated world, and came across this chunk that didn't seem to have loaded properly.


Once I entered the area past the funky generation (where my character is currently standing), I couldn't move, as if I was stuck in a block. So I logged out and back in, only to discover that the terrain had regenerated! Here's a picture of the exact same spot after I logged in:

So anyways, those are pretty much the only bugs I've experienced so far since I started using the 1.8 preview. Thanks so much for putting so much work in this, it's wonderful!!

Best <3

I'm also seeing delays after breaking blocks (SSP). For example (just ran this test several times from a save), when harvesting two rows of pumpkins about 48 blocks each, I'll see 4-6 separate groups of a few lingering blocks, versus not a single one in vanilla. No obvious difference between patcher previews 1 and 2.

Quote from Kahr»

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.

Phew. Sounds like you've more than had your work cut out for you... Appreciate all the effort you've put forward on this.