more progress on the collab NOTE the pyramid shaped blocks things are place holders
- Registered Member
Member for 9 years, 8 months, and 7 days
Last active Sat, Jan, 24 2015 16:50:07
- 1 Follower
- 687 Total Posts
- 62 Thanks
Aug 10, 2012i just thought this looked cool also a little sneak peek of an upcoming texture pack i am doing with north and peytonPosted in: Resource Pack Discussion
this was taken at night (in game not real life ) it is actually brighter the colours
Aug 6, 2012Posted in: Resource Pack Discussion
i wouldn't count this is the best but i currently working on a texture pack do these look any good ?Quote from Lilyo
So I haven't been on these forums in a few months. Can someone give me some links to the currently best texture packs?
Aug 6, 2012ok i have done my entry i was inspired by northern with his little robotPosted in: Resource Pack Discussion
here he is a little scrap bot and with only 7 colours
i love this little guy and i am thinking on making him my avatar any thoughts ???
Aug 5, 2012Posted in: Resource Pack Discussion
i wuv him he is so little and cute :DDDQuote from NorthenerSouth
Presenting the Squarebot.
The original-sized image along with the pallete, with a black background for clarity (it's not part of the pallete, though - just making that clear):
This isn't a serious entry, but put it up in the poll if you want.
Jul 29, 2012Posted in: Resource Pack Discussion
i can tell you have used a tutorial cus i used that tutorial thats how i got ma styleQuote from turek279
What do you guys think of these?
anyway here is some progress the thread might be posted next week cus i its monday tomorrow and i gotta go to school
EDIT those arnt all of the wools i have done them all just to let you now
- To post a comment, please login.
Sep 23, 2012Posted in: Resource Pack Discussion
Heheh, that is me.
Quote from JimmyWalker97
Far too many pinks and blues to be honest, think about what logical colours are needed in a texture pack, maybe add more browns and reds?
Edit: Oops, double post :s
I see what you mean, but I have made a fully complete texture pack with the colors in it and it pretty much has enough colors in reds and browns. (Actually, one time I was stumped because I needed one more shade of red)
Speaking of complete texture pack, I finally uploaded it. Its in my signature, and I need people to tell me what they think.
Heres a pic to convince you to going to my thread
Apr 8, 2012insomniac_lemon posted a message on Dynamic Texture Assigning (updated Sept 10, 2012, including changing models!)FAQ explanation:Posted in: Suggestions
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
- Half Slabs
- Pressure plates
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.
Technical non-FAQ explanation:
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 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.
But that is way too much! I don't want to have to modify all of this code just to make a texture pack!
The great thing about this idea, is that it is all optional. It is up to you, as an artist, how much of this you are comfortable using. Use all of it, use some of it, or just do the same thing you've been doing (none of it). It is up to you. Just like a texture pack itself, just because you change one texture location, does not mean you have to change them all. If you don't specify a texture map/location whatchamacallit Minecraft assumes to use default, just like if you don't modify items.png your items are all default.
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.).
There are more things I have thought of that could be done with this idea, that I'm not asking for, but would be a nice addition, and if the system were implemented correctly, would be easily enough added by modders. More uses:
Nether portal texture:
Allows Obsidian to have a separate texture when it turns into a nether portal.
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)
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.
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....)
Once again, features that would be possible, or come later. Beyond textures, models:
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.
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.
Why can't this just be made into a mod like MCpatcher or something?
Mod users get all of the cool stuff. HD. Animated textures. Biome water. ect. I don't like the burden of imbalanced-gameplay and waiting for mods to become compatible with vanilla. (I don't use mods) But it's time vanilla Minecraft gets some texturing love! Besides, people are always saying how Mojang never makes any cool stuff anymore, that <insert Mojang employee here> has only added things you hate.
Can I use your ideas to make this a mod?
No. I want this implemented into vanilla, but if it isn't implemented by the time the mod API comes out, I will try and make it myself. I'm a programmer, but not with Java, and I'd like the reason and project to start modding and learning Java.
What can I do to support?
Post, vote, and twitter Jeb_, or make a thread on Reddit. If you do, make sure to include the forum link.
Or, post on the epicness of this suggestion, tell me what doesn't make sense, if I should rewrite something, or request I write a little more on something. Give your friends the link. Anything.
Also: I made a getsatisfaction post. Not sure if that matters. Meh.
EDIT: I have spent a little time making a mock-up (out of my texture pack VTC, but it is heavily outdated now) of what one of these text files would look like, and the terrain.png to go with it, as an example of what you might expect to be able to do. (I will add more to this later with things like the button, fence, ect. later)
EDIT2: Both the text file and the textures are out of date, they aren't that ugly anymore :3
Corresponding text file: Mediafire
Sep 10, 2012Ahh so it is!! Teal is my favorite color, it's a beautiful color, especially dark teal..Posted in: Resource Pack Discussion
Anyways with that I bring you -
Zombie Yetis -
With pretty eyes thanks to input from Imnumberfour.
Sep 4, 2012Well alright, closing down my exams and starting work again on Luciscraft.Posted in: Resource Pack Discussion
Slightly off-topic, but this is what I spent most of my time modeling/working on, and I gotta go present it for my exam in a couple of hours. Wish me luck.
- To post a comment, please login.