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.
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:
•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)
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.
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
ModeratorAt 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.
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.
•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
ModeratorThat'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.