Minecraft Forums

I don't make texture packs but I do use them. How will this idea benefit me?
The idea is to have a text file texture pack creators could include inside their texture packs. It would allow them to fully control how terrain.png (where all of the block textures are located) in their texture pack is read

One of the greatest changes texture pack users like yourself would notice, is the ability to change what
each face of any block looks like. Some textures look good on the side of a block, but not the top (especially when the texture is very shaded, or is asymmetric in some way, or the texture does not connect to the sides properly). This idea would allow texture packs to change faces of even half slabs.

If doors have too wide of a window, or if they create shading, it goes on the left and right edges of the door. Doors have hinges on every face. Trapdoors usually show shading on the sides from holes in the top. Stone pressure plates and buttons remain unseen against stone. Pistons cannot have a metal arm and a wooden head, as the crafting recipe would imply.All of these problems could be solved by a texture pack creator if this idea were implemented.

This idea might even allow for cool effects such as obsidian as a portal frame looking different, or blocks having a different appearance in different dimensions.


I am making a texture pack. I hear you have an idea.

Are you constantly finding yourself frustrated when you can't change one texture without ruining another?
t would be this text file that you would make that would allow you to customized what blocks use what textures in many different ways.

Most importantly, it would allow you to change current derivative textures in minecraft.

If you don't get what I mean by derivative textures, I mean things like:

• Fence textures
• Piston arm texture
• Piston head side texture
• Stairs
• Half Slabs
• Buttons
• Pressure plates
• ect.

You could change the derivative textures of these, or give them dedicated textures. You also can give blocks more than one texture.





Now, I know what you're thinking (possibly). That something like this will be having texture artists overly use this causing more a decrease in performance. It would allow artists to not only make more derivative textures, and take blocks with (in default) multiple textures and make them use one texture for all sides.

