Basically, it allows you to set custom item textures based on certain criteria. For example, before Charcoal had its own texture in vanilla, you could force it to have one based on the item's metadata. You can also force an item to have separate textures based on things like name, enchantments, damage, or any other in-game variable.
Oh, well that's good then. Looks like I can have the actually fiery fire aspect swords I've always wanted.
I've sorted my CTM into two folders, but only the files from one of the folders are being applied. Is there any reason for this? Does the numbering in the second folder need to continue on from the numbering in the first?
Is Mojang's converter as bad as I've been hearing? I was hoping to avoid writing my own texture pack converter again. I'd rather work on new features like CIT than pick up Mojang's slack.
It's ok, I suppose, but like mmtr1x3 said, it doesn't delete empty folders or MC Patcher specific folders (the second being a good thing really), so all anims and ctm are left sitting useless, but still intact and apart from mucking up use of HD packs in snapshot 24b, the basic pack at least worked in 24a.
If you're able to produce some kind of converter for all the ctm, anim and other .properties files, that would be enormously helpful...I'd hate to have to convert masses of .properties files if it could be done with a script. Could this be an automatic or optional function of the next patcher or is that just stating the obvious? Otherwise we're in the situation that all old packs that relied on MC Patcher, now no longer supported and able to be converted by a texture artist, will generate endless cries for help from all and sundry.
At this stage we're in your hands as to where all the MC Patcher stuff will go in the new resource pack layout. At the moment it feels like the Mojang ship set sail and left all the MC Patcher cargo on the dockside.
Hi!
I'm on a mac computer and I have downloaded McPatcher and I when I click on the .jar, it won't open! I need help. I have a new MC and I use the faithful texture pack. Any help?
Rollback Post to RevisionRollBack
Hello! Im a moderately experienced Minecrafter who will need help occasionally and give help to people who need it!
I need help. I downloaded MC Patcher lately and I ran the correct version for 1.5 and a popup appears every time. It says that Minecraft couldn't be found in .minecraft. I checked everything and Minecraft is there, but for some reason MC Patcher just won't open .minecraft!
I need help. I downloaded MC Patcher lately and I ran the correct version for 1.5 and a popup appears every time. It says that Minecraft couldn't be found in .minecraft. I checked everything and Minecraft is there, but for some reason MC Patcher just won't open .minecraft!
Probably because the version you've installed is for the latest snapshots, not 1.5; it requires the new launcher to be able to run.
Download the one in the OP, not on this page.
I've sorted my CTM into two folders, but only the files from one of the folders are being applied. Is there any reason for this? Does the numbering in the second folder need to continue on from the numbering in the first?
Still no ideas?
EDIT: I've tested, and it appears to be just my texture pack that's not working. Is there anything I could be doing wrong? For those who want to have a look themselves, I'll put it up to download here.
I've caught another bug with MCPatcher, it is messing up lots of textures. Download the Conquest texturepack by Monsterfish and place a sideways birch log facing east to west. This is only one example of it if you compare it to the birch log facing north to south. Also, it messes up other wood textures too. I don't have this problem with OptiFine, but I don't like it because it lowers my FPS.
Edit: Just tested, and it seems to have something to do with the "standard blocks" option. Will report it to Monsterfish too.
Time: 6/12/13 11:45 AM
Description: Unexpected error
java.lang.ClassCastException: bgx cannot be cast to bgy
at bdr.a(SourceFile:83)
at bdr.a(SourceFile:67)
at bdr.j(SourceFile:38)
at bdr.<init>(SourceFile:27)
at bdu.<init>(SourceFile:39)
at bcf.<init>(SourceFile:28)
at bcb.a(SourceFile:271)
at atc.a(SourceFile:1516)
at atc.a(SourceFile:1468)
at bbu.a(SourceFile:149)
at ef.a(SourceFile:71)
at cl.b(SourceFile:64)
at atc.k(SourceFile:1401)
at atc.R(SourceFile:660)
at atc.d(SourceFile:616)
at net.minecraft.client.main.Main.main(SourceFile:82)
A detailed walkthrough of the error, its code path and all known details is as follows:
---------------------------------------------------------------------------------------
-- Head --
Stacktrace:
at bdr.a(SourceFile:83)
at bdr.a(SourceFile:67)
at bdr.j(SourceFile:38)
at bdr.<init>(SourceFile:27)
at bdu.<init>(SourceFile:39)
at bcf.<init>(SourceFile:28)
at bcb.a(SourceFile:271)
at atc.a(SourceFile:1516)
at atc.a(SourceFile:1468)
at bbu.a(SourceFile:149)
at ef.a(SourceFile:71)
at cl.b(SourceFile:64)
-- Affected level --
Details:
Level name: MpServer
All players: 0 total; []
Chunk stats: MultiplayerChunkCache: 0
Level seed: 0
Level generator: ID 00 - default, ver 1. Features enabled: false
Level generator options:
Level spawn location: World: (8,64,8), Chunk: (at 8,4,8 in 0,0; contains blocks 0,0,0 to 15,255,15), Region: (0,0; contains chunks 0,0 to 31,31, blocks 0,0,0 to 511,255,511)
Level time: 0 game time, 0 day time
Level dimension: 0
Level storage version: 0x00000 - Unknown?
Level weather: Rain time: 0 (now: false), thunder time: 0 (now: false)
Level game mode: Game mode: creative (ID 1). Hardcore: false. Cheats: false
Forced entities: 0 total; []
Retry entities: 0 total; []
Stacktrace:
at bcc.a(SourceFile:282)
at atc.b(SourceFile:1795)
at atc.d(SourceFile:630)
at net.minecraft.client.main.Main.main(SourceFile:82)
-- System Details --
Details:
Minecraft Version: 13w23b
Operating System: Windows 7 (amd64) version 6.1
Java Version: 1.7.0_21, Oracle Corporation
Java VM Version: Java HotSpot™ 64-Bit Server VM (mixed mode), Oracle Corporation
Memory: 133618064 bytes (127 MB) / 494927872 bytes (472 MB) up to 954466304 bytes (910 MB)
JVM Flags: 1 total; -Xmx1G
AABB Pool Size: 13154 (736624 bytes; 0 MB) allocated, 10816 (605696 bytes; 0 MB) used
Suspicious classes: ~~ERROR~~ NoClassDefFoundError: com/prupe/mcpatcher/cit/EnchantmentList$1
IntCache: cache: 0, tcache: 0, allocated: 3, tallocated: 63
Launched Version: 13w23b-mcpatcher
LWJGL: 2.9.0
OpenGL: GeForce GT 540M/PCIe/SSE2 GL version 4.3.0, NVIDIA Corporation
Is Modded: Very likely; Jar signature invalidated
Type: Client (map_client.txt)
Texture Pack: Default
Profiler Position: N/A (disabled)
Vec3 Pool Size: 0 (0 bytes; 0 MB) allocated, 0 (0 bytes; 0 MB) used
It occurs when I switch textures. My skin turns weird colors, doesn't affect the game, until I save and try to join any world save.
Wanted to make sure you saw these, since it seems like there has been lots of posts right after this. The Conquest thing may be a bug with the pack itself, but I thought I'd let you know.
Is it possible to add a feature to CTM that changes a block texture depending on the neighboring block being a different type?
For instance: Stone block next to a grass/dirt block.
With this it would be possible to create textures for transition blocks between common types (sand, dirt, stone, grass, gravel). Blending the transition. Would look so sweet.
Kahr, would you be interested in / willing to add support for storing the CTM information within the mcmeta files? I know I'd rather just deal with one type of file when adding extra data rather than having to mix and match .mcmeta with .properties.
Kahr, would you be interested in / willing to add support for storing the CTM information within the mcmeta files? I know I'd rather just deal with one type of file when adding extra data rather than having to mix and match .mcmeta with .properties.
I wouldn't. The .mcmeta format is a complicated mess. It's too easy to cause it to fail because of a misplaced bracket or some little bit of technical whatever that a normal person wouldn't think twice about. If anything I want Mojang to take a page from Kahr's book and switch over to using his easy-to-understand .properties format.
Ultimately it's up to you, Kahr, to do what you feel is best. Just putting in my two cents.
I wouldn't. The .mcmeta format is a complicated mess. It's too easy to cause it to fail because of a misplaced bracket or some little bit of technical whatever that a normal person wouldn't think twice about. If anything I want Mojang to take a page from Kahr's book and switch over to using his easy-to-understand .properties format.
Ultimately it's up to you, Kahr, to do what you feel is best. Just putting in my two cents.
Eh, I'm not suggesting dropping .properties files, just adding the ability to pull the same data out of the .mcmeta files. I prefer .mcmeta because JSON is a bit more flexible and 'easy' to deal with from a programming standpoint. But then I do this sort of thing for a living. Course I can also completely understand it if Kahr wouldn't want any part of messing with it. If he decides it's not worth his time, I'll probably just do what I usually do and make up a bunch of Perl scripts for converting the files for my own use.
Rollback Post to RevisionRollBack
Tis far better to be a witty fool than a foolish wit.
So i got the random method of ctm to work, but the thing is that out of 7 textures, only one (the base one) appears often; the other ones show up rarely. I tried working with the weight commandline, but it has little effect.
Probably because the version you've installed is for the latest snapshots, not 1.5; it requires the new launcher to be able to run.
Download the one in the OP, not on this page.Still no ideas?
EDIT: I've tested, and it appears to be just my texture pack that's not working. Is there anything I could be doing wrong? For those who want to have a look themselves, I'll put it up to download here.
Hmmmm... I was diggin in there and I seen the CTM folder is properly set up, (for a moment I thought you had two folders for ctm stuff in the root folder... Lemme give it a look and I'll see what I can do!
Eh, I'm not suggesting dropping .properties files, just adding the ability to pull the same data out of the .mcmeta files. I prefer .mcmeta because JSON is a bit more flexible and 'easy' to deal with from a programming standpoint. But then I do this sort of thing for a living. Course I can also completely understand it if Kahr wouldn't want any part of messing with it. If he decides it's not worth his time, I'll probably just do what I usually do and make up a bunch of Perl scripts for converting the files for my own use.
Most of us don't understand any actual "programming", and I'm not trying to sound negative or anything, but if a game or anything could just read from a file that has simple text, an option/variable/property type thing per line, written in english, why do these actual coding languages feel the need to use this convoluted with brackets and weird characters? Like, did they make it that foreign just to make it look more complicated and thus more professional?
Either way, there was no reason for them to switch to that mcmeta , because all it's done is made kahr's job that much harder, and discouraged and confused the out of most TP artists.also, thank minecraft forum for making my last post look unintelligent and disjointed by completely removing my "bad words" instead of replacing them with asterisks or something. They could ing warn us about that before we post.....
Time for a progress update. I put in a ton of hours over the weekend and I'm happy to report that all major features are working again. Fortunately 13w25a was only a minor setback (I want to smack whoever removed the method "bis a();" from bir.class), and I can focus on testing and bugfixing. Needless to say, backward compatibility with earlier snapshots is not an option.
Once again a custom texture pack converter was all but required for my own sanity, and the result is a TextureEnder.jar replacement. When I get to a certain point in my development, I need a way to convert texture packs for testing. Doing it by hand is too tedious and error-prone. So I write something automated, and then figure I might as well polish it up and release it.
This is just as well because it gives me an opportunity to change the directory structure of MCPatcher's files to better match Mojang's new layout. Everything will move into the assets/minecraft/textures folder. Some files will have new locations that make more sense (misc/watercolorX.png -> textures/colormap/water.png, for example). All this will be handled automatically for you, and I plan to add a few vanilla things Mojang left out, like default .mcmeta files for shadow.png, etc.
Of interest to modders. 1.5 abstracted tile indices into a new Icon class. 1.6 is doing something similar for texture paths. Textures and other resources are no longer referred to by Strings but by a new class I've named ResourceAddress (bis.class in 13w24b). Essentially it's a namespace plus a path. The object new ResourceAddress("minecraft", "textures/blocks/cobblestone.png") expands to "assets/minecraft/textures/blocks/cobblestone.png". All methods for loading, allocating, and switching textures have been changed to accept ResourceAddress parameters instead of Strings.
This affects artists as well. You'll always refer to textures relative to assets/minecraft in your .properties files:
# wrong
from=assets/minecraft/textures/anim/sheepblink.png
to=assets/minecraft/textures/entity/sheep/sheep.png
# correct
from=textures/anim/sheepblink.png
to=textures/entity/sheep/sheep.png
# also correct if file is at assets/mystuff/sheep/sheepblink.png
from=mystuff:sheep/sheepblink.png
to=textures/entity/sheep/sheep.png
As for namespaces, it's too early to tell how/if they will be used. Only the default minecraft namespace is used in vanilla. I've made some effort to accommodate other namespaces in MCPatcher, but it's not perfect so expect problems if you put anything outside of assets/minecraft.
I mentioned something about changing the Minecraft directory with the new launcher some days ago. When using the "--workdir" argument, it's possible to make the launcher download everything to the specified folder, so it's no longer necessary to have any files at "AppData/Roaming/.minecraft". Would it be possible to let the Patcher remember the last directory I used? Otherwise an error message pops up everytime I try to patch the game and I have to select my new Minecraft directory again.
You can use the -mcdir command line option to specify the initial Minecraft directory location so you don't have to search for it each time. The problem with your suggestion is that I have nowhere to bootstrap the last specified folder except AppData/Roaming/.minecraft. (Windows registry or anything else platform-specific is out for obvious reasons.)
At some point I want to merge MCPatcher's profiles with the profile system in the new launcher. I'll re-evaluate this request then.
Slight problem here. I'm missing the HD Textures option. How do I get it? Do I install it, or something else?
I really need to update those screenshots. HD Textures was renamed to Extended HD since the game natively supports higher resolutions in 1.5. Extended HD is kind of a grab-bag of graphical enhancements that don't fit the other categories.
Kahr, would you be interested in / willing to add support for storing the CTM information within the mcmeta files? I know I'd rather just deal with one type of file when adding extra data rather than having to mix and match .mcmeta with .properties.
I briefly considered moving everything to json but decided against it. The only real benefit is that json allows deeper, nested structures that are hacky to represent in a flat format like .properties. palette.block.* is especially cringeworthy. Others have already covered the disadvantages of json. So I'm leaving the format as-is except for the directory structure changes. The distinction also serves as a clear separation between vanilla and MCPatcher features.
Time for a progress update. I put in a ton of hours over the weekend and I'm happy to report that all major features are working again. Fortunately 13w25a was only a minor setback (I want to smack whoever removed the method "bis a();" from bir.class), and I can focus on testing and bugfixing. Needless to say, backward compatibility with earlier snapshots is not an option.
Thank you very much for your time and efforts Kahr!
I am looking forward to that next version of MCPatcher you are working on.
I only caught a glimpse of this (more testing needed to make sure) but it seems Mojangs new launcher, with profiles, changes how you set how much RAM you want Minecraft to use (it seems to override MCPatcher). This is why I say more testing to make sure... either I missed something on my end, or that.
I briefly considered moving everything to json but decided against it. The only real benefit is that json allows deeper, nested structures that are hacky to represent in a flat format like .properties. palette.block.* is especially cringeworthy. Others have already covered the disadvantages of json. So I'm leaving the format as-is except for the directory structure changes. The distinction also serves as a clear separation between vanilla and MCPatcher features.
Figured this was going to be your reply and I can completely understand it. Would have made my life a little easier but eh, that's just me being lazy.
Now to decide if I'd prefer storing all my data in .mcmeta with a second step to export to .properties or if I should just write .properties files directly. I'm leaning towards the two-step process as then supporting other mod-specific files would just be a matter of altering the export step. Course that's provided I can even find the time to work on this stuff... meh.
Rollback Post to RevisionRollBack
Tis far better to be a witty fool than a foolish wit.
To post a comment, please login or register a new account.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumIt's ok, I suppose, but like mmtr1x3 said, it doesn't delete empty folders or MC Patcher specific folders (the second being a good thing really), so all anims and ctm are left sitting useless, but still intact and apart from mucking up use of HD packs in snapshot 24b, the basic pack at least worked in 24a.
If you're able to produce some kind of converter for all the ctm, anim and other .properties files, that would be enormously helpful...I'd hate to have to convert masses of .properties files if it could be done with a script. Could this be an automatic or optional function of the next patcher or is that just stating the obvious? Otherwise we're in the situation that all old packs that relied on MC Patcher, now no longer supported and able to be converted by a texture artist, will generate endless cries for help from all and sundry.
At this stage we're in your hands as to where all the MC Patcher stuff will go in the new resource pack layout. At the moment it feels like the Mojang ship set sail and left all the MC Patcher cargo on the dockside.
Many thanks for any and all help.
I'm on a mac computer and I have downloaded McPatcher and I when I click on the .jar, it won't open! I need help. I have a new MC and I use the faithful texture pack. Any help?
Download the one in the OP, not on this page.Still no ideas?
EDIT: I've tested, and it appears to be just my texture pack that's not working. Is there anything I could be doing wrong? For those who want to have a look themselves, I'll put it up to download here.
Wanted to make sure you saw these, since it seems like there has been lots of posts right after this. The Conquest thing may be a bug with the pack itself, but I thought I'd let you know.
For instance: Stone block next to a grass/dirt block.
With this it would be possible to create textures for transition blocks between common types (sand, dirt, stone, grass, gravel). Blending the transition. Would look so sweet.
-
View User Profile
-
View Posts
-
Send Message
Curse Premium-
View User Profile
-
View Posts
-
Send Message
ModeratorUltimately it's up to you, Kahr, to do what you feel is best. Just putting in my two cents.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumEh, I'm not suggesting dropping .properties files, just adding the ability to pull the same data out of the .mcmeta files. I prefer .mcmeta because JSON is a bit more flexible and 'easy' to deal with from a programming standpoint. But then I do this sort of thing for a living. Course I can also completely understand it if Kahr wouldn't want any part of messing with it. If he decides it's not worth his time, I'll probably just do what I usually do and make up a bunch of Perl scripts for converting the files for my own use.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumYou might have to put commas between the individual file names, otherwise I'd just go with '1-6' for tiles.
Hmmmm... I was diggin in there and I seen the CTM folder is properly set up, (for a moment I thought you had two folders for ctm stuff in the root folder... Lemme give it a look and I'll see what I can do!
Most of us don't understand any actual "programming", and I'm not trying to sound negative or anything, but if a game or anything could just read from a file that has simple text, an option/variable/property type thing per line, written in english, why do these actual coding languages feel the need to use this convoluted with brackets and weird characters? Like, did they make it that foreign just to make it look more complicated and thus more professional?
Either way, there was no reason for them to switch to that mcmeta , because all it's done is made kahr's job that much harder, and discouraged and confused the out of most TP artists.also, thank minecraft forum for making my last post look unintelligent and disjointed by completely removing my "bad words" instead of replacing them with asterisks or something. They could ing warn us about that before we post.....
Once again a custom texture pack converter was all but required for my own sanity, and the result is a TextureEnder.jar replacement. When I get to a certain point in my development, I need a way to convert texture packs for testing. Doing it by hand is too tedious and error-prone. So I write something automated, and then figure I might as well polish it up and release it.
This is just as well because it gives me an opportunity to change the directory structure of MCPatcher's files to better match Mojang's new layout. Everything will move into the assets/minecraft/textures folder. Some files will have new locations that make more sense (misc/watercolorX.png -> textures/colormap/water.png, for example). All this will be handled automatically for you, and I plan to add a few vanilla things Mojang left out, like default .mcmeta files for shadow.png, etc.
Of interest to modders. 1.5 abstracted tile indices into a new Icon class. 1.6 is doing something similar for texture paths. Textures and other resources are no longer referred to by Strings but by a new class I've named ResourceAddress (bis.class in 13w24b). Essentially it's a namespace plus a path. The object new ResourceAddress("minecraft", "textures/blocks/cobblestone.png") expands to "assets/minecraft/textures/blocks/cobblestone.png". All methods for loading, allocating, and switching textures have been changed to accept ResourceAddress parameters instead of Strings.
This affects artists as well. You'll always refer to textures relative to assets/minecraft in your .properties files:
As for namespaces, it's too early to tell how/if they will be used. Only the default minecraft namespace is used in vanilla. I've made some effort to accommodate other namespaces in MCPatcher, but it's not perfect so expect problems if you put anything outside of assets/minecraft.
You can use the -mcdir command line option to specify the initial Minecraft directory location so you don't have to search for it each time. The problem with your suggestion is that I have nowhere to bootstrap the last specified folder except AppData/Roaming/.minecraft. (Windows registry or anything else platform-specific is out for obvious reasons.)
At some point I want to merge MCPatcher's profiles with the profile system in the new launcher. I'll re-evaluate this request then.
I really need to update those screenshots. HD Textures was renamed to Extended HD since the game natively supports higher resolutions in 1.5. Extended HD is kind of a grab-bag of graphical enhancements that don't fit the other categories.
I briefly considered moving everything to json but decided against it. The only real benefit is that json allows deeper, nested structures that are hacky to represent in a flat format like .properties. palette.block.* is especially cringeworthy. Others have already covered the disadvantages of json. So I'm leaving the format as-is except for the directory structure changes. The distinction also serves as a clear separation between vanilla and MCPatcher features.
Thank you very much for your time and efforts Kahr!
I am looking forward to that next version of MCPatcher you are working on.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumNow to decide if I'd prefer storing all my data in .mcmeta with a second step to export to .properties or if I should just write .properties files directly. I'm leaning towards the two-step process as then supporting other mod-specific files would just be a matter of altering the export step. Course that's provided I can even find the time to work on this stuff... meh.