I think I figured out what is going on, I don't think CTM is working on stained glass panes at all. After I stripped it down to just the basic CTM, with a basic wireframe (no partial transparency what so ever just a basic CTM border) I realized its only loading the textures in /blocks/, and ignoring my CTM all together.
I downloaded your pack and took out all the renderPass=2 lines from all 16 glass_*_pane.properties files. Is this how it should look?
Thanks for the update, I'm glad a fix to remove recoloring of sugarcane was implemented!
However, looking at the mcpatcher wiki, a few issues:
Please note that the image is "flipped" vertically: The bottom of the world (y=0) is at the top of the image and the max build height (y=255) is at the bottom.
Why? Why can't up=up and down=down, what you'd logically assume? It's bad enough we have upside-down rain, snow, books, and sunflower faces (maybe more I've not noticed?) in default...... is there some technical reason people do this? I mean, does someone really sit down and say "gee, the texture should be mapped upside-down from how it appears as an asset"?
In particular, a height of 64 pixels allows for variation underground and a fixed color above sea level
I think it would be more useful if this were opposite of how it is..... as in anything underground has a fixed color, and anything above 64 uses the color map.... because you don't generally find grass at lower elevations (in vanilla generation) so the variation is useless there. Maybe the "start" and "stop" elevations could be defined?
Relating, is y-variance based on actual block y-coordinate, or colormap y-coordinate that it should use? Theoretically, if I was to make a 4px high colormap and set y-variation to 4, 2 possible results (too lazy to test this, just figured I'd ask):
based on block coordinate: no change
based on original pixel coordinate: all blocks (mostly) have the same color variation, regardless of height
Does recoloring blocks not work with partial transparency? I'm trying to do it with classic CTM for stained glass (specifically white stained glass) so I don't need 900 tiles to give them all classic CTM, and it's not working. I also want to disable backface culling, but want the transparency still.
I tried it all in 1 tile, but I need to define renderpass 3 to remove backface culling (and keep partial transparency). renderpass 3 also does not fully override textures below it, so it put the texture over the vanilla texture (which was recolored, while the CTM was not). So I tried multiple layers, the first layer (classic CTM) is recolored, the "fill" layer (renderpass 3) is not recolored. There are also major depth-sorting issues (plus, sides are rendered differently), and if I define renderpass 2 to the first layer of white-stained glass, ALL stained glass is put onto renderpass 2 (removing their transparency, I'm guessing this is what Rayvolution mentioned, is it a limitation of the rendering engine?).
If I'm not mistaken there's no reason to use render pass 3 anymore unless you need finer control over the blending method.
Can you possibly make <disable backfaceculling>, <disable lightmaps>, and blending their own per-ctm options instead of renderPass features? That way, in a case like this, I could make the tiles all-in-one classic CTM like I'd like, add in the diable-backface-culling option, and it's good, it would just use default transparency rendering. Maybe if you did that, you could add blend=glass to use vanilla stained-glass rendering (such as adding it to normal glass) for blocks that don't use it?
Also, a little error here:
# (Optional) Whether to enable backface culling during render pass 3.
# true: Culling on. Render only block sides that are facing the camera.
# false: Culling off. Do not render backfacing sides.
# The default is true.
backfaceCulling.3=<true | false>
The true/false are the same. It should read:
# (Optional) Whether to enable backface culling during render pass 3.
# true: Culling on. Render only block sides that are facing the camera.
# false: Culling off. Render backfacing sides.
# The default is true.
backfaceCulling.3=<true | false>
"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 think it would be more useful if this were opposite of how it is..... as in anything underground has a fixed color, and anything above 64 uses the color map.... because you don't generally find grass at lower elevations (in vanilla generation) so the variation is useless there. Maybe the "start" and "stop" elevations could be defined?
I figured it could be useful for underground strata. But regardless, this feature is more accidental than anything. I could add a yOffset property to do what you suggest though.
Relating, is y-variance based on actual block y-coordinate, or colormap y-coordinate that it should use? Theoretically, if I was to make a 4px high colormap and set y-variation to 4, 2 possible results (too lazy to test this, just figured I'd ask):
Variance is applied directly to the block y coordinate, before anything else. In pseudocode,
y = block.y + variance * random(-1, 1)
if (y < 0)
y = 0
if (y > colormapHeight - 1)
y = colormapHeight - 1
return map[biomeID][y]
(It's a bit more complicated. Calculation is done in floating point and linearly interpolates if it's between two integers.)
So in your example, blocks at 7 or higher would always use the bottom (y=3) pixel.
Can you possibly make <disable backfaceculling>, <disable lightmaps>, and blending their own per-ctm options instead of renderPass features?
Unfortunately it's a limitation of the renderer. GL options like blending and culling have to apply to the whole render pass, and a block is either in a particular pass or it isn't. This limitation has always been there, but it wasn't an issue until there were suddenly 16 new kinds of glass blocks.
It's also why depth sorting is such a mess now. Mojang's "fix" for stained glass was simply to turn off writing to the z-buffer during render pass 1. To be fair, doing it right is vastly more complicated, but it still leaves me in a ditch.
Well, which would you prefer? Flip the texture upside down, or mentally calculate 255 - y all the time?
Ah, right, I forgot that digital canvi were like that. It's something that has always bothered me, especially when I was messing around with flash and AS3, and going up was actually making y decrease.....
unlike in a logical and 3D sense where up is an increasing value......
I figured it could be useful for underground strata. But regardless, this feature is more accidental than anything. I could add a yOffset property to do what you suggest though.
That'd probably be perfect. Basically offsetting what the colormap applied to? Or more like the variance, where instead you you subtract from the block height and "give it a new one" and then keep going in the processing? I think (no matter how you do it internally) saying it's a "positive offset of the entire colormap" is easier to wrap my head around. For instance, with the 64px high example, you use a y offset of 64, and now 64-128 are varied, but 0-63 and 129-256 use the top and bottom pixels respectively. Again, you could do it either way, but with a negative value it just seems harder to think about.
Unfortunately it's a limitation of the renderer. GL options like blending and culling have to apply to the whole render pass, and a block is either in a particular pass or it isn't. This limitation has always been there, but it wasn't an issue until there were suddenly 16 new kinds of glass blocks.
It's also why depth sorting is such a mess now. Mojang's "fix" for stained glass was simply to turn off writing to the z-buffer during render pass 1. To be fair, doing it right is vastly more complicated, but it still leaves me in a ditch.
Is this a legacy limitation, or a long-standing one (meaning, when Minecraft needs OpenGL 2.1, will this be fixed)? And let me guess, renderPass applies (more or less) to blockIDs? (and that's why defining one stained glass as a certain renderPass puts them all into it?
Well, is there anything you can do to solve the issue I was having? Either to make some way to have renderpass 3 with overriding blending without more layers, or by making recoloring apply to all CTM layers of the selected block?
Possibly the best solution I could think of would be a new blending mode, replace/override or something like that, that would make it so the texture on the layer below was completely ignored, allowing full/partial transparency from the CTM texture to display instead. This would allow 1-layer partial-transparent renderpass 3 ctm textures.
Forgive me if there is already a blending mode for this, but the documentation on this particular feature is lacking, considering more blending modes seem to work (Rayvolution was using color, and I got subtract to work) than the stated "alpha" and "overlay".
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
Ah, right, I forgot that digital canvi were like that. It's something that has always bothered me, especially when I was messing around with flash and AS3, and going up was actually making y decrease.....
unlike in a logical and 3D sense where up is an increasing value......
but, I still don't get why Mojang does it....
It's because in programming and computer language, that's the way arrays and graph-like data structures tend to work. You begin with 0 in the top left corner, and values increase going toward the right as well as going down. It mostly just made it simpler for them to implement. If they wanted to store the colors in a way that made sense to non-programmers(the opposite way) it might require a little more code.
So the basic answer is efficiency. When they first made the biome palettes they probably just weren't thinking of the non-programmers that would use it, and changing it after that just wasn't a priority. For most people who have taken classes in Java, for example, that layout makes perfect sense. I never even noticed that most people might consider it to be upside down!
doesn't work for enchantments. It should be fixed now, and it might explain why certain enchantments of yours just weren't working.
I tried removing that when I noticed in the log that it was throwing an error. Sorry I didn't fix it before releasing a version with that in it. Changing it didn't have any effect on the main problem anyway, though.
I don't know if this had been addressed, but I've noticed an issue with using renderPass=1 or 3 on a solid block, I've been using it for my pack's Obsidian for the longest time, I'm thinking it caused by the new features brought to the new stained glass. What I've been experiencing is this.
I've experimented with putting the obsidian in renderpass=1 and it fixed the funky frame look but the renderPass=3 is still forcing it's way through the renderPass=1. I came up with the theory when I seen the renderpass forcing itself over the water graphic.
I'm thinking of just putting all my stuff under renderPass=1 and see if that will fix everything really quick... Otherwise I'll get back with you
edit
=====
Alrighty, got into things and found out how renderPass=1 doesn't actually have an 'overlay' so I can get the glass fixed but I'll have to join the textures of the door and glass, because I used renderPass=3 on top of a solid frame. This although adds another dilemma I've used renderPass=3 on my planks to give a layer to them to have random slat spacing. I'm half tempted to simply cast away the obsidian and go with what I can until I can figure things out XD.
If I try to install something, all the mods that come with the patcher are greyed out. I dint install anything by hand and deleted everything twice. wath to do? I can`t just read this theard with 481 sides. Do I do somethin wrong?
If I try to install something, all the mods that come with the patcher are greyed out. I dint install anything by hand and deleted everything twice. wath to do? I can`t just read this theard with 481 sides. Do I do somethin wrong?
You didn't tell us what version of Minecraft and which version of MCPatcher you're running for starters. We can't help you fix your problem if we don't know the details of your setup.
Make sure you have the latest version of MCPatcher if you're using 1.7.2, or the appropriate version if you're using an older Minecraft version.
I patched to the newest version of MCPatcher and was very pleasantly surprised to see that you'd added support for crops and stems. Thanks kindly, man! That really made my day, and I'm sure it'll do the same for plenty others.
Keep up the wonderful work! I'll be keeping an eye on the commits from now on for new features.
Good day!
Rollback Post to RevisionRollBack
I used to maintain the Minecraft Forums Mod List. However, life has stepped in the way of that. Perhaps later...
Glad to see MCPatcher 4.3.0 is out, even though it still needs some work I am glad it is getting updated. I don't know if anybody else is seeing what I see but the mods still don't work (I use Sphax PureBD) and none of MCPatcher mods are working. I can select them but they don't work. Hope it's not just me ....
...things I've noticed lol.
1, The north and east faces of CTM glass blocks have their left and right borders swapped.
...
I've noticed this on any repeated connected textures, as well.
The texture on each block is mirrored on the North and East facing sides.
Using the latest MCPatcher.
I've noticed this on any repeated connected textures, as well.
The texture on each block is mirrored on the North and East facing sides.
Using the latest MCPatcher.
It's not MCPatcher. It's Minecraft itself. It broke when they updated from 1,7,1 to 1,7,2.
I've noticed this on any repeated connected textures, as well.
The texture on each block is mirrored on the North and East facing sides.
Using the latest MCPatcher.
I had a thought about my issue, perhaps it's because of the use of normally solid blocks and making them translucent?
(if you didn't see it, you probably could see in my resource pack when you take some glass block behind obsidian.)
I've also done this with the wood door because I could XD, and well because the only thing I have to worry about is colored glass, I'm cool with changing that to rP=1 and having other colored glass effect it. So I'm probably gonna take my obsidian .properties out as a quick fix for that until something is found out.
If you need to know, I'm running on an ATI Radeon 2400 on an AMD Athlon dual core... and yes I'm surprised the thing still works XD.
Some of my CTM for stone brick is behaving differently for in the latest MCPatcher. Now it is applying itself to quartz slabs, but only for a single quartz slab in the upper position. I'm at a loss trying to figure out what's going on-- everything else seems to work as expected, and as it did in 1.6.x. My experimental cobble CTM also applies itself to the same quartz slabs.
File: block44side.properties
# Stonebrick Slab
metadata=5 13
method=fixed
faces=east west north south
tiles=sb_slabside
Some of my CTM for stone brick is behaving differently for in the latest MCPatcher. Now it is applying itself to quartz slabs, but only for a single quartz slab in the upper position. I'm at a loss trying to figure out what's going on-- everything else seems to work as expected, and as it did in 1.6.x. My experimental cobble CTM also applies itself to the same quartz slabs.
File: block44side.properties
# Stonebrick Slab
metadata=5 13
method=fixed
faces=east west north south
tiles=sb_slabside
No, not yet.
I downloaded your pack and took out all the renderPass=2 lines from all 16 glass_*_pane.properties files. Is this how it should look?
o_O
Very odd indeed, I had to remove renderPass=2 from all 16 panes. Seems if renderPass=2 is applied to *any* of the 16 panes, all 16 look like this.
I sincerely appreciate the help and time you invested with what is apparently my problem.
-
View User Profile
-
View Posts
-
Send Message
ModeratorIf there's anything I can do to help, don't hesitate to shoot me a PM or just ask here on this thread. Thanks.
-
View User Profile
-
View Posts
-
Send Message
Retired StaffHowever, looking at the mcpatcher wiki, a few issues:
Why? Why can't up=up and down=down, what you'd logically assume? It's bad enough we have upside-down rain, snow, books, and sunflower faces (maybe more I've not noticed?) in default...... is there some technical reason people do this? I mean, does someone really sit down and say "gee, the texture should be mapped upside-down from how it appears as an asset"?
I think it would be more useful if this were opposite of how it is..... as in anything underground has a fixed color, and anything above 64 uses the color map.... because you don't generally find grass at lower elevations (in vanilla generation) so the variation is useless there. Maybe the "start" and "stop" elevations could be defined?
Relating, is y-variance based on actual block y-coordinate, or colormap y-coordinate that it should use? Theoretically, if I was to make a 4px high colormap and set y-variation to 4, 2 possible results (too lazy to test this, just figured I'd ask):
Does recoloring blocks not work with partial transparency? I'm trying to do it with classic CTM for stained glass (specifically white stained glass) so I don't need 900 tiles to give them all classic CTM, and it's not working. I also want to disable backface culling, but want the transparency still.
I tried it all in 1 tile, but I need to define renderpass 3 to remove backface culling (and keep partial transparency). renderpass 3 also does not fully override textures below it, so it put the texture over the vanilla texture (which was recolored, while the CTM was not). So I tried multiple layers, the first layer (classic CTM) is recolored, the "fill" layer (renderpass 3) is not recolored. There are also major depth-sorting issues (plus, sides are rendered differently), and if I define renderpass 2 to the first layer of white-stained glass, ALL stained glass is put onto renderpass 2 (removing their transparency, I'm guessing this is what Rayvolution mentioned, is it a limitation of the rendering engine?).
Can you possibly make <disable backfaceculling>, <disable lightmaps>, and blending their own per-ctm options instead of renderPass features? That way, in a case like this, I could make the tiles all-in-one classic CTM like I'd like, add in the diable-backface-culling option, and it's good, it would just use default transparency rendering. Maybe if you did that, you could add blend=glass to use vanilla stained-glass rendering (such as adding it to normal glass) for blocks that don't use it?
Also, a little error here:
The true/false are the same. It should read:
"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 found part of the problem at least. It turns out this syntax
doesn't work for enchantments. It should be fixed now, and it might explain why certain enchantments of yours just weren't working.
Well, which would you prefer? Flip the texture upside down, or mentally calculate 255 - y all the time?
I figured it could be useful for underground strata. But regardless, this feature is more accidental than anything. I could add a yOffset property to do what you suggest though.
Variance is applied directly to the block y coordinate, before anything else. In pseudocode,
y = block.y + variance * random(-1, 1) if (y < 0) y = 0 if (y > colormapHeight - 1) y = colormapHeight - 1 return map[biomeID][y](It's a bit more complicated. Calculation is done in floating point and linearly interpolates if it's between two integers.)
So in your example, blocks at 7 or higher would always use the bottom (y=3) pixel.
Unfortunately it's a limitation of the renderer. GL options like blending and culling have to apply to the whole render pass, and a block is either in a particular pass or it isn't. This limitation has always been there, but it wasn't an issue until there were suddenly 16 new kinds of glass blocks.
It's also why depth sorting is such a mess now. Mojang's "fix" for stained glass was simply to turn off writing to the z-buffer during render pass 1. To be fair, doing it right is vastly more complicated, but it still leaves me in a ditch.
Whoops. Silly double negatives. Fixed.
-
View User Profile
-
View Posts
-
Send Message
Retired StaffAh, right, I forgot that digital canvi were like that. It's something that has always bothered me, especially when I was messing around with flash and AS3, and going up was actually making y decrease.....
unlike in a logical and 3D sense where up is an increasing value......
but, I still don't get why Mojang does it....
That'd probably be perfect. Basically offsetting what the colormap applied to? Or more like the variance, where instead you you subtract from the block height and "give it a new one" and then keep going in the processing? I think (no matter how you do it internally) saying it's a "positive offset of the entire colormap" is easier to wrap my head around. For instance, with the 64px high example, you use a y offset of 64, and now 64-128 are varied, but 0-63 and 129-256 use the top and bottom pixels respectively. Again, you could do it either way, but with a negative value it just seems harder to think about.
Is this a legacy limitation, or a long-standing one (meaning, when Minecraft needs OpenGL 2.1, will this be fixed)? And let me guess, renderPass applies (more or less) to blockIDs? (and that's why defining one stained glass as a certain renderPass puts them all into it?
Well, is there anything you can do to solve the issue I was having? Either to make some way to have renderpass 3 with overriding blending without more layers, or by making recoloring apply to all CTM layers of the selected block?
Possibly the best solution I could think of would be a new blending mode, replace/override or something like that, that would make it so the texture on the layer below was completely ignored, allowing full/partial transparency from the CTM texture to display instead. This would allow 1-layer partial-transparent renderpass 3 ctm textures.
Forgive me if there is already a blending mode for this, but the documentation on this particular feature is lacking, considering more blending modes seem to work (Rayvolution was using color, and I got subtract to work) than the stated "alpha" and "overlay".
"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
It's because in programming and computer language, that's the way arrays and graph-like data structures tend to work. You begin with 0 in the top left corner, and values increase going toward the right as well as going down. It mostly just made it simpler for them to implement. If they wanted to store the colors in a way that made sense to non-programmers(the opposite way) it might require a little more code.
So the basic answer is efficiency. When they first made the biome palettes they probably just weren't thinking of the non-programmers that would use it, and changing it after that just wasn't a priority. For most people who have taken classes in Java, for example, that layout makes perfect sense. I never even noticed that most people might consider it to be upside down!
-
View User Profile
-
View Posts
-
Send Message
Moderator-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI've experimented with putting the obsidian in renderpass=1 and it fixed the funky frame look but the renderPass=3 is still forcing it's way through the renderPass=1. I came up with the theory when I seen the renderpass forcing itself over the water graphic.
I'm thinking of just putting all my stuff under renderPass=1 and see if that will fix everything really quick... Otherwise I'll get back with you
edit
=====
Alrighty, got into things and found out how renderPass=1 doesn't actually have an 'overlay' so I can get the glass fixed but I'll have to join the textures of the door and glass, because I used renderPass=3 on top of a solid frame. This although adds another dilemma I've used renderPass=3 on my planks to give a layer to them to have random slat spacing. I'm half tempted to simply cast away the obsidian and go with what I can until I can figure things out XD.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumYou might have an older version of MCPatcher.
-
View User Profile
-
View Posts
-
Send Message
ModeratorMake sure you have the latest version of MCPatcher if you're using 1.7.2, or the appropriate version if you're using an older Minecraft version.
-
View User Profile
-
View Posts
-
Send Message
Retired StaffKeep up the wonderful work! I'll be keeping an eye on the commits from now on for new features.
Good day!
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumJust mcpatcher and Zans standalone http://pastebin.com/Yxk390ki
Modloader version and mcpatcher http://pastebin.com/3hwQkRDq
Mods I work on and maintain:
TabbyChat | Mine Little Pony
My Blog
I've noticed this on any repeated connected textures, as well.
The texture on each block is mirrored on the North and East facing sides.
Using the latest MCPatcher.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumIt's not MCPatcher. It's Minecraft itself. It broke when they updated from 1,7,1 to 1,7,2.
That's https://mojang.atlassian.net/browse/MC-37106 , will be fixed in the upcoming Minecraft 1.7.3
-
View User Profile
-
View Posts
-
Send Message
Curse Premium(if you didn't see it, you probably could see in my resource pack when you take some glass block behind obsidian.)
I've also done this with the wood door because I could XD, and well because the only thing I have to worry about is colored glass, I'm cool with changing that to rP=1 and having other colored glass effect it. So I'm probably gonna take my obsidian .properties out as a quick fix for that until something is found out.
If you need to know, I'm running on an ATI Radeon 2400 on an AMD Athlon dual core... and yes I'm surprised the thing still works XD.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumFile: block44side.properties
File: block44top.properties
You can also see the glitch in action in my pack (click my sig). Does this make sense to anybody?
• Follow Lithos on Twitter for release announcments
* Join the Lithos Discord for previews and to help
It's a bug in mcpatcher with metadata of 15. Apparently its fixed in the next release, along with the custom biome colors bug.
Putting the CENDENT back in transcendent!