Download 3.0.0-BETA3 and click on Convert Texture Pack at the top. It doesn't work for me and gets stuck at 75%, but hey, it's WIP and is not final so I'm not fretting. Kahr has never let us down!
The new format dosn't support the multiuse of one texture. Example: Replacing wood texture on woodblocks and stairs uses two folders with the same image in it. So the texpack size rises. The best is ctm for every texture like the animation for everything with a source image/folder path and a target image/folder path. In my opinion it's better to have one ctm propertie that includes all. So you have no endless list of properties in the ctm folder and if this is not possible a subfolder for all the folders with ctm textures/properties is a good idea. At the moment it the ctm folder includes too many files/folder in it's direct location.
Still want an option for texturepack specific language files (if it's possible).
Even if all the .properties files were made into one big file the file size(for the .properties files) will still be the same, because you still need to store all the bit & bytes of information that's in the .properties files, so the beginning & end file size would be the same. NOW, on CTM being able to use one texture image for multiple textures is a nice idea.
I can certainly share in everyone's frustration. Mojang apparently made these changes without consulting anyone from the texture pack community (certainly not me). Even skimming over the Information for Texture Pack Authors section in my OP could have saved everyone a lot of grief.
>>> Suggestion: Why not using vertical tilesheets for CTM (similar to animations)?
That's the problem. Vertical tilesheets already mean "animation". I'm not thrilled with Mojang's choice of format either, but I feel obligated to stick to it as much as possible both for consistency and for the sake of code reuse. In this case, as I said, that means CTM gets animation support (with or without .txt files) for free.
Having all CTM tiles for a block in one texture file would definitely be easier to work with (e.g. the CTM texture for wooden logs would contain 47 tiles in a vertical arrangement). Besides, it would decrease the size of a texturepack (the new single-file format increases the size of the CTM folder by 20-30% ... this can be several megabytes when working with HD textures).
While that would cut down on file size, it would take up the same amount in memory where it matters most. The only real benefit comes from eliminating duplicates, and that has tradeoffs too.
3.) It's currently not possible to place the properties files in their repsective folders, e.g. moving block1.properties to the folder "block1"
Each folder being self-contained makes sense, but I'm not sure it's worth the potential confusion of moving ctm properties files from their old location.
4.) The "CTM textures applied to handheld blocks" feature needs some work, especially with slabs and glass blocks:
That part of the code is fragile enough as it is (see: the ender chest bug). The game really, really hates using more than one tilesheet for rendering blocks -- one of my biggest frustrations is that 1.5 doesn't address this at all. I'll see what I can do about slabs, but any block with a special renderer is a special case that raises the chance the patch will break in a future update.
Is there any way to make two properties files use one single texture with the new format? Having clones of a texture isn't very efficient... even better would be:
I knew duplicate textures would happen, but wasn't sure how big a problem they would be. But if tile locations can't be inferred, then they have to be listed one by one. Would you really want to see this?
I'm open to suggestions, but keep in mind it has to support animations. The old way of specifying them won't work because x,y coordinates are unpredictable now that they're computed by Mojang's stitching algorithm.
Dumping all the data for all CTM textures (methods, faces, metadata, ...) in one single properties file --> less files --> less chaos --> faster and more efficient creation of CTM textures
Combining all ctm properties into a single file would be an absolute mess, sorry.
I've came up with a CTM method to make better grass generic as well. You should be able to make conditional methods (like with metadata) to texture a block face based on which block ID it is in direct contact with.
What do you think this would be useful for?
My question to you (since you've been digging through Minecraft's code base for a while) is it feasible to rewrite the (texture) render engine to use a completely new dynamic texture format, possibly bumping the OpenGL requirements to 3.2 and introduce real dynamic lightning like the shader mod and the environmental, and parallax occlusion mappings configured by the index file? Even introduce the shader config files for (water or whatever) refraction to the texture pack itself.
Rumor has it Mojang has something like this planned for 1.6~1.7. I can only guess that it was part of the motivation behind the new texture pack format.
I knew duplicate textures would happen, but wasn't sure how big a problem they would be. But if tile locations can't be inferred, then they have to be listed one by one. Would you really want to see this?
I'm open to suggestions, but keep in mind it has to support animations. The old way of specifying them won't work because x,y coordinates are unpredictable now that they're computed by Mojang's stitching algorithm.
My suggestion would be something like this...
bricks.properties
source=/ctm/ctm/
#folder to look in for png files. Default location would be bricks/ found alongside this property file.
filenames=238 238 239 239
#list of filenames for this property to use. Default is 0 to however many the method needs.
faces=north south
height=1
width=4
matchBlocks=45
method=horizontal
Ive also tried the converter and found that it ignores source and takes all tiles from /ctm/ctm.png.
Unrelated stuff about ctm.
Just some things about ctm that i've discovered but i'm not sure if anyone else knows...
You can organize property files into sub folders of the ctm folder.
You can have more than one ctm folder in your texturepack by appending text to the end of the foldername.
eg.
/ctm/
/ctm2/
/ctmb/ ...
You can use different methods for the betterglass frame and the fill. The frame can be ctm whilst the fill can be fixed.
I'm not active on these forums, so forgive me if I don't respond!
If you want to contact me, try going through Discord or you can find me on GitHub where I am still updating the below mods (and more):
You could for example use it to make Better Grass or Better Show blend better with the environment. It would actually do everything the "A lot better Grass and Snow" mod does just without a new mod and with the possibility to use it for other blocks aswell.
Maybe you could even make the border between a grass and a snow block look like they merge.
But the reason why I would love to have it included would be this:
Although it would have to be possible to check every of the eight blocks around a texture to achieve this effect and not only the ones directly connected.
Additionally it could also make grass blocks with flowers on top but with snow in other directions look like snow and therefor improving snow biomes a lot.
How did you make that picture?!
Anyway, what kexikus brings up is a good point; I've always hated better grass because I thought it was ugly, but this may be able to make it less ugly!
Ok, so I went back to the drawing board and came up with this proposed CTM format.
Properties files move into the subfolders of /ctm alongside their textures.
Subfolders can contain more than one properties file. Properties files in the same folder pull from the same set of textures.
Subfolder names are arbitrary. You can organize them however you like. One folder per properties file, all files in one folder, or anything in between.
The tiles= property is required again to specify which textures to use:
tiles=0-4 6 (Uses /ctm/myctm/0.png, /ctm/myctm/1.png, etc. /ctm/myctm/ refers to the folder containing the .properties file)
You can name your textures instead of number them and refer to them that way. The .png extension is optional.
tiles=mygrass1 mygrass2 (Uses /ctm/myctm/mygrass1.png and /ctm/myctm/mygrass2.png)
You can refer to tiles outside of the directory (including vanilla textures) by using a full path, for example,
iterating through multiple folders to find properties is going to be a pain. :-/ Oh well.
Anyway, I maintain a minimap mod. It currently has CTM support. I'm having some issues with the new format. I keep track of block colors by blockID and metadata (that's what's returned by world.world.getBlockId() - makes it easier when dynamically drawing a map). I can parse the blockID from the blockXX.properties filename, but it's pretty hard to associate the old terrainID properties with a particular blockID - stuff like cloth0, or sandstone_smooth. Those strings are stored in the Icon returned by getBlockTextureFromSideAndMetadata(), but it's a lot easier to start with a blockID and metadata and get the Icon than it is to go from a String in an Icon and figure out which blockID it belongs to :-/
I've experimented with iterating through all the blockid/metadata possibilities and storing the blockname String from the resulting Icon in an array, then comparing that against the name of the properties files in order to match it to the right blockID. It's massively kludgy though Am I missing some more obvious method?
Anyway, it would be nice if getBlockTextureFromSideAndMetadata() returned the actual texture (after MCPatcher has done its thing), then I could get CTM etc just by doing what I'm already doing. MCPatcher seems to change things somewhere after that though. Again, if I'm missing anything..
At any rate, I appreciate you putting out releases for the snapshots. Big help making sure I'm ready to go when 1.5 comes out! Thanks!
Two questions:
Could you please make the CTM-Mod like the Anim-Mod so that you can make mods like IC2 or SEUS Bumpmapping compatible?
And is it able to make a mod in which the weapons have different textures for each of its damage-types?
i am having major lag problem with vondoomcraft tp. it went from 130fps default down to under 5fps. (patcher version 3.0.0beta4) conversion worked fine, but minecraft is unplayable. i normally have 40fps with vondoomcraft and shader mod.
MCPatcher 3.0.0-beta4 is out, fixing the chest rendering and supporting a new CTM format. To update to the new format, either convert your old (1.4.7) pack again, or just move each /ctm/xxx.properties file into its /ctm/xxx/ folder.
Anyway, it would be nice if getBlockTextureFromSideAndMetadata() returned the actual texture (after MCPatcher has done its thing), then I could get CTM etc just by doing what I'm already doing.
The are a couple of problems to doing it that way unfortunately. One, I'd have to patch every Block-subclass's getBlockTexture* methods (dozens of them), and that wouldn't even catch blocks added by mods. I don't know if CTM will work for mod blocks now -- we'll have to wait until ModLoader and Forge update -- but I think it's at least possible.
The second problem is that overriding the returned texture isn't enough. You potentially have to use a different Tessellator as well, or you'll end up drawing the right coordinates using the wrong texture. If Mojang would replace Tessellator.instance with Tessellator.getForTexture(Icon icon), I wouldn't have to worry about that. But until then, I'm forced to inject my code in places that have local variables for both the texture to be drawn and the tessellator drawing it.
Anyway, all the interesting CTM stuff happens inside of RenderBlocks. There are a lot of rendering methods, but they mostly follow the same pattern, which makes patching easier.
Two questions: Could you please make the CTM-Mod like the Anim-Mod so that you can make mods like IC2 or SEUS Bumpmapping compatible? And is it able to make a mod in which the weapons have different textures for each of its damage-types?
I can't even begin looking into the first one until the shader mod is updated to 1.5. As for custom item textures, I haven't thought about it much, but it seems feasible at least.
Can someone please explain to me why when I go to download the file. It downloads something called setup.exe, and prompts me to install 6 different versions of sometime called "continue to save." It changes everything in my internet settings to direct to ing bing.com
I can't even begin looking into the first one until the shader mod is updated to 1.5.
I mean like the Anim mod.
Here exeple:
from=/ctm/icmachine1.png
to=/ic2/sprite/block_machines.png
x=0
y=0
w=32
h=32
method=random
Do you understand what I mean? CTM for all textures if it be possible.
I don't even want to know to redo stuff with the CTM again(I still will though). Now with what the few people are saying about doing with Better Grass & Better Snow. I know I will have to add that in at some point so that's going to be hard to learn. I barely understand how to do CTM, much less than Better Grass, Better Snow, Better Skies, & Better Glass. But I hope it'll be easier than before. Can't wait to look through a texture pack(most likely "Better Than Default" because of all the CTM it has)learning how the new CTM works.
hhhmm...I wander is it possible to have stone texture thats different when it has a Silverfish in it & when it doesn't??? Can you do that with CTM??? Just wandering.
I know they still work, but I'm talking about what 2nv2u & Kexikus are saying what they want to do with Better Grass & stuff. I would like to learn it so I can add it to my 32x texture pack, but learning it would be stressful for me. I also have looked through drfrozenfire's thread already before(& bookmarked it too), but I will look through the doc files now. Thank you, hopefully they will help me understand it better now.
Although I would really like more flexible texture techniques and I've been digging through the Minecraft code for a couple of hours lately (which was unfortunately kinda discouraging). You should keep in mind this is nothing more than a proposal. Kahr hasn't confirmed doing this nor does it mean the old mod will disappear any time soon.
As for the available CTM I also recommend reading the docs and the mentioned thread which does explain the features quite well.
I know it's a proposal. I'm just saying it looks hard to set up & config, & I am looking through the docs & the thread.
Can someone please explain to me why when I go to download the file. It downloads something called setup.exe, and prompts me to install 6 different versions of sometime called "continue to save." It changes everything in my internet settings to direct to ing bing.com
That's bcs you have very ugly avatar image
BTW, it' time for you to take Nod32 or something like that - microsoft security essentials works pretty good too... You may even end up reinstalling your windows.
In order to use converted TP, I have to repack it, or unpack the texture in the folder. There is some bug while making archive file.
Now I see that in the current snapshot (13w04a) I get this:
Everything works fine with the same converted texturepack, on 13w03a (better than default). I think it needs some more updating
CTMs are according to Khar's specs, but it simply won't display needed images. 13w03a does work just fine. And doesn't crash with the MCPatcher's converted and packed textures like in 13w04a
That doesn't make any sense! I have to make CTM files from scratch, like everyone else, and there are no #comments or guides in nonexistent things!
Even if all the .properties files were made into one big file the file size(for the .properties files) will still be the same, because you still need to store all the bit & bytes of information that's in the .properties files, so the beginning & end file size would be the same. NOW, on CTM being able to use one texture image for multiple textures is a nice idea.
That's the problem. Vertical tilesheets already mean "animation". I'm not thrilled with Mojang's choice of format either, but I feel obligated to stick to it as much as possible both for consistency and for the sake of code reuse. In this case, as I said, that means CTM gets animation support (with or without .txt files) for free.
While that would cut down on file size, it would take up the same amount in memory where it matters most. The only real benefit comes from eliminating duplicates, and that has tradeoffs too.
I actually considered doing it this way:
Each folder being self-contained makes sense, but I'm not sure it's worth the potential confusion of moving ctm properties files from their old location.
That part of the code is fragile enough as it is (see: the ender chest bug). The game really, really hates using more than one tilesheet for rendering blocks -- one of my biggest frustrations is that 1.5 doesn't address this at all. I'll see what I can do about slabs, but any block with a special renderer is a special case that raises the chance the patch will break in a future update.
I knew duplicate textures would happen, but wasn't sure how big a problem they would be. But if tile locations can't be inferred, then they have to be listed one by one. Would you really want to see this?
I'm open to suggestions, but keep in mind it has to support animations. The old way of specifying them won't work because x,y coordinates are unpredictable now that they're computed by Mojang's stitching algorithm.
Combining all ctm properties into a single file would be an absolute mess, sorry.
What do you think this would be useful for?
Rumor has it Mojang has something like this planned for 1.6~1.7. I can only guess that it was part of the motivation behind the new texture pack format.
My suggestion would be something like this...
bricks.properties
Ive also tried the converter and found that it ignores source and takes all tiles from /ctm/ctm.png.
Unrelated stuff about ctm.
- You can organize property files into sub folders of the ctm folder.
- You can have more than one ctm folder in your texturepack by appending text to the end of the foldername.
eg.If you want to contact me, try going through Discord or you can find me on GitHub where I am still updating the below mods (and more):
PRESENCE FOOTSTEPS - (github)
VOID FOG - (github)
How did you make that picture?!
Anyway, what kexikus brings up is a good point; I've always hated better grass because I thought it was ugly, but this may be able to make it less ugly!
(Uses /ctm/myctm/0.png, /ctm/myctm/1.png, etc. /ctm/myctm/ refers to the folder containing the .properties file)
(Uses /ctm/myctm/mygrass1.png and /ctm/myctm/mygrass2.png)
(Uses /ctm/my_other_ctm/5.png)
Old format (1.4.7) using examples from Misa's pack:
/ctm/block125.properties source=/ctm/misactm.png method=horizontal tiles=76-79 metadata=2 /ctm/block126a.properties source=/ctm/misactm.png method=horizontal tiles=140-143 metadata=10 /ctm/misactm.pngThe converter will output this:
/ctm/misactm/block125.properties method=horizontal tiles=76-79 metadata=2 /ctm/misactm/block126a.properties method=horizontal tiles=140-143 metadata=10 /ctm/misactm/76.png /ctm/misactm/77.png /ctm/misactm/78.png /ctm/misactm/79.png /ctm/misactm/140.png /ctm/misactm/141.png /ctm/misactm/142.png /ctm/misactm/143.pngAgain, the folder name misactm is arbitrary, and just serves to separate groups of textures that used to be in the same tilesheet.
I think this gives the most flexibility, addresses most of the objections to the beta3 format, and still allows for CTM animations.
Anyway, I maintain a minimap mod. It currently has CTM support. I'm having some issues with the new format. I keep track of block colors by blockID and metadata (that's what's returned by world.world.getBlockId() - makes it easier when dynamically drawing a map). I can parse the blockID from the blockXX.properties filename, but it's pretty hard to associate the old terrainID properties with a particular blockID - stuff like cloth0, or sandstone_smooth. Those strings are stored in the Icon returned by getBlockTextureFromSideAndMetadata(), but it's a lot easier to start with a blockID and metadata and get the Icon than it is to go from a String in an Icon and figure out which blockID it belongs to :-/
I've experimented with iterating through all the blockid/metadata possibilities and storing the blockname String from the resulting Icon in an array, then comparing that against the name of the properties files in order to match it to the right blockID. It's massively kludgy though
Anyway, it would be nice if getBlockTextureFromSideAndMetadata() returned the actual texture (after MCPatcher has done its thing), then I could get CTM etc just by doing what I'm already doing. MCPatcher seems to change things somewhere after that though. Again, if I'm missing anything..
At any rate, I appreciate you putting out releases for the snapshots. Big help making sure I'm ready to go when 1.5 comes out! Thanks!
Could you please make the CTM-Mod like the Anim-Mod so that you can make mods like IC2 or SEUS Bumpmapping compatible?
And is it able to make a mod in which the weapons have different textures for each of its damage-types?
The are a couple of problems to doing it that way unfortunately. One, I'd have to patch every Block-subclass's getBlockTexture* methods (dozens of them), and that wouldn't even catch blocks added by mods. I don't know if CTM will work for mod blocks now -- we'll have to wait until ModLoader and Forge update -- but I think it's at least possible.
The second problem is that overriding the returned texture isn't enough. You potentially have to use a different Tessellator as well, or you'll end up drawing the right coordinates using the wrong texture. If Mojang would replace Tessellator.instance with Tessellator.getForTexture(Icon icon), I wouldn't have to worry about that. But until then, I'm forced to inject my code in places that have local variables for both the texture to be drawn and the tessellator drawing it.
Anyway, all the interesting CTM stuff happens inside of RenderBlocks. There are a lot of rendering methods, but they mostly follow the same pattern, which makes patching easier.
I can't even begin looking into the first one until the shader mod is updated to 1.5. As for custom item textures, I haven't thought about it much, but it seems feasible at least.
I mean like the Anim mod.
Here exeple:
from=/ctm/icmachine1.png
to=/ic2/sprite/block_machines.png
x=0
y=0
w=32
h=32
method=random
Do you understand what I mean? CTM for all textures if it be possible.
I know they still work, but I'm talking about what 2nv2u & Kexikus are saying what they want to do with Better Grass & stuff. I would like to learn it so I can add it to my 32x texture pack, but learning it would be stressful for me. I also have looked through drfrozenfire's thread already before(& bookmarked it too), but I will look through the doc files now. Thank you, hopefully they will help me understand it better now.
That's bcs you have very ugly avatar image
BTW, it' time for you to take Nod32 or something like that - microsoft security essentials works pretty good too... You may even end up reinstalling your windows.
In order to use converted TP, I have to repack it, or unpack the texture in the folder. There is some bug while making archive file.
Everything works fine with the same converted texturepack, on 13w03a (better than default). I think it needs some more updating
CTMs are according to Khar's specs, but it simply won't display needed images. 13w03a does work just fine. And doesn't crash with the MCPatcher's converted and packed textures like in 13w04a