So how do I go about getting CTM with the default texpack? Right now I simply patch Connected Textures and Better Glass with MCPatcher and fire up Minecraft, but I don't see any difference in glass panes or glass blocks (which is the main reason why I use CTM).
What am I doing wrong? Do I actually need to use a specific "default CTM" resource pack?
--Tuan
You can get the default CTM files for the default textures from Optifine's .jar. Download it, and extract the folder containing them.
Is there any way to alter the color of the text that is hardcoded on to the UI elements? I've been pulling my hair out all evening trying to figure it out.
Well, the vanilla way allows this through editing the language files in the gui.container section. You simply need to prefix it with the symbol § and a number (0-9) or letter (a-f, k-o, or r) to change the way that particular text looks in-game. You can see what the formatting codes do here. Also, you'll need to save the language file as ANSI format to use the § symbol in the language pack... If you're unsure of how to do that, see the bottom of the linked page for an alternative. Just tinker with it (with a back-up, of course).
I'm unsure of if MCPatcher has something that also does this, but it probably does.
Rollback Post to RevisionRollBack
I used to maintain the Minecraft Forums Mod List. However, life has stepped in the way of that. Perhaps later...
I found out something about trying "connect=material" with glass and stained glass, It will register with other glass type stuff like the glowstone, it will register with the white glass (meta 0 I believe) but it will not register with other colors. Don't know if they are not set up as 'glass' or if the material property is not working with all metadata values.
In general, connectedness requires that the two blocks have the same metadata value. I'm considering removing this restriction for connect=material but am unsure if there would be any negative side effects (like block A connecting to block B, but not vice versa).
In 1.7.2/13w47 the flowing/still water and rain splashes are significantly more blue than they should be (but not completely blue as if it was using default CC). Dripping water is fine. Removing the water.png file fixes the coloration but makes dripping water gray.
Turns out the particle.color property wasn't being used at all since the new colormap system. I've fixed that problem and a few others, so water particles should be colored more consistently now.
Also, Kahr, have you tried anything with the new CC applying to CTM? As I said before, render pass 3 does not work right with 1 layer (it shows regular textures under it), but with 2 layers CC does not recolor the second layer. So to work, it would either need for a "replace" style blending mode, or for CC to recolor all CTM layers on given block.
Does blend.3=replace work now? Any of the Better Skies blending methods should be recognized.
I'll look into making colormaps more render pass-aware, which should address the second problem.
Can someone help me out here? I am trying to control biome shading with the new grid format, but am having no luck getting it working. I think i'm just not understanding the proper file structure. Is there a template anywhere that shows exactly where the files go and what should be in the properties file?
You're probably not doing anything wrong. There's currently a bug applying the grid format to grass and foliage. You can work around it by setting grid format globally (palette.format=grid in color.properties) or by naming the files something other than "grass" or "foliage".
Is it possible to make randomized double tall plants cooperate?
I've changed random CTM so that the top and bottom halves of double plants use the same seed value. If you have the same number of tiles and weights, it should behave consistently.
Alvoria is on the right track. Minecraft simply joins all the texture/resource packs that are enabled, so if a file exists in, say, the 2nd choice, but not the 1st one, it will still be included in Minecraft's "internal resource pack".
This is exactly right. When the game requests a texture it has no way of knowing which pack it came from. All of that information is abstracted away.
I'm not sure what the correct behavior should be either. The current behavior works for a base pack + addon packs that are designed to go together. Like a base pack with just vanilla textures, another pack for mods, an MCPatcher addon pack with CTM, Random Mobs, etc., and possibly even additional packs with more CTM variants. But merging two base packs from two different authors is problematic no matter how you do it.
This is exactly right. When the game requests a texture it has no way of knowing which pack it came from. All of that information is abstracted away.
I'm not sure what the correct behavior should be either. The current behavior works for a base pack + addon packs that are designed to go together. Like a base pack with just vanilla textures, another pack for mods, an MCPatcher addon pack with CTM, Random Mobs, etc., and possibly even additional packs with more CTM variants. But merging two base packs from two different authors is problematic no matter how you do it.
In my tests with the new system, the addon pack will replace any file in the base pack no matter what the file is (even MCPatcher files, or files that shouldn't even BE in a resource pack normally), and CTM overrides all.
For example:
- If your base pack has a CTM .properties file of any kind, it will use the textures that CTM properties file is pointing to in that folder. Regardless if an addon pack overrides a texture in /blocks/. So, if your addon pack only replaces the texture in /blocks/, the CTM .properties file still wins out, and will still replace that texture with whatever CTM it's pointing to. Since CTM always wins, it doesn't matter if the addon pack replaced the texture in /blocks/
- BUT: If there is a .properties file inside the addon pack in the exact same spot with the exact same name it will override the base pack's CTM file with the new config. If you wanted to disable CTM this way, you can simply just throw a blank file in the addon pack. (This is assuming you are the owner of both packs and have a logical reason to do this)
- You can change the CTM's images in the addon in it's CTM folder without changing the properties file, MC will simply load up the base packs CTM then when it loads up the addon packs new textures, it will replace all the old CTM textures with the new ones, assuming they are in the same folder, and have the same name.
- I have not tested it, but I believe if the addon pack has a different properties file in a different folder that effects the same blocks, the "winner" .properties file will be whatever loads last, so presumably, the one in the addon pack.
So, having said all that, basically those of us using CTM will totally override any add on packs that are loaded on top of our packs unless those addon packs also have a CTM .properties file, with the same name, in the same location. Else it will replace the texture in /blocks/, you just won't see it since your base pack's CTM overrides /blocks/ anyway.
I hope I didn't make that *too* confusing. But actually the system is working exactly as it should be, I think. It's just that when MC replaces a base texture in /blocks/, it's doing it's job. CTM overrides it anyway, regardless if it's in the base pack or the addon pack, so you have to override CTM as well.
This could be confusing for non-resource pack artists who don't understand the details, but unless MCPatcher totally dumps all .properties files from the base pack to load an addon pack (oh god PLEASE no!) I think this is just how it'll have to be.
The only fix I can think of is if MCPatcher detects when a texture is replaced in /blocks/, then disables any .properties file attached to that texture in the base pack's /mcpatcher/ctm.. but I imagine that would be massively and needlessly confusing/complicated to code. I wouldn't expect Kahr to have to waste his time doing such a thing.
(EDIT: I assume everything I said also applies to CIT, BetterSkies, RandomMobs and all the other mods too)
I've changed random CTM so that the top and bottom halves of double plants use the same seed value. If you have the same number of tiles and weights, it should behave consistently.
Someone help please, I'm trying to patch Minecraft 1.7.2 with MCpatcher. I want Randomobs and Zoom mod which I added myself.
When I patch, the textures work fine, but mods aren't being installed. No randomobs, zoom, connected textures etc.
What's wrong?
First, are you sure you've selected the proper Minecraft version in your profile? It should be something like "1.7.2-mcpatcher" in the menu.
Second, are you certain you're using a Resource Pack that supports those features? They don't just appear in vanilla because you installed the mod.
Zoom has, to the best of my knowledge, never been an MCPatcher feature so that one is bound to fail.
I've changed random CTM so that the top and bottom halves of double plants use the same seed value. If you have the same number of tiles and weights, it should behave consistently.
I don't quite understand what you've done there with the matchblocks... though i am using matchTiles in mine which is most likely the issue. Although, i am using biome specific textures for this as well, so the properties file is not named after the block, could that be part of the problem?
Because of the number of changes in this release with the potential to break something, I'm going to release a beta first. Download MCPatcher 4.3.1-beta1 exejar.
Changes:
Force consistent coloring and random CTM between top and bottom half of double_plant blocks.
Fixed CTM problems with metadata 15.
Fixed custom grass, foliage.png always using the vanilla format.
Fixed beacon particle effects transparency.
Support texture.* syntax in CIT type=enchantment.
Added yOffset property to grid format colormap.
Fixed Test Minecraft button with 13w47e.
Fixed crash with zan's minimap.
Fixed transparency issues with 13w47e.
Fixed CIT ignoring weight property in some cases.
Allow CIT matching of damage as a % of max in addition to an absolute value.
Preserve Mojang's hard-coded biome colors for packs with no grass, foliage.png.
Fix inconsistent water particle colors.
Ignore neighbor's metadata when checking connect=material.
New property enableColormap.3 to enable custom colormaps during render pass 3.
I've changed random CTM so that the top and bottom halves of double plants use the same seed value. If you have the same number of tiles and weights, it should behave consistently.
Odd request, but could you add a flag that disables this feature? I know it sounds strange, but all of my double tall plants are actually designed to be totally random tops/bottoms (I made sure their middle points all line up). So the new change actually decreases the amount of random variations I have. Now there's only 9 total variations of my double plants (9 tops and 9 bottoms) where as without this new feature I have 81 variations because the 9 tops and 9 bottoms are all interchangeable.
Odd request, but could you add a flag that disables this feature? I know it sounds strange, but all of my double tall plants are actually designed to be totally random tops/bottoms (I made sure their middle points all line up). So the new change actually decreases the amount of random variations I have. Now there's only 9 total variations of my double plants (9 tops and 9 bottoms) where as without this new feature I have 81 variations because the 9 tops and 9 bottoms are all interchangeable.
EDIT: Doh! Ninja'ed by the update post!
Oh! Good point...I didn't realize the significance of that particular feature! I do it the same way as you, so yes I would be keen to be able to disable this....at least for the foreseeable future.
by "Doh! Ninja'ed by the update post!" Do you mean that what you and I want is or isn't possible with kahr's latest update? I ask this, because I'm remote from my usual MC PC and can't check for a while. It'd be a pain if I have to change stuff to get back some randomness lost.
by "Doh! Ninja'ed by the update post!" Do you mean that what you and I want is or isn't possible with kahr's latest update? I ask this, because I'm remote from my usual MC PC and can't check for a while. It'd be a pain if I have to change stuff to get back some randomness lost.
I just meant that I was hoping to get my message out before he released the update with the change in it.
I just meant that I was hoping to get my message out before he released the update with the change in it.
If you make one extra variation for either the top or bottom, or delete an existing one, that should effectively throw off the matching thing and make it random again.
If you make one extra variation for either the top or bottom, or delete an existing one, that should effectively throw off the matching thing and make it random again.
At least, that's my understanding of Kahr's post.
Oh! Flip! That means I've got to understand another bit of ctm to get the double plant randomness back in.
Actually, how possible would it be to have both the original randomness and the matching ctm type at the same time? Meaning with some unique double plants you might want the top and bottom to match up, whereas with some similar types of double plants you might desire the extra, but limited randomness that we got from pre- 4.3.1-beta1 update.
[edit] Actually, from what you say, and to answer my own question, wouldn't that already be possible? My brain not working...nothing new there then! I see you'd already answered that in your post!
If you make one extra variation for either the top or bottom, or delete an existing one, that should effectively throw off the matching thing and make it random again.
At least, that's my understanding of Kahr's post.
I was thinking that too, it should effectively scramble the pattern. Honestly you wouldn't even have to draw any more variations, just duplicate one.
Or, if you wanted to keep all the randomness totally equal, duplicate all of them so there's still the same chance of any 1 of them popping up, since there's twice as many but 2 of each.
I was thinking that too, it should effectively scramble the pattern. Honestly you wouldn't even have to draw any more variations, just duplicate one.
Or, if you wanted to keep all the randomness totally equal, duplicate all of them so there's still the same chance of any 1 of them popping up, since there's twice as many but 2 of each.
Ray, could I ask you or Alvoria to give me an example .properties file for this new double plant ctm, for both matching and variation type. At the moment I can't get my head around kahr's example. Much thanks in advance.
Ray, could I ask you or Alvoria to give me an example .properties file for this new double plant ctm, for both matching and variation type. At the moment I can't get my head around kahr's example. Much thanks in advance.
I don't have one yet, I'm still using the non-beta version. :/
my configs for top/bottom on all my doubleplants just look like this at the moment:
tiles=0-8
weights=1 1 1 1 1 1 1 1 1
method=random
The weight= part isn't needed either, it's redundant since I haven't changed the weight on anything anyway.
I have a question, is it possible to have multiple variations of arrows (not the item) with any of the features in mcpatcher? I ask because my custom pack has multiple kinds of bows ranging from staves, tomes, bows and a few guns and I wanted them to have their own kinds of arrows to make the most sense. (Crossbow - Bolt, Stave - Mana Charge and etc)
Rollback Post to RevisionRollBack
Jingle bells, decay and fails
The adventurers all died of fright.
Dungeons night, was never right
When the lich came in a sleigh.
I don't have one yet, I'm still using the non-beta version. :/
my configs for top/bottom on all my doubleplants just look like this at the moment:
tiles=0-8
weights=1 1 1 1 1 1 1 1 1
method=random
The weight= part isn't needed either, it's redundant since I haven't changed the weight on anything anyway.
That's what I've already got for mine too. I don't use weight to control things either...the random part worked fine for mixing the top/bottom variations I have.
Oh well. I'd appreciate an example sometime from yourself or anyone who has it figured. I haven't fired up the new update yet either, I'll just motor on with more variations for now and hope someone posts something. Thanks anyway.
Turns out the particle.color property wasn't being used at all since the new colormap system. I've fixed that problem and a few others, so water particles should be colored more consistently now.
Does blend.3=replace work now? Any of the Better Skies blending methods should be recognized.
I'll look into making colormaps more render pass-aware, which should address the second problem.
OK, that fixed my issue. I think it was like that for a while, because it wasn't changing my particles a long time ago, and that's why I needed to use the water colormap.
Yes, I just tried blend.3=replace (thought I tried it before, but guess not), but that doesn't allow for the partial transparency to display properly (it turns opaque). Even in the beta version. Also, the top acts like it isn't on renderPass 3, the top can be recolored (without the flag you added) and no partial transparency shows.
Maybe this is BetterSkies specific blending? I'd get why you wouldn't want the sky keeping transparency, but for CTM it's inside the world, so worthy to have.
"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 what I've already got for mine too. I don't use weight to control things either...the random part worked fine for mixing the top/bottom variations I have.
Oh well. I'd appreciate an example sometime from yourself or anyone who has it figured. I haven't fired up the new update yet either, I'll just motor on with more variations for now and hope someone posts something. Thanks anyway.
I've used weight in a few places, but seldom do I need it. I made some "rare" textures mostly for fun, they have lower weight ratings than the other random textures so they don't pop up very often. My pumpkins for example, I have a creeper-face pumpkin that hardly ever shows up.
I also hid a creeper face in my web CTM with the same method hehe.
-
View User Profile
-
View Posts
-
Send Message
Retired StaffWell, the vanilla way allows this through editing the language files in the gui.container section. You simply need to prefix it with the symbol § and a number (0-9) or letter (a-f, k-o, or r) to change the way that particular text looks in-game. You can see what the formatting codes do here. Also, you'll need to save the language file as ANSI format to use the § symbol in the language pack... If you're unsure of how to do that, see the bottom of the linked page for an alternative. Just tinker with it (with a back-up, of course).
I'm unsure of if MCPatcher has something that also does this, but it probably does.
In general, connectedness requires that the two blocks have the same metadata value. I'm considering removing this restriction for connect=material but am unsure if there would be any negative side effects (like block A connecting to block B, but not vice versa).
Turns out the particle.color property wasn't being used at all since the new colormap system. I've fixed that problem and a few others, so water particles should be colored more consistently now.
Does blend.3=replace work now? Any of the Better Skies blending methods should be recognized.
I'll look into making colormaps more render pass-aware, which should address the second problem.
You're probably not doing anything wrong. There's currently a bug applying the grid format to grass and foliage. You can work around it by setting grid format globally (palette.format=grid in color.properties) or by naming the files something other than "grass" or "foliage".
I've changed random CTM so that the top and bottom halves of double plants use the same seed value. If you have the same number of tiles and weights, it should behave consistently.
double_plant_bottom.properties:
method=random
matchBlocks=double_plant:0-7
tiles=red_bottom green_bottom blue_bottom
double_plant_top.properties:
method=random
matchBlocks=double_plant:8-15
tiles=red_top green_top blue_top
This is exactly right. When the game requests a texture it has no way of knowing which pack it came from. All of that information is abstracted away.
I'm not sure what the correct behavior should be either. The current behavior works for a base pack + addon packs that are designed to go together. Like a base pack with just vanilla textures, another pack for mods, an MCPatcher addon pack with CTM, Random Mobs, etc., and possibly even additional packs with more CTM variants. But merging two base packs from two different authors is problematic no matter how you do it.
In my tests with the new system, the addon pack will replace any file in the base pack no matter what the file is (even MCPatcher files, or files that shouldn't even BE in a resource pack normally), and CTM overrides all.
For example:
- If your base pack has a CTM .properties file of any kind, it will use the textures that CTM properties file is pointing to in that folder. Regardless if an addon pack overrides a texture in /blocks/. So, if your addon pack only replaces the texture in /blocks/, the CTM .properties file still wins out, and will still replace that texture with whatever CTM it's pointing to. Since CTM always wins, it doesn't matter if the addon pack replaced the texture in /blocks/
- BUT: If there is a .properties file inside the addon pack in the exact same spot with the exact same name it will override the base pack's CTM file with the new config. If you wanted to disable CTM this way, you can simply just throw a blank file in the addon pack. (This is assuming you are the owner of both packs and have a logical reason to do this)
- You can change the CTM's images in the addon in it's CTM folder without changing the properties file, MC will simply load up the base packs CTM then when it loads up the addon packs new textures, it will replace all the old CTM textures with the new ones, assuming they are in the same folder, and have the same name.
- I have not tested it, but I believe if the addon pack has a different properties file in a different folder that effects the same blocks, the "winner" .properties file will be whatever loads last, so presumably, the one in the addon pack.
So, having said all that, basically those of us using CTM will totally override any add on packs that are loaded on top of our packs unless those addon packs also have a CTM .properties file, with the same name, in the same location. Else it will replace the texture in /blocks/, you just won't see it since your base pack's CTM overrides /blocks/ anyway.
I hope I didn't make that *too* confusing. But actually the system is working exactly as it should be, I think. It's just that when MC replaces a base texture in /blocks/, it's doing it's job. CTM overrides it anyway, regardless if it's in the base pack or the addon pack, so you have to override CTM as well.
This could be confusing for non-resource pack artists who don't understand the details, but unless MCPatcher totally dumps all .properties files from the base pack to load an addon pack (oh god PLEASE no!) I think this is just how it'll have to be.
The only fix I can think of is if MCPatcher detects when a texture is replaced in /blocks/, then disables any .properties file attached to that texture in the base pack's /mcpatcher/ctm.. but I imagine that would be massively and needlessly confusing/complicated to code. I wouldn't expect Kahr to have to waste his time doing such a thing.
(EDIT: I assume everything I said also applies to CIT, BetterSkies, RandomMobs and all the other mods too)
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThanks, kahr!
-
View User Profile
-
View Posts
-
Send Message
Retired StaffSecond, are you certain you're using a Resource Pack that supports those features? They don't just appear in vanilla because you installed the mod.
Zoom has, to the best of my knowledge, never been an MCPatcher feature so that one is bound to fail.
-
View User Profile
-
View Posts
-
Send Message
Retired StaffI don't quite understand what you've done there with the matchblocks... though i am using matchTiles in mine which is most likely the issue. Although, i am using biome specific textures for this as well, so the properties file is not named after the block, could that be part of the problem?
I may just be very dense today.
Changes:
- Force consistent coloring and random CTM between top and bottom half of double_plant blocks.
- Fixed CTM problems with metadata 15.
- Fixed custom grass, foliage.png always using the vanilla format.
- Fixed beacon particle effects transparency.
- Support texture.* syntax in CIT type=enchantment.
- Added yOffset property to grid format colormap.
- Fixed Test Minecraft button with 13w47e.
- Fixed crash with zan's minimap.
- Fixed transparency issues with 13w47e.
- Fixed CIT ignoring weight property in some cases.
- Allow CIT matching of damage as a % of max in addition to an absolute value.
- Preserve Mojang's hard-coded biome colors for packs with no grass, foliage.png.
- Fix inconsistent water particle colors.
- Ignore neighbor's metadata when checking connect=material.
- New property enableColormap.3 to enable custom colormaps during render pass 3.
Enjoy!Odd request, but could you add a flag that disables this feature? I know it sounds strange, but all of my double tall plants are actually designed to be totally random tops/bottoms (I made sure their middle points all line up). So the new change actually decreases the amount of random variations I have. Now there's only 9 total variations of my double plants (9 tops and 9 bottoms) where as without this new feature I have 81 variations because the 9 tops and 9 bottoms are all interchangeable.
EDIT: Doh! Ninja'ed by the update post!
Example: My rose bushes with random tops/bottoms:
In game:
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumOh! Good point...I didn't realize the significance of that particular feature! I do it the same way as you, so yes I would be keen to be able to disable this....at least for the foreseeable future.
by "Doh! Ninja'ed by the update post!" Do you mean that what you and I want is or isn't possible with kahr's latest update? I ask this, because I'm remote from my usual MC PC and can't check for a while. It'd be a pain if I have to change stuff to get back some randomness lost.
I just meant that I was hoping to get my message out before he released the update with the change in it.
-
View User Profile
-
View Posts
-
Send Message
Retired StaffAt least, that's my understanding of Kahr's post.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumOh! Flip! That means I've got to understand another bit of ctm to get the double plant randomness back in.
Actually, how possible would it be to have both the original randomness and the matching ctm type at the same time? Meaning with some unique double plants you might want the top and bottom to match up, whereas with some similar types of double plants you might desire the extra, but limited randomness that we got from pre- 4.3.1-beta1 update.
[edit] Actually, from what you say, and to answer my own question, wouldn't that already be possible? My brain not working...nothing new there then! I see you'd already answered that in your post!
I was thinking that too, it should effectively scramble the pattern. Honestly you wouldn't even have to draw any more variations, just duplicate one.
Or, if you wanted to keep all the randomness totally equal, duplicate all of them so there's still the same chance of any 1 of them popping up, since there's twice as many but 2 of each.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumRay, could I ask you or Alvoria to give me an example .properties file for this new double plant ctm, for both matching and variation type. At the moment I can't get my head around kahr's example. Much thanks in advance.
I don't have one yet, I'm still using the non-beta version. :/
my configs for top/bottom on all my doubleplants just look like this at the moment:
The weight= part isn't needed either, it's redundant since I haven't changed the weight on anything anyway.
Jingle bells, decay and fails
The adventurers all died of fright.
Dungeons night, was never right
When the lich came in a sleigh.
By Sileo_Vulpes
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThat's what I've already got for mine too. I don't use weight to control things either...the random part worked fine for mixing the top/bottom variations I have.
Oh well. I'd appreciate an example sometime from yourself or anyone who has it figured. I haven't fired up the new update yet either, I'll just motor on with more variations for now and hope someone posts something. Thanks anyway.
-
View User Profile
-
View Posts
-
Send Message
Retired StaffOK, that fixed my issue. I think it was like that for a while, because it wasn't changing my particles a long time ago, and that's why I needed to use the water colormap.
Yes, I just tried blend.3=replace (thought I tried it before, but guess not), but that doesn't allow for the partial transparency to display properly (it turns opaque). Even in the beta version. Also, the top acts like it isn't on renderPass 3, the top can be recolored (without the flag you added) and no partial transparency shows.
Maybe this is BetterSkies specific blending? I'd get why you wouldn't want the sky keeping transparency, but for CTM it's inside the world, so worthy to have.
"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
I've used weight in a few places, but seldom do I need it. I made some "rare" textures mostly for fun, they have lower weight ratings than the other random textures so they don't pop up very often. My pumpkins for example, I have a creeper-face pumpkin that hardly ever shows up.
I also hid a creeper face in my web CTM with the same method hehe.