Minecraft Forums

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.

Quote from kwerti»

A few bugs in the pre-release:

Thanks. Fixed some and added the rest to the todo list.

Quote from diam_0nd»

So if I'm correct about the naming new naming system, changing the

 matchBlocks=47 

in the bookshelf properties will now be changed to code] matchBlocks=minecraft:bookshelf [code/] and glass panes will be matchBlocks=minecraft:glass_pane ?

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.

For comparison

 # 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-3

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

Quote from thecrazydudesrd»

Kahr I'm still very glad that Better Glass is still on the table! I had almost lost all hope of it actually being implemented. Did the MCP help you in any way?

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.

Quote from MasterfulGamer»

MCPatcher is still tinting reeds even though disabled with block models

Gah, I was sure I fixed that. Ok, now it should really be fixed for next time.

Quote from Halite»

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.

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.

Quote from thecrazydudesrd»

Most of my textures after manually converting is alright but also still dealing with stone textures using heights having random changes as I move around. If you want to see what I'm talking about give this a whirl - My MCPatcher addon test for 1.8

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.

Quote from loki_of_sassgard»

How do you name properties files when you have several of them for the same block? The only way I can find to get it to work is to still use the numeric value (block3.properties, block3a.properties, et cetera). Is there a way to get that to work using the block names?

You have to use the weight= property, which determines the order in which the files are loaded. Higher weights are loaded first.

Question (only for experience):

Can be added a custom Connection models (block models) support? Like connect textures.

Example: the fences, redstone wire, glass pane, etc.

or

Can be support CTM for custom block models?

Yes, you can add random models, in vanilla Minecraft, but I lack the skills on knowing how to. CTM for block models should theoretically work, but you have to make sure they have the same shape as the model, otherwise you may end up with blank spots, or stretched out areas