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.
or maybe it's Forge that doesn't work with mcpatcher
It's a little bit of both I'd guess. Regardless Kahr is going to have to be the one to fix it since the makers of Forge don't seem to have much consideration for the Resource Pack community.
It is maybe added, but when I patch it (and yes I checked it) it still doesnt work, atleast not on glass.
What pack are you using? It's possible the pack just isn't updated.
Also, are you certain you're selecting the MCPatcher profile in the launcher? I've seen a LOT of people miss this crucial step and continue to try unaltered vanilla, wondering all the while why it doesn't seem any different.
Yes I do have selected the right profile, I also tried on 3 different resource packs including the default one, not working on all.
Mind telling me how I show you the properties?
You won't see a change in the default pack because Mojang has never included CTM files in it.
Now WHICH packs have you tried? This is important since CTM doesn't impose changes on any packs. Rather, the pack may or may not use CTM. Saying "three different packs" tells me nothing since it's possible that NONE of those packs actually use CTM at all.
Also, Mark assumed you were making your own pack rather than using ones made by other people. Unless you are making a pack and I'm just misunderstanding you, his question isn't really relevant.
Also, Mark assumed you were making your own pack rather than using ones made by other people. Unless you are making a pack and I'm just misunderstanding you, his question isn't really relevant.
Hi, so I'm attempting to make a texture for nether bricks that is connected like normal, but each tile is randomized from a set of tiles that would fit in that spot, so that it looks something like figure A. What I'm getting, however, looks more like figure B. Any thoughts as to why this might be happening?
ATTACHMENTS
FigureA
FigureB
Rollback Post to RevisionRollBack
Don't sweat the petty things, and don't pet the sweaty things.
I second that second. Possibly make it so you can change the texture used based on some nbt tags (like a custom name) on any container?
Having it changed based on name, at least, should be possible since the name is called with and rendered over the GUI image for chests. Not sure about other containers, though.
Having it changed based on name, at least, should be possible since the name is called with and rendered over the GUI image for chests. Not sure about other containers, though.
And yes please!
I should check but I think it sends the name regardless, alternatively it might be possible to access the tileentitity directly.
Edit: All container based guis are initialised with an IInventory that supports GetDisplayName so it would be possible to change the texture based on display name for any of those (Horses too).
Hi, so I'm attempting to make a texture for nether bricks that is connected like normal, but each tile is randomized from a set of tiles that would fit in that spot, so that it looks something like figure A. What I'm getting, however, looks more like figure B. Any thoughts as to why this might be happening?
You want to use vertical ctm for your blocks and then apply a random ctm to the top and bottom tiles. A bit like what I've done with sandstone.
Hi, so I'm attempting to make a texture for nether bricks that is connected like normal, but each tile is randomized from a set of tiles that would fit in that spot, so that it looks something like figure A. What I'm getting, however, looks more like figure B. Any thoughts as to why this might be happening?
I think, a possibility would be , if you change the method like this:
You want to use vertical ctm for your blocks and then apply a random ctm to the top and bottom tiles. A bit like what I've done with sandstone.
The issue with that is that it doesn't allow me to have the left and right edges curved properly (see fig. C); I've currently got it using classic CTM, with each of the 47 tiles calling for one of the randomized tiles, like so:
The issue with that is that it doesn't allow me to have the left and right edges curved properly (see fig. C); I've currently got it using classic CTM, with each of the 47 tiles calling for one of the randomized tiles, like so:
Ah, I see. That is a very complicated way of doing it though. It could be you've made a mistake in block112.properties.
I'd recommend you try switching it around. So apply a random ctm directly to the block and apply a default one to each random tile. That will make it easier to see what's happening and allow you to add more variations more easily.
I'd recommend you try switching it around. So apply a random ctm directly to the block and apply a default one to each random tile. That will make it easier to see what's happening and allow you to add more variations more easily.
I currently have 9 variations for solid-top and solid-bottom blocks (each of which has the left-, both-, right-, and no-connection variants), and 26 variations of the bricked pattern (also with left-, both-, right-, and no-connection variants), so that'll be the original NetherBricks.properties doing a randomized call for one of 26 classic CTM properties files... Tedious as hell, but I'll try it.
Update:
Okay, now I'm getting nothing but default nether bricks. My files now look like this:
Note: for each of the textures, the number represents vertical connectivity, the first letter is horizontal connectivity, and the second letter is the variation.
Update:
I've cycled through the classic CTM files, changing each matchTiles line to be matchBlocks=nether_brick to make sure that they were working properly, and they are. Perhaps the random method doesn't take input from other methods?
Update:
I've cycled through the classic CTM files, changing each matchTiles line to be matchBlocks=nether_brick to make sure that they were working properly, and they are. Perhaps the random method doesn't take input from other methods?
I think as long as the random method is working the other rules should apply themselves to it.
You can try changing:
matchBlocks=nether_brick nether_brick_stairs
to
blocks=nether_brick nether_brick_stairs
It might not make a difference but that's what I've used before and it seems to work.
You should also check that all the texture files (a.png - z.png) exist otherwise MCPatcher will just ignore that rule.
Edit: Also the faces and method aren't needed in the other properties file. Method defaults to ctm when it's not given and the textures those rules replace will only be found on the sides as specified by the first properties file.
That is what Kahr is most likely working on right now.
-
View User Profile
-
View Posts
-
Send Message
ModeratorIt's a little bit of both I'd guess. Regardless Kahr is going to have to be the one to fix it since the makers of Forge don't seem to have much consideration for the Resource Pack community.
(use the F3 screen to see the metadata for any block)
It is added. CTM & CIT have been combined into "Custom Textures and Models"
-
View User Profile
-
View Posts
-
Send Message
ModeratorWhat pack are you using? It's possible the pack just isn't updated.
Also, are you certain you're selecting the MCPatcher profile in the launcher? I've seen a LOT of people miss this crucial step and continue to try unaltered vanilla, wondering all the while why it doesn't seem any different.
Show us pics & your CTM .properties file for glass
-
View User Profile
-
View Posts
-
Send Message
ModeratorYou won't see a change in the default pack because Mojang has never included CTM files in it.
Now WHICH packs have you tried? This is important since CTM doesn't impose changes on any packs. Rather, the pack may or may not use CTM. Saying "three different packs" tells me nothing since it's possible that NONE of those packs actually use CTM at all.
Also, Mark assumed you were making your own pack rather than using ones made by other people. Unless you are making a pack and I'm just misunderstanding you, his question isn't really relevant.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumOh, then I misunderstood everything!
-
View User Profile
-
View Posts
-
Send Message
ModeratorI would like to second this! I don't know how feasible this is with MCPatcher, but if it is it would be another nice little addition.
I second that second. Possibly make it so you can change the texture used based on some nbt tags (like a custom name) on any container?
-
View User Profile
-
View Posts
-
Send Message
ModeratorHaving it changed based on name, at least, should be possible since the name is called with and rendered over the GUI image for chests. Not sure about other containers, though.
And yes please!
I should check but I think it sends the name regardless, alternatively it might be possible to access the tileentitity directly.
Edit: All container based guis are initialised with an IInventory that supports GetDisplayName so it would be possible to change the texture based on display name for any of those (Horses too).
You want to use vertical ctm for your blocks and then apply a random ctm to the top and bottom tiles. A bit like what I've done with sandstone.
None below:
None above:
None above or below:
It might need some adjustments since I just typed this up as an example.
Edit: MCFs pls
Edit2: Pls, MCFs. Stahp.
Edit3: The hell, STOP MANGLING MY POSTS
Edit: *cries*
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI think, a possibility would be , if you change the method like this:
matchBlocks=minecraft:netherbricks:variant=netherbricks
tiles=0-12
height=4
width=3
method=repeat
Because if you randomize ,it would randomize all, also the bottom png.s and the result will be as in your figure B......
The issue with that is that it doesn't allow me to have the left and right edges curved properly (see fig. C); I've currently got it using classic CTM, with each of the 47 tiles calling for one of the randomized tiles, like so:
Ah, I see. That is a very complicated way of doing it though. It could be you've made a mistake in block112.properties.
I'd recommend you try switching it around. So apply a random ctm directly to the block and apply a default one to each random tile. That will make it easier to see what's happening and allow you to add more variations more easily.
...etc
Edit: MCFs pls, not again.
I currently have 9 variations for solid-top and solid-bottom blocks (each of which has the left-, both-, right-, and no-connection variants), and 26 variations of the bricked pattern (also with left-, both-, right-, and no-connection variants), so that'll be the original NetherBricks.properties doing a randomized call for one of 26 classic CTM properties files... Tedious as hell, but I'll try it.
Update:
Okay, now I'm getting nothing but default nether bricks. My files now look like this:
Note: for each of the textures, the number represents vertical connectivity, the first letter is horizontal connectivity, and the second letter is the variation.
Update:
I've cycled through the classic CTM files, changing each matchTiles line to be matchBlocks=nether_brick to make sure that they were working properly, and they are. Perhaps the random method doesn't take input from other methods?
I think as long as the random method is working the other rules should apply themselves to it.
You can try changing:
to
It might not make a difference but that's what I've used before and it seems to work.
You should also check that all the texture files (a.png - z.png) exist otherwise MCPatcher will just ignore that rule.
Edit: Also the faces and method aren't needed in the other properties file. Method defaults to ctm when it's not given and the textures those rules replace will only be found on the sides as specified by the first properties file.