I'd suggest take a break from doing textures and play the game. We've seen in previous snapshots that Mojang change their mind between weeks, so trying to constantly keep up with them is crazy until a stable version is available, and that won't be 1.5. After a ton of bug fixes, 1.6 or higher. Then at that point come back to texturing.
Did not realise that they have just stitched the individual textures back together into one big file. I expected loaded textures on demand, instead of loading them ALL at game start. Waste of memory resources especially if you load in mods.
It kinda feels like a hack fix just to get a snapshot out and to show that they can indeed split up the texture files, even though they are just rebuilding them again in the code. Honestly, I wish they would just slow down with all these snapshots, when I think how long we are all on 1.2.5.
Hai Misa. 'Tis a shame 13w02a doesn't automagically convert TPs to the new format like DB said it would
I do my own remix pack (very edited version of john smith) and now I've gotta convert it manually, along with update it with the new stuff (I really can't make a good quartz/marble texture)
good luck
Automatic conversion isn't so much my worries as is the loss of important features. Dinnerbone released an unstitcher to help with the conversion process. He just seems to fail to understand that texture packs these days are more than just terrain.png with custom animation support.
I don't understand why Mojang didn't just use MCpatcher's methods or OptiFine's methods. There were already working solutions. Did they even talk to Kahr or sp614x?
I don't either. I did suggest to Dinnerbone that he consult one of them at the very least but I guess my request fell on deaf ears. I know Kahr wasn't contacted. And given what we got with this snapshot, I doubt sp614x was either.
Not sure if you already explored this option and if you did if it worked but dinnerbone made a converter tool for the textures. it maaay not work because of 64x but i know for 32 and 16 it works perfect for converting the terrain and items into snapshot compatible textures. again i said i don't know if it works for 64x, and if someone already mentioned this already cool for them just giving ideas to help since it REEEEAAALLY helped me. heres the link for his twitter post that released it https://twitter.com/...796115647561728
and heres a link to a post by someone else on the forum about his post giving the same links here
As stated in the reply above, conversion was never the issue. It's the loss of important features (CTM, Custom Colors, Randomobs, etc.) that many complete, high resolution texture packs have relied upon for ages and the poor technical implementation of high resolution texture support (Buggy held item edges, animation properties using the formatting-corruptable *.txt extension, the unnecessary restitching and unstitching on the code's side, etc).
the new format is interesting. Having separate files makes it easier to fill in a missing texture with the default instead of having it blank (though that does remove the possibility of having it say "get the newest pack!"). In general though I like that new behavior better. It stitches it up again on loading I assume it has fewer textures hanging around, and also so they don't have to change too much of the block code (that gets fed an ID and translates that to the proper section of terrain.png to use).
It will obviously be a big shakeup for Kahr (and for me and my minimap) but it shouldn't be too bad. I mean it's not all that different conceptually from what's going on now with loading each animated texture from a separate file. Aside from forcing texture pack artists to work in even more separate PNGs, once they are all loaded and stitched together things should be pretty close to the same internally. I'll know more when MCP updates; I'm perfectly happy to let someone else deobfuscate for me (not so Kahr, another thing that makes him amazing)
The filled in missing texture feature for me is really less of a motivation to update than anything convenient. That said I don't have a problem with the textures being separate (they should have been from the start). However, considering that the process that they went with for implementation is more redundant than the old system, I have to wonder why they did it. I really hope this is just the start of what they plan to do and this release was just to give some texture pack artists (myself excluded) a heads-up. The current implementation is just completely unnecessary.
Hey, did you know Dinnerbone doesnt/didnt even know what CTM is?
Hell, why dont they just buy MCPatcher and carry on with something that actually works?
It's not too surprising considering that the new API clearly discourages use of client mods (Like MCPatcher or Optifine) and the modders associated with these are a not-so-vocal minority. I complain when they do something to set me back on this thread, but it rarely goes beyond that because I simply don't have the time or energy to be an activist for my own cause.
From a business standpoint the standard end user matters more than the modders. They're more concerned with making things easy and accessible to the average player than to minority of players who have been shaping the formatting of the modding community for years. Which makes perfect sense when you think about it--still, it kinda sucks to be a part of that minority.
Yeah, I like him, but he cleary doesnt know how to chanage the textures. For the blocks, I think adding a second terrain.png would be better, but for items, I think its better because it
s easier to allign the items.
If they don't change the way the stitching is currently handled, they'll HAVE to add a second terrain.png. It'll just be an invisible part of the game's coding. As far as item sprite alignment goes, a standard grid tool (found in most graphic editors) with 'snap to grid' active has always worked just fine.
The new texturmanagement open some interesting options.
- Animated tall grass, flowers, farn etc. (like a brise of wind!?)
- Alternate textures are easyer to change.
- potatos und karrots are no more have the same first 3 growningtextures!
- Quarzblocks should be bright marmor... so endstone can become another texture.
- Generaly all animated blocks/items don´t need any hd-patcher.
To your texturpack Misa:
- Why Netherfence have no darkred texture, like the netherbricks?
- If its possible, to create optional "Millenaire-Mod"-Textures?
- And last.... your the best texturepack creator ever.
-Animated plants have already been possible for nearly two years. It just doesn't work out well on the texture-side of things with my style of texture pack. I spent an entire day trying to get this to work and it failed miserably and ended up making playtesters feel sick. This is something that is best handled by shaders that actually smoothly bend the geometry the texture is applied to (as it is handled in nearly all modern 3D games).
-Alternate textures are only really easier to change for the casual editor. The new format has no real positives or negative effects to anyone remotely comfortable with graphics editing.
-The plant growth textures will be more work for me as I'll have to redo both from scratch to maintain consistency, but yeah, I wanted this from the start so I can't really complain.
-My endstone I feel is too alien in it's design to use it as the basis for the marble blocks and I'm satisfied with how it looks in the End. You can be sure that I'll come up with something that looks good and is very useful in builds though.
-Their animation support also doesn't allow for the advanced animations like mob blinking or the animated full screen effects like underwater caustics that my pack makes heavy use of. And don't get me started about animated CTM stuff.
-Because dark red fences are largely worthless as a building block outside of the Nethe--yet black fences could be used for wrought iron fences that iron bars fail to emulate. Also the Nether fortresses were lacking in variety and contrast. The color choice isn't a dramatic increase in contrast, but with the lighting I have in my pack from custom colors the color scheme fits with the whole volcanic rock theme I went with for netherrack.
-Once the API goes live that pretty much all mods will die and have to be rebuilt. Right now mod support is probably the last thing on any texture pack artist's mind.
-Thanks.
I would just wait out the snapshots and see how things go with them. After a few more releases, if the situation hasn't improved any, then you (and Kahr) can decide which direction to go in. Until that point just relax a bit.
I'd rather just wait and see what we end up with before complaining about texture artists being screwed over.
Especially if Kahr finds a way to work an MC Patcher compatibility feature into it.
Remember the Zombie villager? Before it got it's own texture and was part of the zombie texture.
Then it got it's own texture and even though zombies ended up with a larger texture with no additional benefits, MC Patcher gained a compatibility patch. Sure the villager zombie handling could have been better, but it nearly ended up worse.
Things can be better, but they could be worse.
Mojang changes things during the time between announcement and release sometimes so who knows what will happen?
I'm not saying there's no possibility of it being really bad, but it's a little early to fully confirm anything.
I think you might be equating complaining to the espousement of a defeatist attitude. They're not the same thing. If no one ever complained about anything anyone else did, there would be little motivation to correct potential mistakes. If absolutely no one had complained about the zombie villager texture issue, do you think anything would've been likely to change on its own?
I'm not too occupied with or worried about how the situation will turn out. However that's not going to prevent me from voicing my opinions on the subject--even if they're perceived as negative. My complaints are not representative of a pessimistic of optimistic outlook on the overall situation. They're my way of putting any immediate concerns on the table while venting a little steam from any frustration of the situation.
Cool update. Thanks for it.
I have only two suggestions.
The first one is to leave an unpowered comparator without animation. I didn' even know that it uses a different texture depending on its state but as the quartz-part of your texture is different when on or off I assume it uses two textures. In that case I would keep the design of the repeater and leave it without the energy trail or however you want to call the red animation.
The second one is just a minor thing. I really like your new repeater texture with the red dots and the different "cables" (not sure how to call them else). But you made only three of these red dots and I think it would be really cool to have one in every position the second torch can be.
Well that's it. Otherwise let's see what the next days will bring texture pack wise.
Have you played with comparators much yet? The "unpowered" state is not an unpowered state--It's an open/closed gate system. Comparators can receive powered input from 2 (or 3 with 1 as redundant) sources. If you look closely, you'll see that the circuit flow animations are different. The closed gate is intended to simulate capacitance that is disippated by the input values of the comparator's terminals. While the open gate releases its calculated charge to terminal C. Both states are animated because both states can be receiving input. If I could do a third texture for those with the closed gate state with no terminal contact, I would, but considering no builds would have any use for this, the current setup is more practical than having the closed gate state without animation.
Regarding the repeaters, the reason there are three output terminals to the resistor and output conduit instead four is because there was no way physically possible to fit three resistor symbols on there. I may black out the pulses from the black-ish indents where the redstone torches sit if too many people are confused by this and just pass it off as something more analog like a potentiometer. On that note I may just redesign it to use the rheostat symbol if I can figure out a way to fit and animate it in that space. The reason I didn't do that from the start was that the two terminal input was difficult to figure out how to animate with the setup of the graphic.
Yes, I'm a nerd who played with breadboards a lot as a kid. If my pack was only used by myself, the images used for these components would probably look like old PCB's.
I'd suggest take a break from doing textures and play the game. We've seen in previous snapshots that Mojang change their mind between weeks, so trying to constantly keep up with them is crazy until a stable version is available, and that won't be 1.5. After a ton of bug fixes, 1.6 or higher. Then at that point come back to texturing.
Did not realise that they have just stitched the individual textures back together into one big file. I expected loaded textures on demand, instead of loading them ALL at game start. Waste of memory resources especially if you load in mods.
It kinda feels like a hack fix just to get a snapshot out and to show that they can indeed split up the texture files, even though they are just rebuilding them again in the code. Honestly, I wish they would just slow down with all these snapshots, when I think how long we are all on 1.2.5.
Publicly I've long since stopped trying to keep up to date with every snapshot. Privately I like to be on top of things and the snapshots are usually a good way to go about that--just not so much in this case. Before snapshots I got extremely overwhelmed with my workload while trying to meet my self-imposed update deadlines.
What I'd really be a lot happier with is if the forum moderators would stop advertising every single snapshot on the front page of the forums, and if the community in general wasn't made so readily aware of them. As a tool, snapshots are only really valuable for mod-makers to adapt their work with and actual playtesters who provide feedback through official channels. When they're seen as mini-updates for everyone to go check out immediately, they initial concept of a snapshot is defeated.
I don't either. I did suggest to Dinnerbone that he consult one of them at the very least but I guess my request fell on deaf ears. I know Kahr wasn't contacted. And given what we got with this snapshot, I doubt sp614x was either.
I was referring to the connected textures of Misa's pack. The latest version of Misa's pack relies a lot on the Connected Textures mod, and SEUS lacks bump mapping and parallax mapping support for connected textures, so if you want to use SEUS you'll have to disable these features. Also, as I've said, Misa has issues with Optifine, which SEUS requires to run. Optifine may not support all the pack's features. 'Til SEUS adds support for the CTM, and Optifine issues these problems with Misa's pack, among others, Misa won't be doing official support for SEUS and would recommend against using Optifine.
Well i did read your reply which was after I gave my opinion of option, and I gave the option of using the unstitcher as a way to just try and make things a little easier for conversion, you know save as much time as you can where you can for the poor update being served to us, I was just giving ideas to make your life maybe a little easier while we, i mean the community, tries to figure something to do since those support mods are gonna be pretty broken for a while.
I was referring to the connected textures of Misa's pack. The latest version of Misa's pack relies a lot on the Connected Textures mod, and SEUS lacks bump mapping and parallax mapping support for connected textures, so if you want to use SEUS you'll have to disable these features. Also, as I've said, Misa has issues with Optifine, which SEUS requires to run. Optifine may not support all the pack's features. 'Til SEUS adds support for the CTM, and Optifine issues these problems with Misa's pack, among others, Misa won't be doing official support for SEUS and would recommend against using Optifine.
If you really are working for a bump/parallax mapping support, that's awesome. I don't use bump mapping and parallax mapping since my laptop lags like hell with them, anyway. I just use SEUS for the realistic lighting and waving plants/leaves, among other things.
Hey misa, if you don't know, Dinnerbone released an unstitcher tool, to convert the texture packs for the new format, i tried using on your texture pack, and worked fine, just the things like animated textures and the nether portal arent working, also water is normal too, but its a good way to start converting your texture pack! The link is http://assets.minecr.../unstitcher.jar
Well, the good part is, now minecraft support animated textures which is a good thing, that was on McPatcher, and now is vanilla!
this is an amazing texture pack misa, great work!! just one quick question: this texture pack does work with Mcpatcher, but does it work with Optifine also?
Ok, I'm using your pack but I got this twich when I move my mouse. I use a 128 by 128 texturpack but it doesn't lag, so I know its not my computer. The twiching is hard to play with and I need Help fixing it. I Look on youtube to see if someone else it having it but no one is. Help me Please!?!?!?!
It's a Texture Pack converter. It is able to take ANY old texture pack and pull it apart, or "unstitch," all the individual blocks and items from the terrain.png and items.png into their new, separate, allocated folders.
In other words, one way to look at is this:
You could keep making your Texture Pack how you were, and just run the unstitcher on it; at least until they add even more items or blocks.
Hope this helps!
Rollback Post to RevisionRollBack
So many ideas.
To post a comment, please login or register a new account.
Did not realise that they have just stitched the individual textures back together into one big file. I expected loaded textures on demand, instead of loading them ALL at game start. Waste of memory resources especially if you load in mods.
It kinda feels like a hack fix just to get a snapshot out and to show that they can indeed split up the texture files, even though they are just rebuilding them again in the code. Honestly, I wish they would just slow down with all these snapshots, when I think how long we are all on 1.2.5.
Automatic conversion isn't so much my worries as is the loss of important features. Dinnerbone released an unstitcher to help with the conversion process. He just seems to fail to understand that texture packs these days are more than just terrain.png with custom animation support.
I don't either. I did suggest to Dinnerbone that he consult one of them at the very least but I guess my request fell on deaf ears. I know Kahr wasn't contacted. And given what we got with this snapshot, I doubt sp614x was either.
As stated in the reply above, conversion was never the issue. It's the loss of important features (CTM, Custom Colors, Randomobs, etc.) that many complete, high resolution texture packs have relied upon for ages and the poor technical implementation of high resolution texture support (Buggy held item edges, animation properties using the formatting-corruptable *.txt extension, the unnecessary restitching and unstitching on the code's side, etc).
The filled in missing texture feature for me is really less of a motivation to update than anything convenient. That said I don't have a problem with the textures being separate (they should have been from the start). However, considering that the process that they went with for implementation is more redundant than the old system, I have to wonder why they did it. I really hope this is just the start of what they plan to do and this release was just to give some texture pack artists (myself excluded) a heads-up. The current implementation is just completely unnecessary.
It's not too surprising considering that the new API clearly discourages use of client mods (Like MCPatcher or Optifine) and the modders associated with these are a not-so-vocal minority. I complain when they do something to set me back on this thread, but it rarely goes beyond that because I simply don't have the time or energy to be an activist for my own cause.
From a business standpoint the standard end user matters more than the modders. They're more concerned with making things easy and accessible to the average player than to minority of players who have been shaping the formatting of the modding community for years. Which makes perfect sense when you think about it--still, it kinda sucks to be a part of that minority.
If they don't change the way the stitching is currently handled, they'll HAVE to add a second terrain.png. It'll just be an invisible part of the game's coding. As far as item sprite alignment goes, a standard grid tool (found in most graphic editors) with 'snap to grid' active has always worked just fine.
-Animated plants have already been possible for nearly two years. It just doesn't work out well on the texture-side of things with my style of texture pack. I spent an entire day trying to get this to work and it failed miserably and ended up making playtesters feel sick. This is something that is best handled by shaders that actually smoothly bend the geometry the texture is applied to (as it is handled in nearly all modern 3D games).
-Alternate textures are only really easier to change for the casual editor. The new format has no real positives or negative effects to anyone remotely comfortable with graphics editing.
-The plant growth textures will be more work for me as I'll have to redo both from scratch to maintain consistency, but yeah, I wanted this from the start so I can't really complain.
-My endstone I feel is too alien in it's design to use it as the basis for the marble blocks and I'm satisfied with how it looks in the End. You can be sure that I'll come up with something that looks good and is very useful in builds though.
-Their animation support also doesn't allow for the advanced animations like mob blinking or the animated full screen effects like underwater caustics that my pack makes heavy use of. And don't get me started about animated CTM stuff.
-Because dark red fences are largely worthless as a building block outside of the Nethe--yet black fences could be used for wrought iron fences that iron bars fail to emulate. Also the Nether fortresses were lacking in variety and contrast. The color choice isn't a dramatic increase in contrast, but with the lighting I have in my pack from custom colors the color scheme fits with the whole volcanic rock theme I went with for netherrack.
-Once the API goes live that pretty much all mods will die and have to be rebuilt. Right now mod support is probably the last thing on any texture pack artist's mind.
-Thanks.
Did you read anything I posted after that?
I think you might be equating complaining to the espousement of a defeatist attitude. They're not the same thing. If no one ever complained about anything anyone else did, there would be little motivation to correct potential mistakes. If absolutely no one had complained about the zombie villager texture issue, do you think anything would've been likely to change on its own?
I'm not too occupied with or worried about how the situation will turn out. However that's not going to prevent me from voicing my opinions on the subject--even if they're perceived as negative. My complaints are not representative of a pessimistic of optimistic outlook on the overall situation. They're my way of putting any immediate concerns on the table while venting a little steam from any frustration of the situation.
Have you played with comparators much yet? The "unpowered" state is not an unpowered state--It's an open/closed gate system. Comparators can receive powered input from 2 (or 3 with 1 as redundant) sources. If you look closely, you'll see that the circuit flow animations are different. The closed gate is intended to simulate capacitance that is disippated by the input values of the comparator's terminals. While the open gate releases its calculated charge to terminal C. Both states are animated because both states can be receiving input. If I could do a third texture for those with the closed gate state with no terminal contact, I would, but considering no builds would have any use for this, the current setup is more practical than having the closed gate state without animation.
Regarding the repeaters, the reason there are three output terminals to the resistor and output conduit instead four is because there was no way physically possible to fit three resistor symbols on there. I may black out the pulses from the black-ish indents where the redstone torches sit if too many people are confused by this and just pass it off as something more analog like a potentiometer. On that note I may just redesign it to use the rheostat symbol if I can figure out a way to fit and animate it in that space. The reason I didn't do that from the start was that the two terminal input was difficult to figure out how to animate with the setup of the graphic.
Yes, I'm a nerd who played with breadboards a lot as a kid. If my pack was only used by myself, the images used for these components would probably look like old PCB's.
Publicly I've long since stopped trying to keep up to date with every snapshot. Privately I like to be on top of things and the snapshots are usually a good way to go about that--just not so much in this case. Before snapshots I got extremely overwhelmed with my workload while trying to meet my self-imposed update deadlines.
What I'd really be a lot happier with is if the forum moderators would stop advertising every single snapshot on the front page of the forums, and if the community in general wasn't made so readily aware of them. As a tool, snapshots are only really valuable for mod-makers to adapt their work with and actual playtesters who provide feedback through official channels. When they're seen as mini-updates for everyone to go check out immediately, they initial concept of a snapshot is defeated.
sp614x WAS contacted, sadly, he refused to help
I was referring to the connected textures of Misa's pack. The latest version of Misa's pack relies a lot on the Connected Textures mod, and SEUS lacks bump mapping and parallax mapping support for connected textures, so if you want to use SEUS you'll have to disable these features. Also, as I've said, Misa has issues with Optifine, which SEUS requires to run. Optifine may not support all the pack's features. 'Til SEUS adds support for the CTM, and Optifine issues these problems with Misa's pack, among others, Misa won't be doing official support for SEUS and would recommend against using Optifine.
I hope this clears things up for you.
-
View User Profile
-
View Posts
-
Send Message
Retired StaffWell i did read your reply which was after I gave my opinion of option, and I gave the option of using the unstitcher as a way to just try and make things a little easier for conversion, you know save as much time as you can where you can for the poor update being served to us, I was just giving ideas to make your life maybe a little easier while we, i mean the community, tries to figure something to do since those support mods are gonna be pretty broken for a while.
CTM is now supported
http://www.minecraft...ed-by-karyonix/
I've personally been working on some ctm shader support for Misa's pack, but I'm slow and lazy and haven't gotten much done.
and if you notice there's even shader support on the hand held items now too.
Oh wow. That was quick.
If you really are working for a bump/parallax mapping support, that's awesome.
Weights used in the screenshot: 25 6 9 8 6 6 6 4 13 7 6 4. If you don't know what to do with them - read first post in MCPatcher thread.
http://www.planetminecraft.com/member/spejs/
----------
That's what I wanted to say
Well, the good part is, now minecraft support animated textures which is a good thing, that was on McPatcher, and now is vanilla!
Details?
cool. thanks for the tip!
P.S nice pack
At some point around Snapshot 13w02b, Dinnerbone himself released this:
http://assets.minecraft.net/unstitcher/unstitcher.jar
It's a Texture Pack converter. It is able to take ANY old texture pack and pull it apart, or "unstitch," all the individual blocks and items from the terrain.png and items.png into their new, separate, allocated folders.
In other words, one way to look at is this:
You could keep making your Texture Pack how you were, and just run the unstitcher on it; at least until they add even more items or blocks.
Hope this helps!