Also, possibly the best part of this idea, would be the ability to use greyscale. This idea would allow you to take one texture, make it grayscale, and give it color (like biomes do) with your choice of color in hexadecimal color code (#000000) format.

When would grayscale be useful? For things taking up a bunch of room in your terrain.png that look identical with only changing color (wools, planks). This would allow you to cut greatly on texture space, allowing you space that you know won't be used by new textures in the future, as well less redundancy. When looking at your terrain.png file.

So, you're interested, and wondering: How might I do this for my texture pack if this idea were implemented?

Well, like I said, this would all be done using a text file. It would look similar to how the .lang files look. You'll get what I mean if you open up en_us.lang with a basic text editor, and you'll see what I mean with the example. I looked at the newer version, and it looks bad. It used to look like this, though (*shakes fist at crowdin*) :





So I'll show you how to make a basic texture re-assign. In my texture pack, my sandstone texture is rough-looking, Like something you would see on the outside of an Egyptian pyramid, so I don't really need 3 textures for it. Just one. So, with this idea, this is how I'd do it:

tile.sandstone.texture= tile(0, 12);

So, it's that simple. What does tile do? It would be a way of defining a perfect square, specifically how Minecraft reads them. This will not need to change with the resolution of the pack. The number ranges from 0-15, and is in (x,y) format. Imagine the texture spaces as you use them now as a grid. For example: Grass is (0,0), bedrock is (1,1), sugarcane is (9,4). Tile is useful when you're working with very large images.

So what about textures that don't fit in those tiles?
Rect. Rect would be just like tile only pixel based. This would allow you to assign a non-normal grid or non-square texture. You would use this for many of the derivative textures.

For example, in my texture pack, I want a piston head side that is different from the piston arm side texture:

tile.pistonHead.arm.texture= rect(0,208, 15,211);

Well why did I place it there? Well, I just freed up space by making sandstone use one texture, So I put it below where the sandstone side used to go. As I told you, rect is pixel based. It is in the format of (x1,y1, x2,y2). The first set of coordinates is the top left corner, and the second set is the bottom right corner. What about the side of the piston head I talked about? It would stay in the same place, as with the new system they would be separated (but with the same texture in vanilla) and it you specify one, the other would derive from its original texture space. Minecraft would use the original texture locations for unspecified models, just as if you had missing files in your texture pack.

How do I find out the coordinates to use? I don't want to have to count all those pixels!
Most likely your image editor has something so you don't need to count. In photoshop, open up the "info" panel, and when you move your cursor on the canvas it will tell you the x and y of where it's at. Paint.net has the same thing built right into the GUI at the bottom of the screen (bottom right).


Tell me about grayscale. I'll bet that's complex!
Well, not really. For this next one, I'll be making a few of the wooden planks' texture based on a grayscale image. I'll be using a grayscale version of the original wooden planks' location, and adding color to it to form other wooden planks' texture

tile.wood.oak.texture= tint(#9A5726, tile(4,0));
tile.wood.birch.texture= tint(#90623B, tile(4,0));
tile.wood.jungle.texture= tint(#98F6225, tile(4,0));

I've chosen not to use just the grayscale method for pine planks because it is much darker than the rest of the planks. The format of tint could be (color, grayscale area)

Well what about brightness? Different colors have different values!
Yeah, I just thought about that when writing this suggestion. So, I want to change the pine planks, too! So:

tile.wood.pine.texture= tint(#58280E, shade(-75, 50, tile(4,0)));

The format of shade would be (brightness, contrast, area). This would not be limited to grayscale use (but that would be its most useful use).

Wait, can I do things in multiple places on one texture?
And what about assigning multiple textures to one model?
Why yes! And Most of the time, assigning multiple textures will involve tile extensions based on an item after placed in relation to the player. For instance, the door has always bothered me , the fact that it derives the side textures from the sides of the front, and the fact that it has hinges in 4 places. So here's how I would fix it using my idea:

tile.doorWood.front.texture= rect(16,80, 31,111) pixels(#B27538, rect(16,84, 16,86)) color(#B27538, rect(16,95, 16,97)) color(#B27538, rect(16,106, 16,108));
tile.doorWood.right.texture= rect(16,80, 18,111) pixels(#B27538, rect(16,84, 16,86)) color(#B27538, rect(16,95, 16,97)) color(#B27538, rect(16,106, 16,108));

In this code, pixelswould cover up the hinges from the derivative texture, but only on the front and left side (the side not connected to the wall if there is one) leaving the hinges on the back face, and the side that is actually the door's pivot. Note that how I used the methods, they are separated by a space. A semicolon denotes the end of methods for whatever comes after the equals sign.

More advanced models would require specific name extensions (In fact many I've been using I made up, like anything after tile.____.). such things might be things like

tile.stoneSlab.slabtype.bottomSlab.____.texture= ;
tile.stoneSlab.slabtype.topSlab.____.texture= ;
tile.fence.post.arms.____.texture= ;
tile.piston.head.pusher.____.texture= ;

What would I do with all of this code again?

It would go in a text file.

Is that it?
Yea, pretty much. I'd also like to note that I tried to make this as simple yet informational as possible, to show how you might use this feature, as well as things Mojang would need to make work. Mojang could make more methods to make less typing required (like square and line) but for time, I didn't explain any more. Also, Mojang would probably use names as they appear in the code.

The idea is to have Mojang add a piece of code into Minecraft that would interpret a single .TXT file
on the root directory of a texture pack that would control how textures from terrain.png are read.

The text created by the texture author would mock that of what the game already uses.They would put

tile.____.texture= ;

Tile would be in nearly all of the initiating lines, the first line of underscores would be the block name, and could have extensions after it (".top" ".left" ect.) and this would always end with ".texture" (for changing textures) and then anything after the equals sign and before the semicolon is the code that designates where the texture is from, and how it should be used.

Artists will use things called methods. Methods designate from where or how a texture is used. They also allow the game to do things to certain textures without modifying or needing a new texture.

Methods need to be applied in a certain order. If they are applied first, they are on the bottom, it is under the methods after it. Many things could be done with multiple selections, but layering is a much easier way to achieve the effect.

tile-Selects a resolution dependant square, snapped to a grid on how the game would normally look, based on coordinates that won't change with resolution

rect-Selects a rectangle based on the two coordinates given.

lineX- Selects a straight line based on 1 Y value and a starting and stopping X value.

lineY- Selects a straight line based on 1 X value and a starting and stopping Y value.

tint-Recolors a selection based on the given color.

hueshift- Changes color of selection based on its current color, and shift value.

shade-Changes brightness/contrast of selection.

pixels(name subject to change)-Adds pixels in the given selection (only for this use of the texture).

opacity- Gives the selection a specific opacity (good for layering).

function()- does a check with the game for a variable.

function(grasscolor)- Does a check of what biome the block is in, and returns grass' color (allows any
block to be biome-colored).

function(leafcolor)- Does a check of what biome the block is in, and returns leaves' color (allows any block to be biome-colored).

function(effect)- Does a check of what color the particle would normally be recolored to (potion effect particles, enchanted hit particles, ect.).

Nether portal texture:

tile.obsidian.portal.texture=;

Allows Obsidian to have a separate texture when it turns into a nether portal.

Redstone:

tile.oreRedstone.off.texture=;
tile.oreRedstone.on.texture=;

Allows Redstone ore to have a different texture when it activates. Still changes the lighting. Also, the on/off extension could (and would probably need to) be used on other redstone objects (well, only really needed for the redstone torch)

Dimension-specific textures:

tile.obsidian.normalworld.texture=;
tile.obsidian.nether.texture=;
tile.obsidian.end.texture=;
entity.enderman.normalworld.texture=;
entity.enderman.end.texture=;

This would allow texture packs to have different textures depending on the dimension. For instance, blocks in the nether could be decaying and have a light source from the bottom, not the top, as lava is usually below you, and there is no sun. That same block would be normal in the normal world, and it could be crystallized with no light source in the end, as there is no global light source at all. Also, this could apply to mobs as well, for instance you could texture an enderman normally in the end, but to look like a scout/spy/theif/warrior/soldier when in the normal world.

Particles:

particle.smoke.frame.1.texture=;
particle.smoke.frame.2.texture=;
particle.smoke.frame.3.texture=;
particle.smoke.redstone.texture=;
particle.smoke.bedrock.texture=;
particle.smoke.water.texture=;
particle.smoke.mycelium.texture=;
particle.smoke.portal.frame.1.texture=;
particle.smoke.portal.frame.2.texture=;
particle.smoke.portal.frame.3.texture=;
particle.smoke.ender.frame.1.texture;
particle.smoke.ender.frame.2.texture;
particle.smoke.ender.frame.3.texture;
particle.potion.frame.1.texture=;
particle.potion.frame.2.texture=;
particle.potion.frame.3.texture=;
particle.enchant.texture=;
particle.love.texture=;
particle.note.texture=;

These would allow the separation of many derivative particle textures, allowing texture artists to give them individual textures. Using the frame.# extension, you can change the number of frames, and where they load from. Remember, that if you don't define new textures (like portal particles) they will use and recolor the smoke texture as usual. If you make them have separate textures, you get to choose the color, or use function(effect) to automatically recolor the chosen selection to the color that the game would choose. The frame.# extension would work differently for portal and ender particles, chooesing different frames to send out (like it does with the smoke particle animation now)
(that isn't all of the particles, but you get my point....)

Blocks:

tile.crops.model= model(x);
tile.tallgrass.grass.model= model(numbersign);

This would allow to give certain blocks (like those without collision) use of existing models (but better names ), like this:


I thought of this when carrots and potatoes were added, as I don't like the model it uses, and would rather have them grow as a single plant in the middle of the farmland.

Mobs:

entity.Villager.model= model(humanoid);

This would allow mobs to use other mob models. Obviously I chose a change that will be most popular if this feature were added. This would change the mob's model, but the collision box for mobs would not change, and the model would be scaled to the mob's size. For instance, if you changed skeletons to use the Enderman model, it would be shorter, and thus the model would need to be smaller to compensate. Also, some models might not work with others, like changing the enderdragon to a slime (but you could change it to a giant chicken ). Also, mobs would animate in their own movement style when possible (like a dragon-chicken would flap its wings), but specific animations would not be carried over, such as magma cube sproing or enderman freaking out.

Corresponding text file: Mediafire

[center][url="http://www.minecraftforum.net/topic/1149952-/"][IMG]http://i.imgur.com/7xymh.png[/IMG][/url][/center]