I've noticed the following glitches since updating my MCPatcher version. A quick search didn't turn up any discussion of them, so I juste wanted to make sure they're known:
•Black wool and black carpet CTM isn't working properly — it appears to be using the image files for white wool and carpet, instead (see image below)
•Enchanted items' glint is not showing up at all — they look the same as unenchanted items
This was happening for the black stained glass for me. I'm going to remake it with better textures and give it another shot. I'll post results with more details as to what I've tried, should it not work. And if I do get it to work, I'll still let you know.
Rollback Post to RevisionRollBack
I used to maintain the Minecraft Forums Mod List. However, life has stepped in the way of that. Perhaps later...
Does blend.3=replace work now? Any of the Better Skies blending methods should be recognized.
Ok, so I did a bit more after my reply from before, and got it all set-up and it should work. But, as said before, partial transparency does not work, and rendering order is all screwed up, seemingly even on single blocks (some sides render right, some don't).
Additionally, I decided to use 1 .property file for all of the CTM. I didn't see the point in making the exact same thing with a different metadata value 15 times over (even though I did to get the colors on there, ugh), because I want them to connect together (if I wanted them to be individual, I could add connect=tile it seems). The reason I'm mentioning it, is because there is no inter-block culling (not rendering inner faces between blocks) between the different types of glass, heck, inner faces are showing even in ONE type of glass!
Plus, the depth-rendering is pretty bad (yeah, I know, Mojang.....). This image pretty much sums it all up:
This was happening for the black stained glass for me. I'm going to remake it with better textures and give it another shot. I'll post results with more details as to what I've tried, should it not work. And if I do get it to work, I'll still let you know.
This issue should be fixed in the beta patcher on the previous page.
"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.
It was just the double plants I so no sense in applying weight to, but that was before they got matched up with ctm.
I've just done a mass of random flora for my next update (mostly for desert, fern and grass plants), but I've tended to weight things by just having less of the slightly rarer ones and more variations of the common. I'll chuck in a few very rare things later, when there's more time. Hah! that's a laugh...when do we ever get that!
Random ctm is the thing I have the most fun with though (especially as it's possible to hide little surprises in there that even delight the creator by some of the unusual places they pop up)...the rest of ctm is hard work for a dunderhead like me!
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.
Enjoy!
Thanks! Too bad it didn't fix the glass pane issue
Also I noticed that the glass block you hold in your hand, or in your inventory, is the texture of
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).
Fair point, and that's one of the reasons I wanted to do a beta before making it official. The old behavior (independent tops and bottoms) should probably be the default with an option to turn on the new behavior, just so no one is caught by surprise. I'm just not sure what to call it. useSameSeedForMultiblockObjects=true doesn't exactly roll off the tongue, does 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. At least, that's my understanding of Kahr's post.
More precisely, (ignoring the weights property for the moment)
T = number of top textures
B = number of bottom textures
If T and B are relatively prime: Tops and bottoms are completely scrambled.
If gcd(T,B) > 1: Somewhat scrambled, but certain pairings will never occur.
If T is an exact multiple of B or vice versa: Each bottom has its own separate set of potential tops (or vice versa).
If T = B: Tops and bottoms are always in sync.
For weighted lists, just pretend that they're unweighted lists with the textures repeated: tiles=a b c weights=1 2 3 is equivalent to tiles=a b b c c c.
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.
You could possibly do it with the divisor trickery above. Or, assuming I make the new behavior optional, by chaining two random CTMs together:
Ok, so I did a bit more after my reply from before, and got it all set-up and it should work. But, as said before, partial transparency does not work, and rendering order is all screwed up, seemingly even on single blocks (some sides render right, some don't). Here's a link for you to test with: http://www.mediafire...ained_glass.zip
I think this problem will have to wait until mcp is updated. There's more to Mojang's new transparency handling than I originally thought, but it's too complicated to figure out in obfuscated code.
i am having issues with mcpatcher 4.3 in Minecraft 1.7.2 but by the looks of it so is everyone else. One of the most annoying issues is somtimes two songs will play at the same time. I am not sure if this is an mcpatcher issue. The text on the loading screen looks terrible as well.
i am having issues with mcpatcher 4.3 in Minecraft 1.7.2 but by the looks of it so is everyone else. One of the most annoying issues is somtimes two songs will play at the same time. I am not sure if this is an mcpatcher issue.
No, that's a Minecraft sound engine issue. MCPatcher doesn't presently do anything with audio.
The text on the loading screen looks terrible as well.
That's an issue with your pack's custom font not being properly set up. You can delete the font folders (one under \textures\ and possibly another under \mcpatcher\) as a quick fix. Better to let your pack's artist know you're having this issue, though, so he or she can correct it. I'm reasonably sure that the issues with custom font have been fixed in MCPatcher, so now it's really up to the artist to utilized the fixed system.
As someone who's hung out with math majors... I didn't. It was obvious.
Thanks for fixing so many problems Kahr. My pack looks amazing and bug-free again! Also, super-special thanks for adding the texture.* syntax to CIT type=enchantment. I can FINALLY finish making my armor look amazing now!
I'll have to wait and see how someone else applies this. In the meantime I'll be more than happy with the original random method of joining the top and bottom textures, by having the middle strip the same.
Fair point, and that's one of the reasons I wanted to do a beta before making it official. The old behavior (independent tops and bottoms) should probably be the default with an option to turn on the new behavior, just so no one is caught by surprise. I'm just not sure what to call it. useSameSeedForMultiblockObjects=true doesn't exactly roll off the tongue, does it?
useSameSeedAsBottomsHaveForTopsSoTheyMatchAndYouCanDrawEachDoublePlantAsOneWithOutTilingIssues=true
(don't forget to put a typo in there too so you can throw them off!)
But seriously, maybe:
textureLinking=true
textureMatching=true
textureSync=true
doubletall<Linking/Matching/Sync>=true
multiblock<Linking/Matching/Sync>=true
I can see your point, there's really not any good descriptive names for the flag. My vote would be doubletallMatching= or doubletallSync=, Its not exactly accurate, but it's pretty easy to understand what it *might* do according to just reading the flag. The only problem you run into is if Mojang uses this same method to add "Tripletall" textures, and in that case multiblock may be a better option to cover your bases.
That's an issue with your pack's custom font not being properly set up. You can delete the font folders (one under \textures\ and possibly another under \mcpatcher\) as a quick fix. Better to let your pack's artist know you're having this issue, though, so he or she can correct it. I'm reasonably sure that the issues with custom font have been fixed in MCPatcher, so now it's really up to the artist to utilized the fixed system.
Actually, I get that too, if I'm understanding sin-twin correctly, but only on the briefly visible loading map screen. Every other screen, whether it be options menus, or in-game gui has the font perfectly displayed. It only ever happens for me on that one loading screen just before a world loads up and the text seems to be a garbled vanilla font. Strange, but I couldn't take a screenshot just now to show an example. Have I missed something about fonts between 1.5, 1.6 and 1.7? Highly likely I have, knowing my attention to detail!
Actually, I get that too, if I'm understanding sin-twin correctly, but only on the briefly visible loading map screen. Every other screen, whether it be options menus, or in-game gui has the font perfectly displayed. It only ever happens for me on that one loading screen just before a world loads up and the text seems to be a garbled vanilla font. Strange, but I couldn't take a screenshot just now to show an example. Have I missed something about fonts between 1.5, 1.6 and 1.7? Highly likely I have, knowing my attention to detail!
Oh really? I've never noticed it in any of the packs I've used so I assumed this was the old problem that got fixed. Thanks for pointing that out to me Glimmar.
Actually, I get that too, if I'm understanding sin-twin correctly, but only on the briefly visible loading map screen. Every other screen, whether it be options menus, or in-game gui has the font perfectly displayed. It only ever happens for me on that one loading screen just before a world loads up and the text seems to be a garbled vanilla font. Strange, but I couldn't take a screenshot just now to show an example. Have I missed something about fonts between 1.5, 1.6 and 1.7? Highly likely I have, knowing my attention to detail!
From what I know it seems to do that to any pack with a background that isn't 16x and any font size (I had this happen to me in my custom packs). But I would ignore it, because it doesn't really effect anything but at that moment.
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.
Here's a visual bug. Looks like MCPatcher hasn't adjusted for the change in how Minecraft renders transparencies. I can't remember which way it went, but the order in which blocks were rendered was flipped (front to back and vice versa).
It looks like this got missed, so I guess I have to re-post it.
Does anyone have a working properties file that defines several sets of faces for a block, and chooses randomly between those sets? Is this even possible?
Does anyone have a working properties file that defines several sets of faces for a block, and chooses randomly between those sets? Is this even possible?
I have hybrid vertical/random CTM, if thats what you mean. My ladders, reeds, vines all have a set of random "tops", "bottoms" and "centers". Same with Bookshelves, just horizontal instead of vertical. Is this what you mean?
You could also theoretically have a random CTM that calls upon other sets of random CTM; but I'm unsure what purpose that would serve when you could simply call those files directly in one large random CTM .properties.
Example of my reeds, note they have tops, bottoms and center pieces, all random within themselves as well.
dummy_top and dummy_bottom aren't real textures. Their only purpose is to get matched by the next set of rules:
I think this problem will have to wait until mcp is updated. There's more to Mojang's new transparency handling than I originally thought, but it's too complicated to figure out in obfuscated code.
How about you don't base it on weights or an option, but the same tile name with something like top and bottom or a and b, 1 and 2, etc.
option: useTileSets If true, look at the name. If the name is preceded or appended with certain phrases, look for a match.
The benefit of this is that random weighted pairs don't need to match at all, and the other section can use different random CTM tiles, or not use random CTM at all!
Sets override non-sets. In the event of a pair between 2 different sets, the CTM weight
Does anyone have a working properties file that defines several sets of faces for a block, and chooses randomly between those sets? Is this even possible?
If I'm understanding you right: try defining this:
Quote from ctm.properties sample file »
# (Optional) Desired level of symmetry for the faces of each block. Applies to
# standard 6-sided blocks only.
# none: All 6 faces are textured independently. This is the default.
# opposite: 2-way symmetry; opposing faces have the same texture, but each pair
# can potentially have a different texture.
# all: All 6 faces have the same texture. symmetry=<none | opposite | all>
symmetry=none will choose a random texture for each face (that it can) on the block. Note this is default, so if say, you made ores and used the random method with 7 different tile options, the faces would differ.
symmetry=all on the other hand, will use the same random texture on all (possible) faces of a block.
"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
If I'm understanding you right: try defining this: symmetry=none will choose a random texture for each face (that it can) on the block. Note this is default, so if say, you made ores and used the random method with 7 different tile options, the faces would differ.
symmetry=all on the other hand, will use the same random texture on all (possible) faces of a block.
Ah right, right, that might be more what he's looking for. I misunderstood.
If so, then yes it can be done as well. I did it with my enchanting tables, I wanted to have random cloth colors on the sides, but all 4 sides to be the same color per-block. Only way to do that was with symmetry=all, that way all 4 sides would match. They each had an "accent color". The same method could be applied to any block, just in the case of my enchanting table I only needed it for the sides.
enchanting_table_side.properties
tiles=0-8
method=random
symmetry=all
Note the sides only, they're the only part affected by the above .properties in this situation, the book and enchanting_table_top have their own properties. If the above .properies was applied to a standard block it would be the same across all 6 faces.
•Black wool and black carpet CTM isn't working properly — it appears to be using the image files for white wool and carpet, instead (see image below)
•Enchanted items' glint is not showing up at all — they look the same as unenchanted items
-
View User Profile
-
View Posts
-
Send Message
Retired StaffThis was happening for the black stained glass for me. I'm going to remake it with better textures and give it another shot. I'll post results with more details as to what I've tried, should it not work. And if I do get it to work, I'll still let you know.
-
View User Profile
-
View Posts
-
Send Message
Retired StaffOk, so I did a bit more after my reply from before, and got it all set-up and it should work. But, as said before, partial transparency does not work, and rendering order is all screwed up, seemingly even on single blocks (some sides render right, some don't).
Here's a link for you to test with:
http://www.mediafire...ained_glass.zip
Additionally, I decided to use 1 .property file for all of the CTM. I didn't see the point in making the exact same thing with a different metadata value 15 times over (even though I did to get the colors on there, ugh), because I want them to connect together (if I wanted them to be individual, I could add connect=tile it seems). The reason I'm mentioning it, is because there is no inter-block culling (not rendering inner faces between blocks) between the different types of glass, heck, inner faces are showing even in ONE type of glass!
Plus, the depth-rendering is pretty bad (yeah, I know, Mojang.....). This image pretty much sums it all up:
This issue should be fixed in the beta patcher on the previous page.
"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
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumIt was just the double plants I so no sense in applying weight to, but that was before they got matched up with ctm.
I've just done a mass of random flora for my next update (mostly for desert, fern and grass plants), but I've tended to weight things by just having less of the slightly rarer ones and more variations of the common. I'll chuck in a few very rare things later, when there's more time. Hah! that's a laugh...when do we ever get that!
Random ctm is the thing I have the most fun with though (especially as it's possible to hide little surprises in there that even delight the creator by some of the unusual places they pop up)...the rest of ctm is hard work for a dunderhead like me!
Also I noticed that the glass block you hold in your hand, or in your inventory, is the texture of and not or . How come?
Fair point, and that's one of the reasons I wanted to do a beta before making it official. The old behavior (independent tops and bottoms) should probably be the default with an option to turn on the new behavior, just so no one is caught by surprise. I'm just not sure what to call it. useSameSeedForMultiblockObjects=true doesn't exactly roll off the tongue, does it?
More precisely, (ignoring the weights property for the moment)
T = number of top textures
B = number of bottom textures
- If T and B are relatively prime: Tops and bottoms are completely scrambled.
- If gcd(T,B) > 1: Somewhat scrambled, but certain pairings will never occur.
- If T is an exact multiple of B or vice versa: Each bottom has its own separate set of potential tops (or vice versa).
- If T = B: Tops and bottoms are always in sync.
- For weighted lists, just pretend that they're unweighted lists with the textures repeated: tiles=a b c weights=1 2 3 is equivalent to tiles=a b b c c c.
Yes I was a math major, why do you ask?You could possibly do it with the divisor trickery above. Or, assuming I make the new behavior optional, by chaining two random CTMs together:
dummy_top and dummy_bottom aren't real textures. Their only purpose is to get matched by the next set of rules:
I think this problem will have to wait until mcp is updated. There's more to Mojang's new transparency handling than I originally thought, but it's too complicated to figure out in obfuscated code.
-
View User Profile
-
View Posts
-
Send Message
Retired StaffThat's an issue with your pack's custom font not being properly set up. You can delete the font folders (one under \textures\ and possibly another under \mcpatcher\) as a quick fix. Better to let your pack's artist know you're having this issue, though, so he or she can correct it. I'm reasonably sure that the issues with custom font have been fixed in MCPatcher, so now it's really up to the artist to utilized the fixed system.
As someone who's hung out with math majors... I didn't. It was obvious.
Thanks for fixing so many problems Kahr. My pack looks amazing and bug-free again!
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumNow you're scaring me!
I'll have to wait and see how someone else applies this. In the meantime I'll be more than happy with the original random method of joining the top and bottom textures, by having the middle strip the same.
Thanks, kahr.
useSameSeedAsBottomsHaveForTopsSoTheyMatchAndYouCanDrawEachDoublePlantAsOneWithOutTilingIssues=true
(don't forget to put a typo in there too so you can throw them off!)
But seriously, maybe:
textureLinking=true
textureMatching=true
textureSync=true
doubletall<Linking/Matching/Sync>=true
multiblock<Linking/Matching/Sync>=true
I can see your point, there's really not any good descriptive names for the flag. My vote would be doubletallMatching= or doubletallSync=, Its not exactly accurate, but it's pretty easy to understand what it *might* do according to just reading the flag. The only problem you run into is if Mojang uses this same method to add "Tripletall" textures, and in that case multiblock may be a better option to cover your bases.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumActually, I get that too, if I'm understanding sin-twin correctly, but only on the briefly visible loading map screen. Every other screen, whether it be options menus, or in-game gui has the font perfectly displayed. It only ever happens for me on that one loading screen just before a world loads up and the text seems to be a garbled vanilla font. Strange, but I couldn't take a screenshot just now to show an example. Have I missed something about fonts between 1.5, 1.6 and 1.7? Highly likely I have, knowing my attention to detail!
-
View User Profile
-
View Posts
-
Send Message
Retired StaffJingle 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 PremiumMixupMultiblocks=true/false
• Follow Lithos on Twitter for release announcments
* Join the Lithos Discord for previews and to help
matchTileTwins=true/false
Default false (no matching).
Putting the CENDENT back in transcendent!
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumIt looks like this got missed, so I guess I have to re-post it.Nevermind, I see the response now.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI have hybrid vertical/random CTM, if thats what you mean. My ladders, reeds, vines all have a set of random "tops", "bottoms" and "centers". Same with Bookshelves, just horizontal instead of vertical. Is this what you mean?
You could also theoretically have a random CTM that calls upon other sets of random CTM; but I'm unsure what purpose that would serve when you could simply call those files directly in one large random CTM .properties.
Example of my reeds, note they have tops, bottoms and center pieces, all random within themselves as well.
-
View User Profile
-
View Posts
-
Send Message
Retired StaffHow about you don't base it on weights or an option, but the same tile name with something like top and bottom or a and b, 1 and 2, etc.
option: useTileSets
If true, look at the name. If the name is preceded or appended with certain phrases, look for a match.
The benefit of this is that random weighted pairs don't need to match at all, and the other section can use different random CTM tiles, or not use random CTM at all!
Sets override non-sets. In the event of a pair between 2 different sets, the CTM weight
[spoiler]
If I'm understanding you right: try defining this:
symmetry=none will choose a random texture for each face (that it can) on the block. Note this is default, so if say, you made ores and used the random method with 7 different tile options, the faces would differ.
symmetry=all on the other hand, will use the same random texture on all (possible) faces of a block.
From this file.
"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
Ah right, right, that might be more what he's looking for. I misunderstood.
If so, then yes it can be done as well. I did it with my enchanting tables, I wanted to have random cloth colors on the sides, but all 4 sides to be the same color per-block. Only way to do that was with symmetry=all, that way all 4 sides would match. They each had an "accent color". The same method could be applied to any block, just in the case of my enchanting table I only needed it for the sides.
enchanting_table_side.properties
Note the sides only, they're the only part affected by the above .properties in this situation, the book and enchanting_table_top have their own properties. If the above .properies was applied to a standard block it would be the same across all 6 faces.