Could you add more information to your guide about Connection Type and Metadata?
It took me the longest time to figure out that what to actually type in for metadata (I'm probably still not completely comfortable with it). There is a list of data values on the wiki, but that isn't enough information for people new to this. Do you type in metadata=0x3 or just 3? And if there are multiple bits of metadata you want to apply to the same block? (i.e. an upside down cobblestone slab) Or if you want a single ctm to apply to both an upsidedown cobblestone slab and a right-side-up cobblestone slab. It'd be helpful to have all that spelled out explicitly in the guide.
As for connection type, I'm still not sure what that means or how to use it. Do you mean that I could have one ctm for birch slabs, one ctm for birch blocks, and I can use the material option for connection type to give them a third ctm when they are placed next to each other?
It'd be great to have a list of all the block names too. The data values page on the wiki doesn't have that. grass_side_snowed, leaves_oak_opaque, potatoes_stage_0, etc.
Could you add more information to your guide about Connection Type and Metadata?
It took me the longest time to figure out that what to actually type in for metadata (I'm probably still not completely comfortable with it). There is a list of data values on the wiki, but that isn't enough information for people new to this. Do you type in metadata=0x3 or just 3? And if there are multiple bits of metadata you want to apply to the same block? (i.e. an upside down cobblestone slab) Or if you want a single ctm to apply to both an upsidedown cobblestone slab and a right-side-up cobblestone slab. It'd be helpful to have all that spelled out explicitly in the guide.
First off, just about everything you've said requires a separate properties file except in the case of applying a single texture to multiple states of a block (in the case of stairs being right side up and upside down). You can list Metadata values in the same manner as other information. (ie: "metadata=0 1 5 6 9 10").
Metadata refers to different states of a block. Something like Hardened Clay blocks where they all use the same block ID but use the metadata for each color:
As for connection type, I'm still not sure what that means or how to use it. Do you mean that I could have one ctm for birch slabs, one ctm for birch blocks, and I can use the material option for connection type to give them a third ctm when they are placed next to each other?
The above would not work. One thing to remember is that you can only have one CTM rule applied to any one side of a block. You could use the CTM layering or Renderpass to get past that rule, but I don't have any experience in those and don't know how well that would work or if it could work to produce the above.
From what I understand (and I hope I don't steer you wrong) is that connection type allows Birch blocks to connect with Oak blocks if connection type is set to "material". Since both are wood, they would then connect. Beyond that, you'd have to experiment or hope someone more knowledgeable checks in.
It'd be great to have a list of all the block names too. The data values page on the wiki doesn't have that. grass_side_snowed, leaves_oak_opaque, potatoes_stage_0, etc.
That information is already in your textures>blocks folder.
Another example of metadata usage, this time on upside down stairs.
I don't have any resources to help you with figuring out the Metadata. I just enter values until I find out the side I want. I learn best when i take the basics and figure out how and why they work the way they do.
--Correction--
"the metadata values PLACE this texture"
I should have also mentioned that those values are specific to the upside down stair sides. A different set of values specific to the sides of the right-side up stairs. The top and bottom textures are different metadata values again, each specific to the right-side up and upside down stairs.
If you have a texture for a specific metadata... place the block in the way you want it in a world, then open it with MCEdit, select the block and press "analyze"; that will give you block ID and metadata... that's the way I usually tried
And one more question... As I noticed, the non-main textures of furnaces (non-lit faces, top & bottom), droppers (not-dropping faces) and dispensers (not dispensing faces) use all the same textures (furnace_side & furnace_top) - Is it possible to have a classic CTM for these faces, probably even between droppers, dispensers & furnaces? I'd also be happy if it's "just" a classic CTM for these faces...
Well, I have found something curious. If you use the following block properties: block23.properties
matchTiles=furnace_side.png
tiles=0
method=fixed
faces=all
if will change all the sides that use the furnace_side.png including the front of the dispenser, but not furnace or dropper.
If you use the following file: furnace_side.properties
matchTiles=furnace_side.png
tiles=0
method=fixed
faces=all
It will change only the faces that use furnace_side.png.
To answer your question, YES. It is possible to CTM the sides and/or tops of the three blocks using the matchTiles rule and a file name other than the block name.
On the flip side, I don't know if you could make them connect. I have zero experience with using the connection type rule and have yet to successfully use it.
Does McEdit have any information on a blocks material type? I think that's the only way you could make the three blocks connect together is if they were all classified as the type material.
Of course, you'll want to change the method to CTM from fixed. I was just using fixed to see how to apply the rule to that specific face.
You sir are truly a master... tried it, works brilliant... looked that good that I added ctm parts for all other faces of the blocks attached (furnace_off, furnace_on, dispenser_vertical, dispenser_horizontal, dropper_horizontal, dropper_vertical)... Have a look at YOUR result
Thanks a lot, I'll add credit to you in the PMC Post!
PS: Directly used your config files (modified only the face names, method to ctm and the tiles); No MCEdit was necessary
And if you mean metadata with block material data - yes it does.
You don't need to credit me with anything. And I knew it was possible because I was sure I had seen a resource pack with furnaces that would CTM to make large ovens/fireplaces.
Results look good. Glad to have been a help. Sorry for time between posts. X_x
I have run into a problem concerning ctm for wooden fences and wooden buttons.
The fences:
Up until today I used ctm only for the top and bottom parts of the fences, since the folding method Mojang uses is a horrible mess. Then I discovered in the other McPatcher post Thaylars method to make the fences look right on all sides. Thus I changed a few files, added some more pngs and the respective property files. The top and bottom ctm still shows fine, as it should. the ctm for the sides however doesn't show at all. I checked the property files, the tiles numbers are matching the png file and so on, but no matter what I try, it does not work at all.
block85.properties
metadata=0
tiles=8
method=fixed
faces=sides
I also tried it without the metadata=0, still no change.
The strange thing, I am also using ctm on the nether fences. Same methods and so on like for wooden fences and it works, sides and all. I just don't get it ...
The buttons:
I had the button ctm since 1.4. (? I belive) So far it worked fine. As of today, the png file was saved with a new name, the properties file changed accordingly. I also deleted all the old files in the tp itself, deleted the tp from the resourcepack folder, repacked it again and put it back to the mc folder. Now the buttons show the ctm on the sides, meaning no matter how I place it (on which side of a block) the front has no ctm at all, but the small sides (including top and bottom) have ctm applied.
block143.properties
faces=all
method=fixed
tiles=7
Some help would be greatly appreicated, that stuff is driving me up a wall <.<*
This is most likely because oyu have ctm for for other blocks that are in default layered ontop of those blocks, oak_plank onto fence etc. Look and see if you have any oak_planks.properties file, jsut simply rename it to the block# with a metadata. Althoguht I beleive the block# are being removed in 1.7, so you might want to redo all your block# files. I am uncertain of what we are going to use from now on, lurk aorund I guess xD gl.
holy crap... If you think fences are bad, gates jump metadata values depending on which direction you open or close them....working on a wooden gate template. Don't expect it soon. Sometime today, hopefully.
I think the wooden gates are going to defeat me. I can't find where the game is pulling the top of the gate texture from (other than planks_oak.png) in order to replace it. It does not appear to have a metadata value associated with block ID 107 (which is a wooden gate). Give it no metadata value is the same as giving it all metadata values.
As one can see, the texture will only apply itself to the top if placed on an East/West axis, or when the gate opens with the doors on an East/West axis. How the North/South axis texture is being assigned to the object is beyond me...I think. Even using a matchTile=planks_oak.png will not change the texture.
Anyone have any better ideas?
*Edit* bottom textures pull from the CTM value. Top textures do not.
I have a question: how would one go about randomizing the new double plants (like the double grass/ferns/rosebushes/etc)? I'm familiar with the traditional way, like for example:
flower_dandelion.properties
tiles=240-251
method=random
But how would I name the tiles needed for the two images required to render one double plant? And what would I call the .properties file? Or has CTM yet to be implemented/figured out for this?
Thaylar, try filling in the unused space with various striped lines and see where they are.
I have done that for other problems, but the gate seems unique.
The problem is that I simply can't find the value assigned to the texture. Here is a brief description of the methodology used up till the posting above:
Make 16 images, all identical, but numbered 1 through 15.
Make 16 .properties files all identical, except for each one having a specific metadata that matched the numbered images.
Play with the gate in the game placing/using it in different ways.
I guess, I didn't try metadata values past 15. I just run out of ideas.
Well... it would be bothersome to use since every block that uses renderpass 3 would glow in the dark.
Which wouldn't be too bad if you're using it just for this. The problem is that the possibilities for improved glass textures go out the window. On the other hand if you don't want to use semi-transparent glass... then that's fine. Have fun with glowey textures.
This is the kinda thing you need to plan your MCPatcher strategy around since you can't really have both, unfortunately...
I recently saw a ctm-based glow for various blocks using multiple texture layers...
Check the "main" post here for the idea - http://www.minecraft...0#entry25776513
As far as I understood that - I need two texture sets for the glowing blocks - once the base texture, once the glowing parts;
then I need to define another renderPass in renderpass.properties (mcpatcher directory) and use that for the properties...
Any ideas on a possible config? (I plan to use it for redstone-related blocks)
To be clear:
~/mcpatcher/renderpass.properties:
enableLightmap.3=false
And then define any CTM texture as renderPass=3
Note, you do NOT need to define both layers using CTM. Renderpass 3 will NOT completely override the texture below it, the screenshot I used is the VANILLA mapping with just the "glowing" layer added using CTM.
Also, do you need to define stained glass CTM textures as renderPass 3? If not, I'd say well dernet why didn't they make glass render the same as stained glass? That's not cool
"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 planned on making the redstone mechanisms (so no ctm'd base) and some metadata blocks (kinda ctm'ed base) to work with that fake glow. I'm not sure if my stained glass uses renderPass 3, but I believe not - Couldn't I just define a renderPass 4?
Could you post the both textures you used? (I'm not completely sure how doing it works perfectly, I assume base texture and then only the "glowing" layer as texture with the render pass 3 (or the one that was defined to work like that).
If I get that to work... LED-seamed wooden outdoor planks, I come!
You cannot define renderpass 4 because renderpasses are not arbitrary-they are set values that define in what order CTM features are rendered and also how they are rendered (what features they support such as transparency and non-backface culling). As far as I am aware (through basic testing), this only applies to CTM-ed stuff as part of the layer that MCpatcher patches in for piping the rendering stuff to make it all happen. Only what you define to a renderpass should be on that renderpass.
The "base" you can kinda see in the dark is just my activator rail texture as defined through normal methods.
This is the "glowing" part of the texture, however note that the black is actually transparent in what I used (I made it black for visibility) and the white parts are actually like 11% opaque, just to make it feel more like it's "glowing".
I just mapped it to block157, and because I defined renderPass=3 as well, the regular texture remained under the glowy one.
So yes, it seems you get it. The only caveat here is that you must define the texture through a BLOCK method, not a TILE one. I used block157.properties and that worked, and I tried matchTiles on the dispenser face and it threw me the error that only block-methods can have renderpass 3.
Also, I had the idea to make my dispensers have glowy eyes, found that they had a "powered" metadata, however, it only applies if a dispenser shot and then received a block update (like placing a block near it) at which point it would stay on. So that's out of the picture because it can't be just when it's firing and I don't just want to give away their presence in the dark (by making it apply all the time).
That's one issue I have with this, is that it has the potential to "cater" towards the player, or "spoil" them in a way. As said above, if I made dispensers have glowy eyes, it would alert players of a dispenser. Similarly, I don't want to make tripwires or pressure plates stand out, as then players would more easily see it and could avoid them. I might do this for the redstone stuff, especially the stuff that doesn't glow. I don't really see an issue with redstone-rail stuff and blocks of redstone, not really sure why they don't glow in the first place. I guess you could use it as a trap for TNT/command block minecarts, but I'm not too concerned about something like that.
The LED thing..... not my taste..... maybe if it was a movie theater or something.... which this practice could be pretty cool for custom maps and such, I just hope artists don't break them with it.
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
After a long talk with insomniac_lemon yesterday, I took some time on the overlay...
I'll improve that later (and I'll add slabs & stairs of that kind too)
Let me introduce you to LED stripes in planks!
[spoiler='Screenshots inside']
For those who wondered about the default textures in the background:
For testing new features on my (pretty crappy) machine, I usually make a new pack that only includes the updated textures.
Some of many applications of that could be airport / street lights, bar tables & walls, but also swimming pool borders or balconies
Looks like the proper way of making a Tron resource pack.
You're looking for the section on metadata.
It took me the longest time to figure out that what to actually type in for metadata (I'm probably still not completely comfortable with it). There is a list of data values on the wiki, but that isn't enough information for people new to this. Do you type in metadata=0x3 or just 3? And if there are multiple bits of metadata you want to apply to the same block? (i.e. an upside down cobblestone slab) Or if you want a single ctm to apply to both an upsidedown cobblestone slab and a right-side-up cobblestone slab. It'd be helpful to have all that spelled out explicitly in the guide.
As for connection type, I'm still not sure what that means or how to use it. Do you mean that I could have one ctm for birch slabs, one ctm for birch blocks, and I can use the material option for connection type to give them a third ctm when they are placed next to each other?
Owner & Creator of Aquain, a huge underwater city on the Opticraft server. Check out info on my underwater city here. Also creator of an art deco-like resource pack to go along with the city. Help me develop my resource pack here.
Owner & Creator of Aquain, a huge underwater city on the Opticraft server. Check out info on my underwater city here. Also creator of an art deco-like resource pack to go along with the city. Help me develop my resource pack here.
First off, just about everything you've said requires a separate properties file except in the case of applying a single texture to multiple states of a block (in the case of stairs being right side up and upside down). You can list Metadata values in the same manner as other information. (ie: "metadata=0 1 5 6 9 10").
Metadata refers to different states of a block. Something like Hardened Clay blocks where they all use the same block ID but use the metadata for each color:
The above would not work. One thing to remember is that you can only have one CTM rule applied to any one side of a block. You could use the CTM layering or Renderpass to get past that rule, but I don't have any experience in those and don't know how well that would work or if it could work to produce the above.
From what I understand (and I hope I don't steer you wrong) is that connection type allows Birch blocks to connect with Oak blocks if connection type is set to "material". Since both are wood, they would then connect. Beyond that, you'd have to experiment or hope someone more knowledgeable checks in.
That information is already in your textures>blocks folder.
I don't have any resources to help you with figuring out the Metadata. I just enter values until I find out the side I want. I learn best when i take the basics and figure out how and why they work the way they do.
--Correction--
"the metadata values PLACE this texture"
I should have also mentioned that those values are specific to the upside down stair sides. A different set of values specific to the sides of the right-side up stairs. The top and bottom textures are different metadata values again, each specific to the right-side up and upside down stairs.
Anyways, it may be useful to add the faces next to the rules a particular CTM method can apply itself to.
Well, I have found something curious. If you use the following block properties:
block23.properties
matchTiles=furnace_side.png
tiles=0
method=fixed
faces=all
if will change all the sides that use the furnace_side.png including the front of the dispenser, but not furnace or dropper.
If you use the following file:
furnace_side.properties
matchTiles=furnace_side.png
tiles=0
method=fixed
faces=all
It will change only the faces that use furnace_side.png.
To answer your question, YES. It is possible to CTM the sides and/or tops of the three blocks using the matchTiles rule and a file name other than the block name.
On the flip side, I don't know if you could make them connect. I have zero experience with using the connection type rule and have yet to successfully use it.
Does McEdit have any information on a blocks material type? I think that's the only way you could make the three blocks connect together is if they were all classified as the type material.
Of course, you'll want to change the method to CTM from fixed. I was just using fixed to see how to apply the rule to that specific face.
You don't need to credit me with anything. And I knew it was possible because I was sure I had seen a resource pack with furnaces that would CTM to make large ovens/fireplaces.
Results look good. Glad to have been a help. Sorry for time between posts. X_x
This is most likely because oyu have ctm for for other blocks that are in default layered ontop of those blocks, oak_plank onto fence etc. Look and see if you have any oak_planks.properties file, jsut simply rename it to the block# with a metadata. Althoguht I beleive the block# are being removed in 1.7, so you might want to redo all your block# files. I am uncertain of what we are going to use from now on, lurk aorund I guess xD gl.
I think the wooden gates are going to defeat me. I can't find where the game is pulling the top of the gate texture from (other than planks_oak.png) in order to replace it. It does not appear to have a metadata value associated with block ID 107 (which is a wooden gate). Give it no metadata value is the same as giving it all metadata values.
>block107.properties
metadata=0-15
tiles=2
method=fixed
faces=top bottom
As one can see, the texture will only apply itself to the top if placed on an East/West axis, or when the gate opens with the doors on an East/West axis. How the North/South axis texture is being assigned to the object is beyond me...I think. Even using a matchTile=planks_oak.png will not change the texture.
Anyone have any better ideas?
*Edit* bottom textures pull from the CTM value. Top textures do not.
Thaylar, try filling in the unused space with various striped lines and see where they are.
I have a question: how would one go about randomizing the new double plants (like the double grass/ferns/rosebushes/etc)? I'm familiar with the traditional way, like for example:
flower_dandelion.properties
But how would I name the tiles needed for the two images required to render one double plant? And what would I call the .properties file? Or has CTM yet to be implemented/figured out for this?
I have done that for other problems, but the gate seems unique.
The problem is that I simply can't find the value assigned to the texture. Here is a brief description of the methodology used up till the posting above:
I guess, I didn't try metadata values past 15. I just run out of ideas.
This is the kinda thing you need to plan your MCPatcher strategy around since you can't really have both, unfortunately...
To be clear:
~/mcpatcher/renderpass.properties:
And then define any CTM texture as renderPass=3
Note, you do NOT need to define both layers using CTM. Renderpass 3 will NOT completely override the texture below it, the screenshot I used is the VANILLA mapping with just the "glowing" layer added using CTM.
Also, do you need to define stained glass CTM textures as renderPass 3? If not, I'd say well dernet why didn't they make glass render the same as stained glass? That's not cool
"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
You cannot define renderpass 4 because renderpasses are not arbitrary-they are set values that define in what order CTM features are rendered and also how they are rendered (what features they support such as transparency and non-backface culling). As far as I am aware (through basic testing), this only applies to CTM-ed stuff as part of the layer that MCpatcher patches in for piping the rendering stuff to make it all happen. Only what you define to a renderpass should be on that renderpass.
The "base" you can kinda see in the dark is just my activator rail texture as defined through normal methods.
This is the "glowing" part of the texture, however note that the black is actually transparent in what I used (I made it black for visibility) and the white parts are actually like 11% opaque, just to make it feel more like it's "glowing".
I just mapped it to block157, and because I defined renderPass=3 as well, the regular texture remained under the glowy one.
So yes, it seems you get it. The only caveat here is that you must define the texture through a BLOCK method, not a TILE one. I used block157.properties and that worked, and I tried matchTiles on the dispenser face and it threw me the error that only block-methods can have renderpass 3.
Also, I had the idea to make my dispensers have glowy eyes, found that they had a "powered" metadata, however, it only applies if a dispenser shot and then received a block update (like placing a block near it) at which point it would stay on. So that's out of the picture because it can't be just when it's firing and I don't just want to give away their presence in the dark (by making it apply all the time).
That's one issue I have with this, is that it has the potential to "cater" towards the player, or "spoil" them in a way. As said above, if I made dispensers have glowy eyes, it would alert players of a dispenser. Similarly, I don't want to make tripwires or pressure plates stand out, as then players would more easily see it and could avoid them. I might do this for the redstone stuff, especially the stuff that doesn't glow. I don't really see an issue with redstone-rail stuff and blocks of redstone, not really sure why they don't glow in the first place. I guess you could use it as a trap for TNT/command block minecarts, but I'm not too concerned about something like that.
The LED thing..... not my taste..... maybe if it was a movie theater or something.... which this practice could be pretty cool for custom maps and such, I just hope artists don't break them with it.
"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
Thanks for the prompt answer. I had figured that the case might be something like this but I had to confirm. Thank you again.
Looks like the proper way of making a Tron resource pack.