If the Biome's ID is between 0 and 255, it should fall on the existing map. I don't think biome IDs can be greater than 255 in the current system, so this shouldn't be an issue. Please feel free to correct me if I'm wrong.
For the record, the latest version of ExtraBiomesXL used biome IDs 32 - 59.
Oops, I was thinking of blocks, but it will still be harder to make the grid format compatible with mods.
Slightly off: I would like some way of specifying biome colors through properties files, so that mod biomes can use their defaults.
Hi guys!
Using a Mac and I can't patch Minecraft. Testing Minecraft got me the error message above. No changes to textures, etc upon startup either. Any thoughts on how to fix this issue? Looked everywhere else online but it seems nobody else has this issue. Thanks!
Hello everyone, Merry Cristmass, and so on)
Well, next question i have:
Running MCPatcher with forge-modified 1.6.4-enviroment (forge 965) i have problems rendering liquids of forestry and steam of thermal expansion (just can not see them). Somehow, vanilla glass and glass paneling is not transparent now. This all with Sphax texturepack - but it is not textures fault at all - turning resourcepack make it still ugly: any liquids of forestry, as example, is a glowing wierd goo......
HELP! xD
I have been using mcpatcher in my texture pack but when I started creating connected glass textures for the new stained glass it messed up all the other stained glass colors making them all white. Will there be an update to the better glass mod or the connected textures mod?
I'd say so, but it's a mod in the way Optifine is. Rather than adding stuff like items, new blocks, biomes, etc, it modifies how textures are handled. Vanilla minecraft has higher-res texture support, but MCpatcher smooths some kinks out with that, as well as allowing for customized skyboxes, potion colors, lightmaps, and more.
Hello Folks. I'm the texture pack manager for the Sanacraft server and I come to you with a bug we've been experencing since updating to 1.7.2 and hence 4.3 and 4.3.1. Before the update, I did not mess with any of our established, well working CTM Blocks. The ones I finally figured out, I just left alone. However, we're experience this glitch all of a sudden.On one side, the CTM works normally.On the other, the CTM left and right ends seem to be reversed. I've probably missed a change in the way MCPatcher reads CTM, but at the moment I am lost as to what could be causing this and how I would go about making a correction. Hopefully it won't involve renaming all 1 and 3s of the various CTM files. Should anyone wish to take a look at it, our Texturepack is available at Imperial Sanacraft. Any advice or suggestions regarding this glitch are welcomed and appreciated. Thank you for your help.
On the other, the CTM left and right ends seem to be reversed.
It's a bug with Minecraft, not MCPatcher, they fixed in in 1.7.3 or 1.7.4. Check out the bed with the default texture-- that's the most obvious place to see it in vanilla.
It's a bug with Minecraft, not MCPatcher, they fixed in in 1.7.3 or 1.7.4. Check out the bed with the default texture-- that's the most obvious place to see it in vanilla.
Thank you you very much Eleazzaar. I appreciate it. We've not made that update so I'll let them know.
Keeping getting a crash, I think it involves the ctm. I didn't use to get this, only is the 1.7.1 version
---- Minecraft Crash Report ----
// I bet Cylons wouldn't have this problem.
Time: 10/24/13 5:49 PM
Description: Registering texture
bpo: Unable to fit: minecraft:mcpatcher/ctm/35 - [Wool]/[7] - Gray/4.png - size: 32x32 - Maybe try a lowerresolution texturepack?
at bpl.c(SourceFile:56)
at bpp.b(SourceFile:203)
at bpp.a(SourceFile:90)
at bpv.a(SourceFile:72)
at bpv.a(SourceFile:61)
at bpv.a(SourceFile:52)
at azc.Z(SourceFile:455)
at azc.e(SourceFile:689)
at net.minecraft.client.main.Main.main(SourceFile:103)
A detailed walkthrough of the error, its code path and all known details is as follows:
---------------------------------------------------------------------------------------
-- Head --
Stacktrace:
at bpl.c(SourceFile:56)
at bpp.b(SourceFile:203)
at bpp.a(SourceFile:90)
-- Resource location being registered --
Details:
Resource location: minecraft:textures/atlas/blocks.png
Texture object class: bpp
Stacktrace:
at bpv.a(SourceFile:72)
at bpv.a(SourceFile:61)
at bpv.a(SourceFile:52)
at azc.Z(SourceFile:455)
-- Initialization --
Details:
Stacktrace:
at azc.e(SourceFile:689)
at net.minecraft.client.main.Main.main(SourceFile:103)
-- System Details --
Details:
Minecraft Version: 1.7.1
Operating System: Windows 7 (amd64) version 6.1
Java Version: 1.7.0_05, Oracle Corporation
Java VM Version: Java HotSpot™ 64-Bit Server VM (mixed mode), Oracle Corporation
Memory: 30819624 bytes (29 MB) / 324730880 bytes (309 MB) up to 954466304 bytes (910 MB)
JVM Flags: 2 total; -XX:HeapDumpPath=MojangTricksIntelDriversForPerformance_javaw.exe_minecraft.exe.heapdump -Xmx1G
AABB Pool Size: 0 (0 bytes; 0 MB) allocated, 0 (0 bytes; 0 MB) used
IntCache: cache: 0, tcache: 0, allocated: 0, tallocated: 0
Launched Version: 1.7.1-mcpatcher
LWJGL: 2.9.0
OpenGL: Intel Bear Lake B GL version 1.4.0 - Build 8.15.10.1912, Intel
Is Modded: Very likely; Jar signature invalidated
Type: Client (map_client.txt)
Resource Packs: [Rovan2008's DokuCraft High]
Current Language: English (US)
Profiler Position: N/A (disabled)
Vec3 Pool Size: ~~ERROR~~ NullPointerException: null
Anisotropic Filtering: Off (1)
Thanks for the tool, I can't live without my resource packs now.
I have exactly the same problem as Roven3011. Did this problem ever get resolved other than suggesting that it was the video card? I read about 10 pages past the post and did not see anything more helpful.
Comparing my error log and his it appears to be a problem when using Dokucraft (in my case megadoku light, which is 64x64) and trying to set RAM allocation above default (-Xmx1G) in the launcher profile. I can play fine using this resource pack and the default RAM (512M) (a little laggy normally, unplayable riding a horse) but when i add the java argument to my profile I get this error after hitting play in the launcher. If I remove the argument the game and resource pack loads fine. If i remove the resource pack before starting with the RAM argument then the game is ok but if I then try and add the resource pack it has all sorts of rendering issues. (such as transparent blocks are a bright orange)
Any help is appreciated. For the record my system specs are AMD FX-6300, 8GB RAM, Gigabyte HD7770OC 1GB/128bit video card
OK. So I got this working about a minute after typing the previous post - hahaha ...grrr
What I did was:
unpatch
deleted the mcpatcher profile (not sure if necessary but thought it was better to start clean)
added the argument to the unpatched, vanilla minecraft profile
patched using the editted profile as the base profile.
When I checked the mcpatcher profile, it now had the argument already checked and included and the game started fine. Hope this helps others
I get this ugly bug when I turn connected textures on:
How can I fix it?
It isnt even only the glass. The iron blocks too. (everything with CTM is bugged)
Please help me
Minecraft seems to render the brightness of glass panes differently than glass blocks. Even when both are based off the same texture the panes appear brighter. I'm new to better glass and haven't used many MCPatcher features. Is there something that can be done in MCPatcher to make glass blocks and panes of equal brightness?
I've been busy over the holidays, but here is a new release with a few bugfixes. See OP for links and list of changes. This includes preliminary compatibility with the Forge beta for 1.7.2. I suspect some features will be broken, but I won't be looking at them until Forge itself is more stable on 1.7.
I keep getting a download error when I try to test Minecraft. The error message that pops up says to check my server's proxy settings.
MCPatcher version is 4.3.1_01
OS: Windows Vista 6.0 amd64
JVM: Sun Microsystems Inc. 1.6.0_31 (64 bit)
Classpath: C:\Users\Derrick\Downloads\mcpatcher-4.3.1_01.exe
Fetching https://s3.amazonaws.com/Minecraft.Download/versions/versions.json...
Minecraft version is 1.7.4 (md5 f9ffe7e56b26d459560c48e228cc6ad4)
Done!
Fetching https://libraries.minecraft.net/tv/twitch/twitch-platform/5.12/twitch-platform-5.12-natives-windows-${arch}.jar...
com.prupe.mcpatcher.PatcherException$DownloadException: java.io.IOException: HTTP response code: 403
at com.prupe.mcpatcher.Util.fetchURL(Util.java:214)
at com.prupe.mcpatcher.launcher.version.Library.fetch(Library.java:171)
at com.prupe.mcpatcher.launcher.version.Version.fetchLibraries(Version.java:281)
at com.prupe.mcpatcher.MinecraftJar.run(MinecraftJar.java:265)
at com.prupe.mcpatcher.MainForm$14$1.runImpl(MainForm.java:398)
at com.prupe.mcpatcher.MainForm$UIWorker.run(MainForm.java:1066)
Caused by: java.io.IOException: HTTP response code: 403
at com.prupe.mcpatcher.Util.fetchURL(Util.java:189)
... 5 more
(The forum said my post was too long, so I deleted a great deal of the middle of the log. I figured the informaition you needed was at the end.)
I've been busy over the holidays, but here is a new release with a few bugfixes. See OP for links and list of changes. This includes preliminary compatibility with the Forge beta for 1.7.2. I suspect some features will be broken, but I won't be looking at them until Forge itself is more stable on 1.7.
Glad to see you're back, smooth posting an update on 1/1
I'm not sure if you saw it (it was right after your last log-in) but I posted something a few pages back:
For now though I'll probably continue with the conversion to renderPass=0 for 1.7 so that folks will still get my pack with minimal issues.
How about render pass 1?
This was my stained glass CTM with pass 3:
This is with pass 1:
So it's working alright, but still has backface culling (which I didn't want, why I was trying to use pass 3). Methinks maybe Kahr should scrap the renderPass feature, possibly just re-adding removal of backface culling (and possible blending modes?) using modified versions of the new rendering code.
Bug report! Non-metadata (or metadata 0 blocks) work as intended, however any blocks with non-0-metadata will not cause adjacent faces (such as for glass) to not be inter-block culled as they should. Shown:
Note the difference between the regular oak log, and sideways log. This causes darker textures and z-fighting.
This bug can also be exploited to bring up this idea again:
innerSeams that is only affected by itself, not other blocks. Basically half-way between regular CTM and current innerSeams implementation, allows innerSeams, but will still connect to other of the same blocks even if those faces are covered (as demonstrated in the picture above).
For custom colors, can fixed metadata color specifications be added in 1 block file? For instance, the stained glass recoloring I just did needs 16 .properties files, each with only 2 lines inside, with the name based on block and metadata (like stained_glass:0.properties). This was a pain to initially create.
I'd like it instead if I could use 1 file (say, stained_glass.properties) in which I defined all colors for the metadata, like instead of color=EFFABA, I did
This would make custom colors stuff with the MC palette (wool, stained clay, stained glass) much easier to work with, and not need as many files. Then, going from one to another, just rename 1 file (instead of 16) and the colors are there to edit as necessary. (EDIT: something else I'd find useful related to this is connect=metadata, which would be a connect method for only the same block with the same metadata, which would prevent different different colors of stained glass from connecting, and also glass panes of the same color to those blocks. perfect for when block connects multiple metadatas and tile connects multiple blocks.)
One thing I'd like is a new "base" attribute, dependsOn, which allows adds a safeguard against broken dependencies. For instance, what happens with my stained glass CTM (that is intended to be recolored by custom colors) when the game is loaded without custom colors enabled? This:
The CTM is loaded, despite the fact that it is intended to be recolored. With the dependsOn features, I would add "dependsOn=customColors" to prevent this issue. Other values would be betterGlass, MC:1.7.4, patcher:4.3.1
If all of the parts of dependsOn value are not met, the .properties file is ignored. This would allow you to make textures that are broken/unwanted in previous versions of Minecraft or MCpatcher, such as bugs that exist below certain versions, or new features that only exist in above a certain version. This feature would be more useful in the future.
Last feature request for now, most likely will have to wait for MCP, but here it is: New feature set, NoMoreIcons (NMI). Makes every block or entity that has a world model able to use that (instead of an icon) in the inventory, dropped on the ground, and in item frames. This inludes, but is not limited to:
hoppers
brewing stand
doors
bed
signs
mob heads
boats/minecarts
torches (makes them 3D)
redstone stuff (repeaters, comparators)
mob eggs (displays the mob they spawn)
etc.
High-res packs screenshot (or make 3D representations of) some of these, and standard-res packs have to try and make something that kinda "looks" like it, or use a cleverly-lazily edited from of their block textures. It not only requires less work on the artists part, but also looks better. It's kind of odd that some of these items require icons, while others don't. You could even spawn cake (block 92) in your inventory (so it uses the model) in previous versions (seems it won't let you in 1.7.4), so I'm not sure how much of a challenge making this will be. NMI could also be a new subset of features for CIT. A .properties file (nmi.properties) or a new attribute in cit.properties to define which things use block models instead of item icons.
A bug and some features+discussion, but I'd say the most important are the metadata issue with glass, and the dependsOn feature (as shown in the screenshot) that will not use certain extended textures (such as CTM, custom colors, CIT, etc.) if a specified feature is available. I think this is a needed feature now that there are multiple feature subsets of MCpatcher that can interconnect.
An addendum to this I just thought of would be making dependsOn have the ability to disable a feature if a specified .properties file is not loaded by the system. For instance, I could use the attribute:
To my stained glass .properties file (for CTM). If it is not present, or not loaded for some reason (custom colors not enabled, error with the file causing it not to work) then the .properties file will not be used, and will send a message to the dev console. dependsOn could also use just the .properties file name (without the path) to depend on things in the same folder. This would allow you to have one file depend on an external file (such as the example) and then have this other file depend on the previous file (which would be useful when it comes to multiple .properties files on one block).
Rollback Post to RevisionRollBack
"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
Whoops, forgot to include the fix for this bug. I've reuploaded 4.3.1_01, so just grab it again if you're having this problem. Bitbucket has some weird caching, so you might still get the old version for a few hours. The updated downloads should be exactly 2276799 (exe) or 2143167 (jar) bytes.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
Oops, I was thinking of blocks, but it will still be harder to make the grid format compatible with mods.
Slightly off: I would like some way of specifying biome colors through properties files, so that mod biomes can use their defaults.
Putting the CENDENT back in transcendent!
Hi guys!
Using a Mac and I can't patch Minecraft. Testing Minecraft got me the error message above. No changes to textures, etc upon startup either. Any thoughts on how to fix this issue? Looked everywhere else online but it seems nobody else has this issue. Thanks!
Well, next question i have:
Running MCPatcher with forge-modified 1.6.4-enviroment (forge 965) i have problems rendering liquids of forestry and steam of thermal expansion (just can not see them). Somehow, vanilla glass and glass paneling is not transparent now. This all with Sphax texturepack - but it is not textures fault at all - turning resourcepack make it still ugly: any liquids of forestry, as example, is a glowing wierd goo......
HELP! xD
Hello Folks. I'm the texture pack manager for the Sanacraft server and I come to you with a bug we've been experencing since updating to 1.7.2 and hence 4.3 and 4.3.1. Before the update, I did not mess with any of our established, well working CTM Blocks. The ones I finally figured out, I just left alone. However, we're experience this glitch all of a sudden.On one side, the CTM works normally.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumIt's a bug with Minecraft, not MCPatcher, they fixed in in 1.7.3 or 1.7.4. Check out the bed with the default texture-- that's the most obvious place to see it in vanilla.
• Follow Lithos on Twitter for release announcments
* Join the Lithos Discord for previews and to help
Thank you you very much Eleazzaar. I appreciate it. We've not made that update so I'll let them know.
Thanks for the tool, I can't live without my resource packs now.
I have exactly the same problem as Roven3011. Did this problem ever get resolved other than suggesting that it was the video card? I read about 10 pages past the post and did not see anything more helpful.
Comparing my error log and his it appears to be a problem when using Dokucraft (in my case megadoku light, which is 64x64) and trying to set RAM allocation above default (-Xmx1G) in the launcher profile. I can play fine using this resource pack and the default RAM (512M) (a little laggy normally, unplayable riding a horse) but when i add the java argument to my profile I get this error after hitting play in the launcher. If I remove the argument the game and resource pack loads fine. If i remove the resource pack before starting with the RAM argument then the game is ok but if I then try and add the resource pack it has all sorts of rendering issues. (such as transparent blocks are a bright orange)
Any help is appreciated. For the record my system specs are AMD FX-6300, 8GB RAM, Gigabyte HD7770OC 1GB/128bit video card
What I did was:
unpatch
deleted the mcpatcher profile (not sure if necessary but thought it was better to start clean)
added the argument to the unpatched, vanilla minecraft profile
patched using the editted profile as the base profile.
When I checked the mcpatcher profile, it now had the argument already checked and included and the game started fine. Hope this helps others
I addressed this issue a few pages back and Kahr fixed it for the next version which I am excited for.
-
View User Profile
-
View Posts
-
Send Message
Curse Premium• Follow Lithos on Twitter for release announcments
* Join the Lithos Discord for previews and to help
(The forum said my post was too long, so I deleted a great deal of the middle of the log. I figured the informaition you needed was at the end.)
-
View User Profile
-
View Posts
-
Send Message
Retired StaffGlad to see you're back, smooth posting an update on 1/1
I'm not sure if you saw it (it was right after your last log-in) but I posted something a few pages back:
How about render pass 1?
This was my stained glass CTM with pass 3:
This is with pass 1:
So it's working alright, but still has backface culling (which I didn't want, why I was trying to use pass 3). Methinks maybe Kahr should scrap the renderPass feature, possibly just re-adding removal of backface culling (and possible blending modes?) using modified versions of the new rendering code.
Bug report!
Non-metadata (or metadata 0 blocks) work as intended, however any blocks with non-0-metadata will not cause adjacent faces (such as for glass) to not be inter-block culled as they should. Shown:
Note the difference between the regular oak log, and sideways log. This causes darker textures and z-fighting.
This bug can also be exploited to bring up this idea again:
innerSeams that is only affected by itself, not other blocks. Basically half-way between regular CTM and current innerSeams implementation, allows innerSeams, but will still connect to other of the same blocks even if those faces are covered (as demonstrated in the picture above).
For custom colors, can fixed metadata color specifications be added in 1 block file? For instance, the stained glass recoloring I just did needs 16 .properties files, each with only 2 lines inside, with the name based on block and metadata (like stained_glass:0.properties). This was a pain to initially create.
I'd like it instead if I could use 1 file (say, stained_glass.properties) in which I defined all colors for the metadata, like instead of color=EFFABA, I did
color.metadata.0=ffffff
color.metadata.1=d37e00
color.metadata.2=d026d1
color.metadata.3=85b4f0
...etc...
This would make custom colors stuff with the MC palette (wool, stained clay, stained glass) much easier to work with, and not need as many files. Then, going from one to another, just rename 1 file (instead of 16) and the colors are there to edit as necessary. (EDIT: something else I'd find useful related to this is connect=metadata, which would be a connect method for only the same block with the same metadata, which would prevent different different colors of stained glass from connecting, and also glass panes of the same color to those blocks. perfect for when block connects multiple metadatas and tile connects multiple blocks.)
One thing I'd like is a new "base" attribute, dependsOn, which allows adds a safeguard against broken dependencies. For instance, what happens with my stained glass CTM (that is intended to be recolored by custom colors) when the game is loaded without custom colors enabled? This:
The CTM is loaded, despite the fact that it is intended to be recolored. With the dependsOn features, I would add "dependsOn=customColors" to prevent this issue. Other values would be betterGlass, MC:1.7.4, patcher:4.3.1
If all of the parts of dependsOn value are not met, the .properties file is ignored. This would allow you to make textures that are broken/unwanted in previous versions of Minecraft or MCpatcher, such as bugs that exist below certain versions, or new features that only exist in above a certain version. This feature would be more useful in the future.
Last feature request for now, most likely will have to wait for MCP, but here it is: New feature set, NoMoreIcons (NMI). Makes every block or entity that has a world model able to use that (instead of an icon) in the inventory, dropped on the ground, and in item frames. This inludes, but is not limited to:
- hoppers
- brewing stand
- doors
- bed
- signs
- mob heads
- boats/minecarts
- torches (makes them 3D)
- redstone stuff (repeaters, comparators)
- mob eggs (displays the mob they spawn)
- etc.
High-res packs screenshot (or make 3D representations of) some of these, and standard-res packs have to try and make something that kinda "looks" like it, or use a cleverly-lazily edited from of their block textures. It not only requires less work on the artists part, but also looks better. It's kind of odd that some of these items require icons, while others don't. You could even spawn cake (block 92) in your inventory (so it uses the model) in previous versions (seems it won't let you in 1.7.4), so I'm not sure how much of a challenge making this will be. NMI could also be a new subset of features for CIT. A .properties file (nmi.properties) or a new attribute in cit.properties to define which things use block models instead of item icons.A bug and some features+discussion, but I'd say the most important are the metadata issue with glass, and the dependsOn feature (as shown in the screenshot) that will not use certain extended textures (such as CTM, custom colors, CIT, etc.) if a specified feature is available. I think this is a needed feature now that there are multiple feature subsets of MCpatcher that can interconnect.
An addendum to this I just thought of would be making dependsOn have the ability to disable a feature if a specified .properties file is not loaded by the system. For instance, I could use the attribute:
To my stained glass .properties file (for CTM). If it is not present, or not loaded for some reason (custom colors not enabled, error with the file causing it not to work) then the .properties file will not be used, and will send a message to the dev console. dependsOn could also use just the .properties file name (without the path) to depend on things in the same folder. This would allow you to have one file depend on an external file (such as the example) and then have this other file depend on the previous file (which would be useful when it comes to multiple .properties files on one block).
"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
Whoops, forgot to include the fix for this bug. I've reuploaded 4.3.1_01, so just grab it again if you're having this problem. Bitbucket has some weird caching, so you might still get the old version for a few hours. The updated downloads should be exactly 2276799 (exe) or 2143167 (jar) bytes.