it is possible to use cit to change the armor the playermodels are wearing (cit_single.properties), but i dont get it to work. 3.0.4_01 version of mcpatcher. So im asking myself if someone already tested it and can help me out^^
Custom Item Textures (CIT) is only in the 4.0 versions of MCPatcher, not the 3.0.4_01 version
i use cit since 1 month (min)....works great. but i dont know if the armor-cit are implementet yet or i am doing something wrong
Yea, the armor thing only made it into a recent version. I'm pretty sure it's the 4.0.0 Beta version. It's not in the first version that had it, unfortunately.
Sorry, but I don't think this would be possible. I don't think there is any way you can control how a group uses CTM. You could make randomized frames, however, it would apply per-block, meaning that within the 2x2x2 cubes, some of them would have wood frame, and some of the would not.
That's right. You can have Random on top of CTM (CTM where each tile is further randomized), but not the other way around. Random doesn't take into account what neighboring blocks are doing, and I don't see a good way to change that without dragging down performance.
Yea, the armor thing only made it into a recent version. I'm pretty sure it's the 4.0.0 Beta version. It's not in the first version that had it, unfortunately.
Yes, armor wasn't implemented until 4.0.0. However, the properties file format will change slightly in the upcoming release. The current way doesn't really handle multiple armor textures well.
Mojang will release 1.6 with no support for custom fonts in resource packs. Obviously, it's up to you again, Kahr ...
Any plans for a workaround?
The sad thing is the code to parse the mcmeta file for font metrics is already there -- just not being used anywhere. With each snapshot I kept hoping Mojang would finish it so I could rip out my own HD Font support once and for all. Since I'm writing my own converter anyway, it would have been a perfect time to move font properties files to mcmeta.
So MCPatcher's HD font support stays for now, although the directory structure will change. More on that later.
Everything's working fine in 1.6 and nothing broke in the update from 13w26a, which makes me happy. I have my own mini-MCP for 1.6 with a few dozen classes deobfuscated. Right now I'm mainly focused on finalizing the new directory structure for MCPatcher files within texture packs. The new layout is something I want to get right the first time because changing it later will be difficult.
To make the transition as painless as possible for artists, MCPatcher's built-in convert utility is getting an overhaul to match. So don't bother with Mojang's TextureEnder.jar. It's completely useless for any texture pack with advanced features.
There are still a few details I need to work out, but the new format has two goals:
Separate MCPatcher files from vanilla files.
Separate MCPatcher files for vanilla from MCPatcher files for mods.
Assuming Mojang ever gives players a UI to activate multiple resource packs at once, this will make it easier for artists to distribute a base pack and a separate MCPatcher addon pack, and possibly even further addons for specific mods.
What won't be in this release but I hope to have in the future is better integration with the new launcher. I'm not happy with the way you have to select the new version.jar manually in MCPatcher whenever there's an update. Now that the game supports multiple profiles, MCPatcher's own profile system should go away, but the replacement isn't fully thought out yet.
...To make the transition as painless as possible for artists, MCPatcher's built-in convert utility is getting an overhaul to match. So don't bother with Mojang's TextureEnder.jar. It's completely useless for any texture pack with advanced features...
...Assuming Mojang ever gives players a UI to activate multiple resource packs at once, this will make it easier for artists to distribute a base pack and a separate MCPatcher addon pack, and possibly even further addons for specific mods.
Hopefully this should make things simpler in the long run.
I much appreciate the work your doing, kahr. The base 1.6 version is looking pretty bland by comparison with my 1.5.2 MC Patcher set up...nothing against horses of course.
Assuming Mojang ever gives players a UI to activate multiple resource packs at once, this will make it easier for artists to distribute a base pack and a separate MCPatcher addon pack, and possibly even further addons for specific mods.
This is something that I had never considered, though it does make a lot of sense since that's the end goal of this entire reorganization. Way to think ahead Kahr!!!
Now I don't have to worry as much about whether or not I should make a "lite" version of Sanity.
Wow, I hadn't realized that you had gotten to item textures until I read their post!
This branches closer to one of the ideas I've had and would like to request.
Can you add support to CIT for giving items that have their own world model and textures to use that instead of icons?
In other words, all of these:
(also, possibly armor and arrows)
For one, it is annoying to texture some of these, ESPECIALLY at low resolutions (like 16x and lower). I already textured this thing in the world, and now I've got to make an icon to hope to represent this? HD texture packs often take stuff like this (especially boats and minecarts) and screenshot it and turn it into a texture, however this is a waste of resources and not a good option for 16x.
It's also inconsistent for these dozen things to use icons, and then another dozen slightly-complicated blocks just use their models (like stairs, slabs, trapdoors, fences, fence gate, anvil, snow, button, beacon, enchanting table, walls, pressure plates, carpets).
Well, how to implement this?
The easiest way would be in a list format like color.properties, with a list of all of the items that could use their world models and textures instead of icons, like this:
If you used CIT on an item that used a model (enchanting table, maybe you don't like the lack of floating book), it would automatically use an icon instead (sorry, not sure if it is like this already).
This is a simple little feature that Mojang could implement into mcmeta files. Sigh.... they never would, though, Even if they would, I have no way to tell them, even if I do. Which reminds me, do you think you could also fix mob head items not loading hat layers?
Floating eyes aren't cool
However, 3D mob heads are.
It would make the skeleton skull particularly cool
I'd just like say thank you for being here for the community. I really love innerSeams that you added (which, might I add, I asked sp614x months before you added it). I will admit that I've mostly been an Optifine fan (mostly because of being able to change options in-game), but your connection with the community and trying to keep up-to-date just seems better.
I've never really had a use for MCpatcher, but recently I've tried to support it. I didn't really like CTM because of how most artists use it on glass, large sections of glass look invisible. Then, you added betterglass. Everyone was hyped about partial transparency (I didn't hype in because it didn't add transparency properly), so I decided to use the renderpass setting to combine classic CTM with a repeat (and no backface culling) so it was better than classic CTM.
I was quite pleased with the results
Then, the old new pack format came out, and you updated how CTM was used (I don't know if Optifine ever did), so I decided to up support on it. I had already changed many of my textures to odd resolution for the new format, I think this was also around the time I discovered you added innerSeams. With my non-CTM glass texture changing, I decided to take a second look at how classic CTM worked.
EDIT: updated pic
With innerSeams, no backface culling, and the designs you can make (and that every block has pixels on it), I just love it. I have been thinking back on it now that the new new pack format is here, wishing I could be using my CTM glass. I guess I'm just itching to get it 1.6 ready.
Once again, thank you, and sorry for the long post (I wasn't intending to do this). Just something I feel like I had to say because I'm usually the guy who says "I don't use mods", but now I'm a little less of that guy
EDIT: I actually decided to try and get it working again with 12w23b.
It's really cool that the latest version of the patcher automatically patches the .JAR to a directory in the /versions/ dir even with a proper .json file!
However, when I got it working I noticed a problem.
It was loading more .properties files from my texture pack than previous versions. When the first new pack format came out, you changed it to stop loading them from /ctm/ in texture packs, instead loading them only from folders within them (default being /ctm/ctm/). I was using this fact to keep my old files in as legacy support for the old pack format.
Now (well, in 12w23b and 4.0 beta4) it will load any files in /ctm despite them:
a.)being in the same folder as full CTM sheets
b.)having duplicates in the folders in /ctm/
After they try to load, they don't because it trys to read from unstitched images, causing a magenta/black square to be used as the texture. This could either be fixed by restoring the older behavior of only loading from folders within /ctm/ but not files directly in it, or better yet, when encountering errors (and only telling about it), continue trying to load other .properties until they have all been tried.
Perhaps detecting files with the source= line as legacy, or possibly even a parsed comment (like #!/legacy/1.4) at the top of the document?
EDIT2: Also, my animations were completely messed up, and not loading the frame order at all, not sure why... happens with default lava, too. (and skins not loading after texture pack change, followed by crash on world exit and reload)
"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
Hey Kahr, just wanted to tell you I love how a good a job you've done all this time updating MCPatcher, and I can't wait to see what you figure out for 1.6!
That all sounds great and well-thought-out. Thanks for your hard work on this
The only thing I still don't understand is all the font stuff (so the code for it is actually in the game but not active?).
Especially Grum's "We might add the extended font feature later" and "Now I will wait an additional 2 weeks" comments in MC-17673 are absolutely incomprehensible to me after reading your post (they could have easily finished it and release 1.6 with a more complete resource pack system). Sometimes I think they just want to mock us ...
The "Now I will wait an additional 2 weeks. happy?" in the comment section, to be frank it sounds like Grum is just being childish and vindictive since someone mentioned that it's up to Kahr again to support HD font. Seems like Grum got a little butthurt and that is wholly unprofessional -- you don't wait to fix a bug because someone annoyed you. You wait because you don't have time or because there are bigger bugs to squash or whatever other technical/time reasons that force devs to not fix bugs.
I can understand getting frustrated at the mewling masses, but that's something you keep to yourself. You don't take it out on your fans, Grum, that's inappropriate. Minecraft is a popular game with a big community, as a dev. you have to expect people to be on your butt to fix bugs and you have to expect that more than half of the people are going to be frustrated and rude.
#Tact
Sorry about the little rant. In any case, please keep up the great work Kahr. I held off on using Dinnerbone's TexureEnder converter because I had heard it was a bit buggy so I'm looking forward to yours and updating my TP and messing around with 1.6.
Download MCPatcher 4.1.0-beta3 for Minecraft 1.6. jarexe
At long last, MCPatcher is updated for 1.6 including the new resource pack format! Included is a new utility for converting 1.5 texture packs into resource packs. This replaces Mojang's TextureEnder.jar while also moving all MCPatcher-related files to a new directory structure.
The new layout is roughly
assets/minecraft/textures - all vanilla files
assets/minecraft/mcpatcher - all MCPatcher files
~ = assets/minecraft/mcpatcher
~/anim - Custom animations (not items or blocks)
~/cit - Custom Item Textures rules
~/cit.properties - Global CIT properties
~/colormap - Custom biome palettes
~/color.properties - Global Custom Colors settings
~/ctm - Connected Textures rules
~/dial - Custom clock and compass
~/font - HD Font. Your font will be moved here if it is either higher res
than vanilla or it has a properties file / glyph_sizes.bin
~/lightmap - Custom lighting palettes for overworld, Nether, the End
~/line - Custom fishing line and lead textures
~/mob - Random Mobs alts and biome+height rules
~/renderpass.properties - Better Glass
~/sky - Skybox textures and properties for Better Skies
With the new resource pack system, Mojang changed the way textures are referenced internally. This required some changes to the way you specify textures within MCPatcher properties files. No one wants to keep typing assets/minecraft/etc. over and over, so I've added some easier ways to specify textures without the paths getting so long.
Normal path - relative to assets/minecraft:
textures/path/to/file.png -> assets/minecraft/textures/path/to/file.png
Relative to MCPatcher base directory:
~/path/file.png -> assets/minecraft/mcpatcher/path/file.png
Relative to path of properties file:
./path/file.png -> assets/minecraft/(dir of properties file)/path/file.png
Path in a different namespace:
namespace:path/file.png -> assets/namespace/path/file.png
The converter will automatically update the contents of your properties file too, so just look at those if this seems confusing.
What is a "namespace"? Basically they are a way for Mojang to separate mods from each other and from vanilla in the future. For now you don't need to worry about them. Everything is in the default "minecraft" namespace, but that may change depending on how ModLoader, et. al decide to handle things.
Most questions about the new format can be answered by converting your texture pack and looking at where files end up. But a couple things deserve mention.
Fonts. Since 1.6 does not properly support HD Fonts, MCPatcher's font support is still active, but it will only read from assets/minecraft/mcpatcher/font, not the vanilla directory assets/minecraft/textures/font. So, if you like, you can have a custom font that works in vanilla and a higher resolution font that requires MCPatcher to display properly. Essentially, this replaces default.png and default_hd.png in the old system. The converter tries to be intelligent about where it puts your old font files, but it may guess wrong, so just move the files manually if that happens.
Mob Textures. Separating MCPatcher and vanilla means that the base mob texture is in one directory and the alternates are in another. Basically, replace "textures/entity/" with "mcpatcher/mob/", keeping whatever directory structure Mojang used below that. Unfortunately Mojang wasn't very consistent here. Some mobs have a subfolder and some have just a texture.
The Meaning of Life, the Universe, and Everything.
Location:
California
Join Date:
9/16/2011
Posts:
43
Minecraft:
HunterBlackbrick
Member Details
Hey Kahr. Great work on MCP 1.6! It looks great! I have a few requests, some have been previously suggested I'm sure.
Custom biome coloring for the Sky biome and the Hell biome
The ability to add biome specific fire textures
Add the hat layer to mob heads (It would add more depth to them, and texture packs would look way better with this)
RandomMob sounds
The ability to add a hat layer to mobs that don't have it currently (Bats, Blaze, Slime, Creeper, Villager, Pig, etc...)
So those are my requests/suggestions. I'm sure these additions to MCPatcher would be quite useful to most if not all texture pack creators that use them.
Please deeply consider adding these features.
A reply would be great
-
View User Profile
-
View Posts
-
Send Message
Moderatorhttp://www.minecraftforum.net/topic/1496369-13w23b-152-151update-611-mcpatcher-hd-fix-400-beta4-304-01/page__st__8120#entry22833901
Thank you
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumMods I work on and maintain:
TabbyChat | Mine Little Pony
My Blog
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI'm not really expecting anything soon as it's a big overhaul you're going to have to do but any info as to your progress would be lovely!
That's right. You can have Random on top of CTM (CTM where each tile is further randomized), but not the other way around. Random doesn't take into account what neighboring blocks are doing, and I don't see a good way to change that without dragging down performance.
Yes, armor wasn't implemented until 4.0.0. However, the properties file format will change slightly in the upcoming release. The current way doesn't really handle multiple armor textures well.
The sad thing is the code to parse the mcmeta file for font metrics is already there -- just not being used anywhere. With each snapshot I kept hoping Mojang would finish it so I could rip out my own HD Font support once and for all. Since I'm writing my own converter anyway, it would have been a perfect time to move font properties files to mcmeta.
So MCPatcher's HD font support stays for now, although the directory structure will change. More on that later.
Everything's working fine in 1.6 and nothing broke in the update from 13w26a, which makes me happy. I have my own mini-MCP for 1.6 with a few dozen classes deobfuscated. Right now I'm mainly focused on finalizing the new directory structure for MCPatcher files within texture packs. The new layout is something I want to get right the first time because changing it later will be difficult.
To make the transition as painless as possible for artists, MCPatcher's built-in convert utility is getting an overhaul to match. So don't bother with Mojang's TextureEnder.jar. It's completely useless for any texture pack with advanced features.
There are still a few details I need to work out, but the new format has two goals:
- Separate MCPatcher files from vanilla files.
- Separate MCPatcher files for vanilla from MCPatcher files for mods.
Assuming Mojang ever gives players a UI to activate multiple resource packs at once, this will make it easier for artists to distribute a base pack and a separate MCPatcher addon pack, and possibly even further addons for specific mods.What won't be in this release but I hope to have in the future is better integration with the new launcher. I'm not happy with the way you have to select the new version.jar manually in MCPatcher whenever there's an update. Now that the game supports multiple profiles, MCPatcher's own profile system should go away, but the replacement isn't fully thought out yet.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumGreat news and just what I wanted to hear.
Hopefully this should make things simpler in the long run.
I much appreciate the work your doing, kahr. The base 1.6 version is looking pretty bland by comparison with my 1.5.2 MC Patcher set up...nothing against horses of course.
-
View User Profile
-
View Posts
-
Send Message
ModeratorNow I don't have to worry as much about whether or not I should make a "lite" version of Sanity.
-
View User Profile
-
View Posts
-
Send Message
Retired StaffWow, I hadn't realized that you had gotten to item textures until I read their post!
This branches closer to one of the ideas I've had and would like to request.
Can you add support to CIT for giving items that have their own world model and textures to use that instead of icons?
In other words, all of these:
(also, possibly armor and arrows)
For one, it is annoying to texture some of these, ESPECIALLY at low resolutions (like 16x and lower). I already textured this thing in the world, and now I've got to make an icon to hope to represent this? HD texture packs often take stuff like this (especially boats and minecarts) and screenshot it and turn it into a texture, however this is a waste of resources and not a good option for 16x.
It's also inconsistent for these dozen things to use icons, and then another dozen slightly-complicated blocks just use their models (like stairs, slabs, trapdoors, fences, fence gate, anvil, snow, button, beacon, enchanting table, walls, pressure plates, carpets).
Well, how to implement this?
The easiest way would be in a list format like color.properties, with a list of all of the items that could use their world models and textures instead of icons, like this:
If you used CIT on an item that used a model (enchanting table, maybe you don't like the lack of floating book), it would automatically use an icon instead (sorry, not sure if it is like this already).
This is a simple little feature that Mojang could implement into mcmeta files. Sigh.... they never would, though, Even if they would, I have no way to tell them, even if I do. Which reminds me, do you think you could also fix mob head items not loading hat layers?
Floating eyes aren't cool
However, 3D mob heads are.
It would make the skeleton skull particularly cool
I'd just like say thank you for being here for the community. I really love innerSeams that you added (which, might I add, I asked sp614x months before you added it). I will admit that I've mostly been an Optifine fan (mostly because of being able to change options in-game), but your connection with the community and trying to keep up-to-date just seems better.
I've never really had a use for MCpatcher, but recently I've tried to support it. I didn't really like CTM because of how most artists use it on glass, large sections of glass look invisible. Then, you added betterglass. Everyone was hyped about partial transparency (I didn't hype in because it didn't add transparency properly), so I decided to use the renderpass setting to combine classic CTM with a repeat (and no backface culling) so it was better than classic CTM.
I was quite pleased with the results
Then, the old new pack format came out, and you updated how CTM was used (I don't know if Optifine ever did), so I decided to up support on it. I had already changed many of my textures to odd resolution for the new format, I think this was also around the time I discovered you added innerSeams. With my non-CTM glass texture changing, I decided to take a second look at how classic CTM worked.
EDIT: updated pic
With innerSeams, no backface culling, and the designs you can make (and that every block has pixels on it), I just love it. I have been thinking back on it now that the new new pack format is here, wishing I could be using my CTM glass. I guess I'm just itching to get it 1.6 ready.
Once again, thank you, and sorry for the long post (I wasn't intending to do this). Just something I feel like I had to say because I'm usually the guy who says "I don't use mods", but now I'm a little less of that guy
EDIT: I actually decided to try and get it working again with 12w23b.
It's really cool that the latest version of the patcher automatically patches the .JAR to a directory in the /versions/ dir even with a proper .json file!
However, when I got it working I noticed a problem.
It was loading more .properties files from my texture pack than previous versions. When the first new pack format came out, you changed it to stop loading them from /ctm/ in texture packs, instead loading them only from folders within them (default being /ctm/ctm/). I was using this fact to keep my old files in as legacy support for the old pack format.
Now (well, in 12w23b and 4.0 beta4) it will load any files in /ctm despite them:
a.)being in the same folder as full CTM sheets
b.)having duplicates in the folders in /ctm/
After they try to load, they don't because it trys to read from unstitched images, causing a magenta/black square to be used as the texture. This could either be fixed by restoring the older behavior of only loading from folders within /ctm/ but not files directly in it, or better yet, when encountering errors (and only telling about it), continue trying to load other .properties until they have all been tried.
Perhaps detecting files with the source= line as legacy, or possibly even a parsed comment (like #!/legacy/1.4) at the top of the document?
EDIT2: Also, my animations were completely messed up, and not loading the frame order at all, not sure why... happens with default lava, too. (and skins not loading after texture pack change, followed by crash on world exit and reload)
"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
There are a lot of things like Random Mobs that should be in the game by now (without MCPatcher), the horses are random so the code must be there.
http://www.johnsmithlegacy.co.uk/ - John Smith Legacy for Java Minecraft
The "Now I will wait an additional 2 weeks. happy?" in the comment section, to be frank it sounds like Grum is just being childish and vindictive since someone mentioned that it's up to Kahr again to support HD font. Seems like Grum got a little butthurt and that is wholly unprofessional -- you don't wait to fix a bug because someone annoyed you. You wait because you don't have time or because there are bigger bugs to squash or whatever other technical/time reasons that force devs to not fix bugs.
I can understand getting frustrated at the mewling masses, but that's something you keep to yourself. You don't take it out on your fans, Grum, that's inappropriate. Minecraft is a popular game with a big community, as a dev. you have to expect people to be on your butt to fix bugs and you have to expect that more than half of the people are going to be frustrated and rude.
#Tact
Sorry about the little rant. In any case, please keep up the great work Kahr. I held off on using Dinnerbone's TexureEnder converter because I had heard it was a bit buggy so I'm looking forward to yours and updating my TP and messing around with 1.6.
At long last, MCPatcher is updated for 1.6 including the new resource pack format! Included is a new utility for converting 1.5 texture packs into resource packs. This replaces Mojang's TextureEnder.jar while also moving all MCPatcher-related files to a new directory structure.
The new layout is roughly
assets/minecraft/textures - all vanilla files assets/minecraft/mcpatcher - all MCPatcher files ~ = assets/minecraft/mcpatcher ~/anim - Custom animations (not items or blocks) ~/cit - Custom Item Textures rules ~/cit.properties - Global CIT properties ~/colormap - Custom biome palettes ~/color.properties - Global Custom Colors settings ~/ctm - Connected Textures rules ~/dial - Custom clock and compass ~/font - HD Font. Your font will be moved here if it is either higher res than vanilla or it has a properties file / glyph_sizes.bin ~/lightmap - Custom lighting palettes for overworld, Nether, the End ~/line - Custom fishing line and lead textures ~/mob - Random Mobs alts and biome+height rules ~/renderpass.properties - Better Glass ~/sky - Skybox textures and properties for Better SkiesWith the new resource pack system, Mojang changed the way textures are referenced internally. This required some changes to the way you specify textures within MCPatcher properties files. No one wants to keep typing assets/minecraft/etc. over and over, so I've added some easier ways to specify textures without the paths getting so long.
The converter will automatically update the contents of your properties file too, so just look at those if this seems confusing.
What is a "namespace"? Basically they are a way for Mojang to separate mods from each other and from vanilla in the future. For now you don't need to worry about them. Everything is in the default "minecraft" namespace, but that may change depending on how ModLoader, et. al decide to handle things.
Most questions about the new format can be answered by converting your texture pack and looking at where files end up. But a couple things deserve mention.
Fonts. Since 1.6 does not properly support HD Fonts, MCPatcher's font support is still active, but it will only read from assets/minecraft/mcpatcher/font, not the vanilla directory assets/minecraft/textures/font. So, if you like, you can have a custom font that works in vanilla and a higher resolution font that requires MCPatcher to display properly. Essentially, this replaces default.png and default_hd.png in the old system. The converter tries to be intelligent about where it puts your old font files, but it may guess wrong, so just move the files manually if that happens.
Mob Textures. Separating MCPatcher and vanilla means that the base mob texture is in one directory and the alternates are in another. Basically, replace "textures/entity/" with "mcpatcher/mob/", keeping whatever directory structure Mojang used below that. Unfortunately Mojang wasn't very consistent here. Some mobs have a subfolder and some have just a texture.
In other words,
- Custom biome coloring for the Sky biome and the Hell biome
- The ability to add biome specific fire textures
- Add the hat layer to mob heads (It would add more depth to them, and texture packs would look way better with this)
- RandomMob sounds
- The ability to add a hat layer to mobs that don't have it currently (Bats, Blaze, Slime, Creeper, Villager, Pig, etc...)
So those are my requests/suggestions. I'm sure these additions to MCPatcher would be quite useful to most if not all texture pack creators that use them.Please deeply consider adding these features.
A reply would be great
Thanks, HunterBlackbrick
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumAs mentioned, later vanilla 1.6 snapshots were not the same places to wander as they had been through MC Patcher eyes.
Many thanks.