Glass Panes are still ignoring the new partial transparency added in 1.7, but only when you load a resource pack that uses Better Glass (even if Better Glass isnt even applied to the block!)
Even more research is showing some really odd behavior, with *all* properties files removed, *all* custom textures removed for lime stained glass, I get this. But it only happens when a resource pack is loaded that uses Better Glass, NOT with defaults. But, it can't be my pack, because in this image there is no .properties files OR textures at all effecting the lime colored glass.
I think this might be because of that vanilla bug where the texture on the North East side (or whatever it is) of all blocks are flipped. For example, my Connected Texture glass is fine when I place it in two directions, but not when I place them in two other directions.
I think this might be because of that vanilla bug where the texture on the North East side (or whatever it is) of all blocks are flipped. For example, my Connected Texture glass is fine when I place it in two directions, but not when I place them in two other directions.
That's a totally different bug, unrelated to MCPatcher and my problem..
So, quick issue here.I've been trying to get fixed colormaps to work, and I succeeded, but only by making all colormaps fixed by using the global variable in color.properties.Here is the current working scenario.
Adding the file source doesn't help either, as it doesn't seem to even be loading the properties file. I set stuff that'd cause MCPatcher to error in the console if it loaded the file, and moving it all around resulted in no mention of the file.
Moving grass.png to anywhere outside of that blocks folder makes the colormap not even load at all, and instead it loads the vanilla map.
Here is the current colormap which only works for the ocean biome if it's in the fixed format. If MCPatcher attempts to read it in the vanilla format, the ocean turns black letting me know. It also makes the grass green at y255.
Bug Report! With MCPatcher installed, the particles that surround the player when under the effect of a potion are completely opaque. This happens even when under the effect of a beacon, where the particles are barely visible in vanilla.
If I remember this right, Endermen were not allowed to pick up player placed blocks in an earlier version. Also, how do anti grief tools for Minecraft servers check block placement by the player? I may be wrong though.
You're wrong on the first count, and somewhat mislead on the second. Endermen were always able to pic up any block that they're able to pick up (the number of block has changed with the versions), but this never had anything to do with what players placed.
For the anti-griefing tools, if they keep track of what blocks players have placed they build a database of changes made. These aren't stored in the normal level files. At least that's my understanding from having read stuff. If I'm wrong, someone please correct me.
Regardless, MCPatcher won't (and shouldn't) do this because it requires writing of extra information which it avoids for the most part. Even if Kahr did implement this, it wouldn't work on servers or at least would reset when you log out for the same reason that RandomMobs will change the skins of persistent mobs with each server login.
Sorry. It's a cool feature idea. Maybe someday Mojang will care about griefing enough to implement their own anti-griefing tools which MCpatcher could read... but it probably won't be any time soon.
I need a little help. I use magic launcher but can't get 1.7.2, MC Patcher and Magic Launcher to work nicely. I tried to download a fresh 1.7.2 via the official launcher, but when I patch it with MC Patcher, it only gives a 1.7 Mc Patcher version :/
Nevermind. I discovered that you can refresh the versions list
I don't know whether this belongs here or in Misa's thread but I'll post it anyways.
Black Hardened Clay and White Hardened clay now share the same appearance while all other Colored Hardened Clay blocks remain as they should be.
So, quick issue here.I've been trying to get fixed colormaps to work, and I succeeded, but only by making all colormaps fixed by using the global variable in color.properties.
With v4.3.0 & MC 1.7.2 Iron golems hold out their hands to offer roses/poppies, but the flower is not displayed. This is the same with the default pack as with a texture pack.
Possibly fixed. I'm pretty sure this is the same as Leischii's problem.
Glass Panes are still ignoring the new partial transparency added in 1.7, but only when you load a resource pack that uses Better Glass (even if Better Glass isnt even applied to the block!)
Render pass 2 isn't supposed to support transparency. It only differs from render pass 0 in that it disables backface culling. Use render pass 1 instead.
Here are the render passes in the order they happen in-game:
0: On/off transparency, with backface culling (vanilla)
2: On/off transparency, without backface culling (added by Better Glass)
1: Transparent blocks with alpha blending and no depth sorting (vanilla)
3: Transparent blocks with customizable blending (added by Better Glass)
When you put renderPass=n in a ctm properties file, you are assigning the block a new render pass, either by replacing (0-2) or adding (3).
If I'm not mistaken there's no reason to use render pass 3 anymore unless you need finer control over the blending method.
With MCPatcher installed, the particles that surround the player when under the effect of a potion are completely opaque. This happens even when under the effect of a beacon, where the particles are barely visible in vanilla.
Render pass 2 isn't supposed to support transparency. It only differs from render pass 0 in that it disables backface culling. Use render pass 1 instead.
Here are the render passes in the order they happen in-game:
0: On/off transparency, with backface culling (vanilla)
2: On/off transparency, without backface culling (added by Better Glass)
1: Transparent blocks with alpha blending and no depth sorting (vanilla)
3: Transparent blocks with customizable blending (added by Better Glass)
When you put renderPass=n in a ctm properties file, you are assigning the block a new render pass, either by replacing (0-2) or adding (3).
If I'm not mistaken there's no reason to use render pass 3 anymore unless you need finer control over the blending method.
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.
As for renderPass=3, I actually am using blend.3=color, so that's why I injected it into the "shiny" parts of my glass (As seen on the top 2 rows of regular glass panes)
EDIT: Now lets make this even more confusing, because my method=random CTM that is overlayed ontop of it (it's disabled in the shot above) works fine.
This is quite confusing, I invite you to download my pack and look at it. Because I'm not exactly sure whats going on.. but all I can tell is it's a much more simple problem than I realized; method=CTM just simply isnt working on panes.
The reason everything was solid had nothing to do with it. Just happens my placeholder glass in /blocks/ (that should never be loading because of the properties files) are solid, and since method=CTM isnt working, it was loading them.
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?
I think this might be because of that vanilla bug where the texture on the North East side (or whatever it is) of all blocks are flipped. For example, my Connected Texture glass is fine when I place it in two directions, but not when I place them in two other directions.
That's a totally different bug, unrelated to MCPatcher and my problem..
In grass.properties, you put "palette.format" when it should be "format"
Putting the CENDENT back in transcendent!
-
View User Profile
-
View Posts
-
Send Message
Curse Premium-
View User Profile
-
View Posts
-
Send Message
Retired Staff...And it's really annoying.
Thanks in advance for fixing this Kahr!
-
View User Profile
-
View Posts
-
Send Message
Retired StaffFor the anti-griefing tools, if they keep track of what blocks players have placed they build a database of changes made. These aren't stored in the normal level files. At least that's my understanding from having read stuff. If I'm wrong, someone please correct me.
Regardless, MCPatcher won't (and shouldn't) do this because it requires writing of extra information which it avoids for the most part. Even if Kahr did implement this, it wouldn't work on servers or at least would reset when you log out for the same reason that RandomMobs will change the skins of persistent mobs with each server login.
Sorry. It's a cool feature idea. Maybe someday Mojang will care about griefing enough to implement their own anti-griefing tools which MCpatcher could read... but it probably won't be any time soon.
I need a little help. I use magic launcher but can't get 1.7.2, MC Patcher and Magic Launcher to work nicely. I tried to download a fresh 1.7.2 via the official launcher, but when I patch it with MC Patcher, it only gives a 1.7 Mc Patcher version :/Nevermind. I discovered that you can refresh the versions list
Fixed.
Fixed.
Fixed.
Fixed.
Possibly fixed. I'm pretty sure this is the same as Leischii's problem.
Render pass 2 isn't supposed to support transparency. It only differs from render pass 0 in that it disables backface culling. Use render pass 1 instead.
Here are the render passes in the order they happen in-game:
0: On/off transparency, with backface culling (vanilla)
2: On/off transparency, without backface culling (added by Better Glass)
1: Transparent blocks with alpha blending and no depth sorting (vanilla)
3: Transparent blocks with customizable blending (added by Better Glass)
When you put renderPass=n in a ctm properties file, you are assigning the block a new render pass, either by replacing (0-2) or adding (3).
If I'm not mistaken there's no reason to use render pass 3 anymore unless you need finer control over the blending method.
Fixed. Related to the black/white stained clay bug it turns out.
Fixed.
-
View User Profile
-
View Posts
-
Send Message
Retired StaffAny luck figuring out why CIT is ignoring weights one some items yet?
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.
lime pane's .properties file (Bottom 2 rows)
As for renderPass=3, I actually am using blend.3=color, so that's why I injected it into the "shiny" parts of my glass (As seen on the top 2 rows of regular glass panes)
EDIT: Now lets make this even more confusing, because my method=random CTM that is overlayed ontop of it (it's disabled in the shot above) works fine.
This is quite confusing, I invite you to download my pack and look at it. Because I'm not exactly sure whats going on.. but all I can tell is it's a much more simple problem than I realized; method=CTM just simply isnt working on panes.
The reason everything was solid had nothing to do with it. Just happens my placeholder glass in /blocks/ (that should never be loading because of the properties files) are solid, and since method=CTM isnt working, it was loading them.
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
Retired StaffIf 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
Retired Staff-
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.