Kahr, I'm very glad you fixed the bug with Mekanism. But from mcpatcher-4.3.1_01 to mcpatcher-4.3.2, all glass and iron fence blocks of the resource pack I use (http://www.planetminecraft.com/texture_pack/aeon-1355543/) and a few others became completely invisible or renders white.
Reported earlier, renderPass 2 and 3 aren't currently working with Forge. Another instance where we both modify the exact same line of code and it requires some tricky merging on my part. Fixed for next release.
I know that this has probably been requested before (by me, perhaps), and there are still lots of bugs that people are reporting, but adding the ability to make custom skies biome-specific would be a god send.
The problem with that is keeping so many large skybox textures in memory at once in order to smoothly transition between them.
So it seems that the random mobs feature is selecting a random colour for my animals each time the chunk is loaded, not just the first time! Is this supposed to happen?
Ah, I've tried several times and never been able to nail this bug down since the SSP/SMP merge. In singleplayer it's supposed to save the skin used to the NBT data when it saves the chunk. And it worked perfectly in 1.2 and still mostly works now. But not always as you've noted.
For multiplayer, it's more complicated, but as long as the chunk stays loaded on the server it should get the same skin each time until it is rebooted. That's the best that can be done without patching the server code.
Well, maybe. If you're actively trying to patch 14w06b and CTM is grayed out, then it might not quite be compatible,
I probably broke compatibility with 14w06b when I updated to 14w08a. The custom block model code changed so much between the two versions (and again in 14w10, which I'm currently dealing with) that it no longer recognizes one of the classes. I'll see if there's an easy fix, but no promises.
Just thought I'd ask this again, since it appears to have gotten lost in the deluge and rapidly approaching forgotten as well, and I'd really rather get it over with before putting it behind us. Then it can be lost and forgotten again.
I made a small program that extracts the things mcpatcher adds to the jar and puts it in a new one in the form of a library. Right now, it can't tell if forge is installed, but it won't matter if you're just going to move the library into FTB. I may package it in a bit.
Interesting, but if I'm understanding this right, don't you still have to install Forge via MCPatcher and use that patched jar as input to your program for this to work? Otherwise none of Forge's base class changes will be in the library.
For example, with smooth granite, i am trying to use vertical ctm, but make each vertical tile repeat horizontally, then have a seperate texture for the top/bottom faces. Only the base vertical ctm is working. It won't repeat, and it won't apply the face specific ctm.
Quick question since block ids are being phased out entirely is it possible to specify renderpass with MatchBlocks or MatchTiles?
matchBlocks yes, matchTiles no. I would strongly recommend getting out of the habit of relying on naming your files block###.properties though. There's no telling when Mojang will remove the last vestiges of numerical IDs.
java.lang.ArrayIndexOutOfBoundsException: 12
at com.prupe.mcpatcher.cc.ColorizeBlock.setupBiomeSmoothing(ColorizeBlock.java:494)
at com.prupe.mcpatcher.cc.ColorizeBlock.setupBlockSmoothing(ColorizeBlock.java:470)
I think there is a bug here as that "connect=block" shouldn't be necessary. I'll look into it more.
More or less. By repeat horizontally i meant repeat ctm, but in a single block high multiple block wide horizontal pattern.
Also, just plain repeat ctm with "faces=top bottom" not relying on the output of another properties isn't working either.
All of my plank textures use all of these ctm methods together with no problem. I've never heard of "connect=block" before, but i'll give it a try and let you know what happens. Thanks
Edit: I just tried it. Unfortunately adding "connect=block" had no effect.
Reported earlier, renderPass 2 and 3 aren't currently working with Forge. Another instance where we both modify the exact same line of code and it requires some tricky merging on my part. Fixed for next release.
Great man! Looking forward to downloading the next release. Thank you!
When I open MCpatcher, connected textures is grayed out. The only options under the mods tab not grayed out are Extended HD, Better Skies, and Custom Item textures.How do I get MCpatcher to recognize the Conquest resource pack?
I really like the new 'heights= array of heights. Would it be possible to add a variable to give it some jitter so long as it's on the same block?
I've got a 5 toned stone with multiple layers to give it a strata effect, it looks alright now and I could use biomes to variate the strata too. I was just wondering if the variable could be done? Maybe have a 'jitterweight' to make a weight based setup as to what 'room' is available?
I dunno, I'm just thinking aloud. I'm still happy with the product.
Why is this mod pinned anyways?
There are loads of better mods out there than this..
Notice that it's in the resource packs section, rather than in the mods section. Rather than effecting gameplay in any way, this mod is more of a graphical expansion. It's a framework for texture packs to be built upon, allowing texture artists to do some incredible things, far beyond the single texture per block that vanilla minecraft allows.
With mcpatcher, minecraft can look absolutely amazing. Texture artists can be much more creative. For example, have you ever seen swamp flies in minecraft? In my texture pack, you'll occasionally come across flies hovering around in circles in a swamp. It doesn't sound like much, but it does a lot to create an atmosphere. I was able to retexture a bit of grass into a fly, animate it, and make it replace just a few random patches of grass, and only in swamps because of mcpatcher. But that's just one of an endless number of options it provides.
Texture artists are pretty much the only ones who will ever truly appreciate just how much this mod does. Texture pack users might give all the credit to the artists who made the pack using mcpatcher's features, but without mcpatcher, some of the most amazing packs out there would look horrible.
It may not do anything gameplay wise, but that doesn't mean it has no merit as a mod. It's pinned in the resource pack section because it deserves to be. Because without it, a lot of resource packs just won't live up to their potential. If a resource pack says it requires mcpatcher, you better be using mcpatcher.
But i seem to be doing a lot of rambling here, to answer your question in TL;DR fashion: Mcpatcher is pinned here because many resource packs require it to function properly.
Notice that it's in the resource packs section, rather than in the mods section. Rather than effecting gameplay in any way, this mod is more of a graphical expansion. It's a framework for texture packs to be built upon, allowing texture artists to do some amazing things, far beyond the single texture per block that vanilla minecraft allows.
With mcpatcher, minecraft can look absolutely amazing. Texture artists can be much more creative. For example, have you ever seen swamp flies in minecraft? In my texture pack, you'll occasionally come across flies hovering around in circles in a swamp. It doesn't sound like much, but it does a lot to create an atmosphere. I was able to retexture a bit of grass into a fly, animate it, and make it replace just a few random patches of grass, and only in swamps because of mcpatcher. But that's just one of an endless number of options it provides.
Texture artists are pretty much the only ones who will ever truly appreciate just how much this mod does. Texture pack users might give all the credit to the artists who made the pack using mcpatcher's features, but without mcpatcher, some of the most amazing packs out there would look horrible.
It may not do anything gameplay wise, but that doesn't mean it has no merit as a mod. It's pinned in the resource pack section because it deserves to be. Because without it, a lot of resource packs just won't live up to their potential. If a resource pack says it requires mcpatcher, you better be using mcpatcher.
But i seem to be doing a lot of rambling here, to answer your question in TL;DR fashion: Mcpatcher is pinned here because many resource packs require it to function properly.
I raise my glass to the best explaination of MCPatcher's significance in this community that I have seen these many moons. * Alvoria raises his glass of Zinfandel in 13thMurder's honor * Here Here!
matchBlocks yes, matchTiles no. I would strongly recommend getting out of the habit of relying on naming your files block###.properties though. There's no telling when Mojang will remove the last vestiges of numerical IDs.
Yeah I plan on shifting all of the ctm over to name based when I next push an update for my pack. I can't however seem to get ctm to work for modded blocks, which I recall reading you can do. So I am thinking that my file/folder structure for it isn't right,or I am not specifying the right patch in the .properties file. So could I get a sample of how to set it up for am do or if anyone has a pack with some ctm for mods in it could you point me to it?
to be honest.. anyone who uses this over Optifine is doing it wrong..
(and not using optifine at all is definitely silly.. the chunk loading is so much better)
Let's take a look at he pros and cons of using mcpatcher over optifine.
Pros:
More featuers, such as Better Glass and CIT.
Better mod support.
Cons:
No support for putting it in the mods folder. Could be if kahr implemented ITweaker.
Not to mention, not everyone wants to use Optifine. It has it's place to be sure, but there's no obligation for everyone to use Optifine UND ONLY OPTIFINE, people can use what they want. Maybe Optifine is unnecessary for one, or uncooperative for another, whatever their reasons are they're not "silly" or "doing it wrong" if they use MCPatcher instead. Regardless of what you might think, MCPatcher has its place and ain't going anywhere anytime soon, not with how important it is to many resource pack creators, and maybe even adventure map creators due to the Custom Item Textures feature allowing them to add unique-looking items for the purposes of their map.
I'd say another "Pro" is that not only is MCpatcher much, much faster at updating, it also sometimes has snapshot support. Optifine pretty much completely relies on MCP (Mod Coder Pack), and took an extremely long time to get to even 1.7.4. MCpatcher already has 1.7.5 support, Optifine doesn't.
I don't think Optifine is EVER updated to snapshots, either, waiting for stable releases, which means updating is going to take longer, because snapshots give content creators (like modders and resource pack makers) a head start on what changes are being made.
Rollback Post to RevisionRollBack
"I'm an outsider by choice, but not truly.
It’s the unpleasantness of the system that keeps me out.
I’d rather be in, in a good system. That’s where my discontent comes from:
being forced to choose to stay outside.
My advice: Just keep movin’ straight ahead.
Every now and then you find yourself in a different place."
-George Carlin
That's much easier said than done. For those who want the gory details, I'll just paste my reply to a PM asking about the same thing:
It's not the use of Javassist that worries me. It's the way MCPatcher does its own deobfuscation and reobfuscation. As I understand it, FML relies on fixed mappings, which means it has all the information it needs for each class as soon as the class loader calls for it. MCPatcher often won't know what to do with, say, abc.class until it sees cba.class, which may not even be loaded yet. It takes multiple passes over the entire jar file to fully resolve these cross-dependencies before patching can begin.
While this problem isn't unsolvable, it's a lot more complicated than I want to deal with. If you run into a situation where you can't resolve a particular class, say in a new snapshot, what do you do? Today I can just grey out that feature in MCPatcher's UI, but when you're in the middle of starting the game, an unceremonious crash is about your only option.
Of course you could sidestep the issue by using fixed mappings. That ties you to one specific version of Minecraft, though, and defeats much of the purpose of MCPatcher's system. You couldn't necessarily use MCP's either, since I often have to name things well before any MCP release. (I already have mappings for several new 1.8 classes for example).
Anyway, I wanted to show this:
It may not look like much, but it's taken me days to get CTM working on rotated logs and pillars again after the last snapshot. What's nice is that there's no more special-case code for these blocks anymore. The models have all the information I need to tell me when the "top" face is actually on the north, etc.
That's much easier said than done. For those who want the gory details, I'll just paste my reply to a PM asking about the same thing:
I wasn't really talking about mcpatcher itself using a version independent ITweaker. I meant that it could create a version dependent jar file that uses ITweaker and ASM transformers. It still takes some work, but it would be better than the other option
Hmm. I thought of an extension to ctm rules and a slightly more advanced random mobs. I dunno if there's already a rule for this, but for all that I've messed with MCPatcher, there doesn't seem to be. Anyways, here's an explanation for each.
Orientation Rule for CTM:
• Normal: Default when not included. Doesn't change any functionality of current CTM rules.
• Horizontal: Flips textures randomly in the horizontal direction.
• Vertical: Flips textures randomly in the vertical direction.
• Rotate: Rotates textures by 90 degrees randomly. Also can be paired with Horizontal or Vertical.
• Random: Flips and Rotates the texture randomly.
Advanced Random Mobs:
• Bodypart Specifications:
○ Allows you to create a folder for a mob containing textures for the bodyparts you'd like to switch out. Subfolders for each head, body, arms, and legs. If the feature is used, then the game looks for textures within these folders and applies them randomly to mobs. Only looks for the folders that exist.
▣Example 1: So, if you only want to change the shirt and pants of a zombie, giving 10 textures to each, you don't have to create 100 different textures specifically for each combination.
▣Example 2: If you want certain chunks of a skeleton to be missing, such as parts of it's skull or a missing rib here and there, you specify torso and head folders with the textures you wish to mix and match.
I can understand if and why the advanced Random Mobs stuff might be a bit much though. Just thought I'd share the thoughts, though. Keep up the great work, man.
Let's take a look at he pros and cons of using mcpatcher over optifine.
Pros:
More featuers, such as Better Glass and CIT.
Better mod support.
Cons:
No support for putting it in the mods folder.
No fps increase, which isn't required for me.
No ingame menu for changing mcpatcher settings.
Most of the cons are inconsequential.
1) Can Optifine change the texture of an item based simply on NBT data? Nope. ("Custom Item Texutres" feature) (Ex.: Naming an Emerald & calling it "Ruby" changes it into the Ruby texture, but if the Emerald isn't named, it stays the normal Emerald texture.)
2) Is Optifine working on the weekly snapshots? Nope. (MCPatcher might not work on ALL snapshots, but it does work on MOST of them. Optifine doesn't work on any snapshots.)
3) Does Optifine have a Texture Pack converter? Nope.
The only thing Optifine is good for is for reducing lag. MCPatcher isn't deisgned to do that, nor does MCPatcher decrease your fps.
Optifine sucks as being a Texture/Resource Pack tool.
to be honest.. anyone who uses this over Optifine is doing it wrong..
(and not using optifine at all is definitely silly.. the chunk loading is so much better)
No it's not. It's silly if you use Optifine over MCPatcher.(unless maybe you're going to play in normal vanilla Survival without a texture pack, then you MIGHT, but not really, have a point)
& who really cares about the chunk loading? My computer runs Minecraft just fine. I don't use Optifine, because the only thing Optifine is good at, is reducing lag, & I don't have any lag on my computer. If anything, Optifine decreases my fps.
If you look on the Optifine page, it says: Information for Texture Pack Authors (based on MCPatcher's description)
...read it again carefully. (BASED ON MCPATCHER'S DESCRIPTION)!
So yeah if anything, Optifine is copying Kahr's MCPatcher code. All the texture pack features that Optifine has, also goes into the \{Resource Pack's Name}\assets\minecraft\mcpatcher folder, just like for MCPatcher.
The only people who should use Optifine, are people who have really bad & ancient computers(which I don't have). If people can run Minecraft without Optifine & get 20-60 fps, should use MCPatcher or just plain Vanilla, but no Optifine. You don't really need any fps that are higher than 60.
Optifine sucks at their statement of:
"Doubling the FPS is common."
I, as a texture/resource pack artist, hate Optifine, because it lacks the same quality features as MCPatcher.(Optifine might have the same features, but it's not the same as MCPatcher, if not worse).
I, as a normal player, hate Optifine, because it sucks as increasing fps & reducing lag. (It decreases fps & creates lag).
This is already fixed in 4.3.2.
Reported earlier, renderPass 2 and 3 aren't currently working with Forge. Another instance where we both modify the exact same line of code and it requires some tricky merging on my part. Fixed for next release.
The problem with that is keeping so many large skybox textures in memory at once in order to smoothly transition between them.
Good catch, switching from a pack with redstone.png to one without doesn't clear out the old colors. That bug's probably been there since 1.5. Fixed.
Ah, I've tried several times and never been able to nail this bug down since the SSP/SMP merge. In singleplayer it's supposed to save the skin used to the NBT data when it saves the chunk. And it worked perfectly in 1.2 and still mostly works now. But not always as you've noted.
For multiplayer, it's more complicated, but as long as the chunk stays loaded on the server it should get the same skin each time until it is rebooted. That's the best that can be done without patching the server code.
I probably broke compatibility with 14w06b when I updated to 14w08a. The custom block model code changed so much between the two versions (and again in 14w10, which I'm currently dealing with) that it no longer recognizes one of the classes. I'll see if there's an easy fix, but no promises.
Not going to spend a lot of time on these. As of 14w10, glass pane rendering is completely out of my hands, so these issues are basically moot.
Good god, why not use method=fixed?
The default method if you don't specify is "ctm", which is why it expects 47 tiles.
This is working for me (4.3.2 + 14w08a & 1.7.5):
Interesting, but if I'm understanding this right, don't you still have to install Forge via MCPatcher and use that patched jar as input to your program for this to work? Otherwise none of Forge's base class changes will be in the library.
Is this what you're trying to do?
I think there is a bug here as that "connect=block" shouldn't be necessary. I'll look into it more.
matchBlocks yes, matchTiles no. I would strongly recommend getting out of the habit of relying on naming your files block###.properties though. There's no telling when Mojang will remove the last vestiges of numerical IDs.
Fixed.
Fixed.
More or less. By repeat horizontally i meant repeat ctm, but in a single block high multiple block wide horizontal pattern.
Also, just plain repeat ctm with "faces=top bottom" not relying on the output of another properties isn't working either.
All of my plank textures use all of these ctm methods together with no problem. I've never heard of "connect=block" before, but i'll give it a try and let you know what happens. Thanks
Edit: I just tried it. Unfortunately adding "connect=block" had no effect.
Oh, so they have to all be in the same folder and not in sub-folders of that folder?
Also check me out on:
WordPress, Etsy, and Spore.
Great man! Looking forward to downloading the next release. Thank you!
EzerArch.com | Armourer's Workshop Skins | MCHeli Content Pack Addons | Resource Packs | YouTube | G+ | Twitter
Now where do I find this fixed version?
I've got a 5 toned stone with multiple layers to give it a strata effect, it looks alright now and I could use biomes to variate the strata too. I was just wondering if the variable could be done? Maybe have a 'jitterweight' to make a weight based setup as to what 'room' is available?
I dunno, I'm just thinking aloud. I'm still happy with the product.
Notice that it's in the resource packs section, rather than in the mods section. Rather than effecting gameplay in any way, this mod is more of a graphical expansion. It's a framework for texture packs to be built upon, allowing texture artists to do some incredible things, far beyond the single texture per block that vanilla minecraft allows.
With mcpatcher, minecraft can look absolutely amazing. Texture artists can be much more creative. For example, have you ever seen swamp flies in minecraft? In my texture pack, you'll occasionally come across flies hovering around in circles in a swamp. It doesn't sound like much, but it does a lot to create an atmosphere. I was able to retexture a bit of grass into a fly, animate it, and make it replace just a few random patches of grass, and only in swamps because of mcpatcher. But that's just one of an endless number of options it provides.
Texture artists are pretty much the only ones who will ever truly appreciate just how much this mod does. Texture pack users might give all the credit to the artists who made the pack using mcpatcher's features, but without mcpatcher, some of the most amazing packs out there would look horrible.
It may not do anything gameplay wise, but that doesn't mean it has no merit as a mod. It's pinned in the resource pack section because it deserves to be. Because without it, a lot of resource packs just won't live up to their potential. If a resource pack says it requires mcpatcher, you better be using mcpatcher.
But i seem to be doing a lot of rambling here, to answer your question in TL;DR fashion: Mcpatcher is pinned here because many resource packs require it to function properly.
Well said!
Yeah I plan on shifting all of the ctm over to name based when I next push an update for my pack. I can't however seem to get ctm to work for modded blocks, which I recall reading you can do. So I am thinking that my file/folder structure for it isn't right,or I am not specifying the right patch in the .properties file. So could I get a sample of how to set it up for am do or if anyone has a pack with some ctm for mods in it could you point me to it?
Let's take a look at he pros and cons of using mcpatcher over optifine.
Pros:
Mods I work on and maintain:
TabbyChat | Mine Little Pony
My Blog
I'd say another "Pro" is that not only is MCpatcher much, much faster at updating, it also sometimes has snapshot support. Optifine pretty much completely relies on MCP (Mod Coder Pack), and took an extremely long time to get to even 1.7.4. MCpatcher already has 1.7.5 support, Optifine doesn't.
I don't think Optifine is EVER updated to snapshots, either, waiting for stable releases, which means updating is going to take longer, because snapshots give content creators (like modders and resource pack makers) a head start on what changes are being made.
"I'm an outsider by choice, but not truly.
It’s the unpleasantness of the system that keeps me out.
I’d rather be in, in a good system. That’s where my discontent comes from:
being forced to choose to stay outside.
My advice: Just keep movin’ straight ahead.
Every now and then you find yourself in a different place."
-George Carlin
That's much easier said than done. For those who want the gory details, I'll just paste my reply to a PM asking about the same thing:
Anyway, I wanted to show this:
I wasn't really talking about mcpatcher itself using a version independent ITweaker. I meant that it could create a version dependent jar file that uses ITweaker and ASM transformers. It still takes some work, but it would be better than the other option
Mods I work on and maintain:
TabbyChat | Mine Little Pony
My Blog
Orientation Rule for CTM:
Advanced Random Mobs:
I can understand if and why the advanced Random Mobs stuff might be a bit much though. Just thought I'd share the thoughts, though. Keep up the great work, man.
Putting the CENDENT back in transcendent!
1) Can Optifine change the texture of an item based simply on NBT data? Nope. ("Custom Item Texutres" feature) (Ex.: Naming an Emerald & calling it "Ruby" changes it into the Ruby texture, but if the Emerald isn't named, it stays the normal Emerald texture.)
2) Is Optifine working on the weekly snapshots? Nope. (MCPatcher might not work on ALL snapshots, but it does work on MOST of them. Optifine doesn't work on any snapshots.)
3) Does Optifine have a Texture Pack converter? Nope.
The only thing Optifine is good for is for reducing lag. MCPatcher isn't deisgned to do that, nor does MCPatcher decrease your fps.
Optifine sucks as being a Texture/Resource Pack tool.
No it's not. It's silly if you use Optifine over MCPatcher.(unless maybe you're going to play in normal vanilla Survival without a texture pack, then you MIGHT, but not really, have a point)
& who really cares about the chunk loading? My computer runs Minecraft just fine. I don't use Optifine, because the only thing Optifine is good at, is reducing lag, & I don't have any lag on my computer. If anything, Optifine decreases my fps.
If you look on the Optifine page, it says:
Information for Texture Pack Authors (based on MCPatcher's description)
...read it again carefully. (BASED ON MCPATCHER'S DESCRIPTION)!
So yeah if anything, Optifine is copying Kahr's MCPatcher code. All the texture pack features that Optifine has, also goes into the \{Resource Pack's Name}\assets\minecraft\mcpatcher folder, just like for MCPatcher.
The only people who should use Optifine, are people who have really bad & ancient computers(which I don't have). If people can run Minecraft without Optifine & get 20-60 fps, should use MCPatcher or just plain Vanilla, but no Optifine. You don't really need any fps that are higher than 60.
Optifine sucks at their statement of:
"Doubling the FPS is common."
I, as a texture/resource pack artist, hate Optifine, because it lacks the same quality features as MCPatcher.(Optifine might have the same features, but it's not the same as MCPatcher, if not worse).
I, as a normal player, hate Optifine, because it sucks as increasing fps & reducing lag. (It decreases fps & creates lag).
What other mods do the same things as MCPatcher does & are better than it?