Just wondering, but is it possible to make each face on a block different? If so, how do I do this and what do I name each block face? If this is not possible right now, can you add this feature later? I guess each face could be named something like enchantment_table_north, enchantment_table_south, etc.
Just wondering, but is it possible to make each face on a block different? If so, how do I do this and what do I name each block face? If this is not possible right now, can you add this feature later? I guess each face could be named something like enchantment_table_north, enchantment_table_south, etc.
This is possible for most blocks via the Connected Textures Mod. See the "Information for Texture Pack Authors" fold in the OP for more information on how to set up your folders, file names, and .config files.
Does this happen only when mipmapping is turned on? Mojang's implementation of mipmaps leaves a lot to be desired, and I suspect they might just be throwing away pixels with a low alpha value.
This happens in vanilla, without mipmaps, with the default texture pack as well, as a result of the rendering engine(?). This used to happen at any distance from the player, now it is about 20-60 blocks, depending on if you are looking at the texture or not. Yes, anything under 50% opacity for blocks will be rendered selectively like this.
Ah! Great stuff! I wasn't sure if I was doing something wrong when trying out the last download as lighting on trees was still borked, but I read you as saying it was fixed.
Does this happen only when mipmapping is turned on? Mojang's implementation of mipmaps leaves a lot to be desired, and I suspect they might just be throwing away pixels with a low alpha value.
Well I just checked again in your latest beta and the w39b snapshot, it appears to be happening with mipmapping on or off and with anisotropic filtering on or off as well. So basically it seems to be happening no matter what settings I use (I also checked all the lighting types, none made any sort of difference). I also noticed that it's not actually a specific distance either, I checked various distances and flying up and down (vertically) made the betterglass layer flash in and out, seemingly randomly, not at any specific height or distance as far as I could tell (although if the transition lagged behind at all it might've been happening more specifically than I noticed)
I can confirm the problem only occurs when mipmaps are enabled. Soartex water has low alpha values, so it disappears pretty often, unfortunately.
Another request. If there are a number of people experiencing this, it may be important. Would it be possible to determine the offset of bolded font? Minecraft renders bold by adding a second text layer with an offset, but because soartex font is thinner than default, the two layers separate.
Actually, it happens seemingly no matter what options are selected. Here's a Mojira issue about it. It used to affect rain and GUI, but now it just affects blocks, triggered and fixed based on a large number of odd factors.
The bold issue in that menu can be fixed. Try adding this to your .lang file if you have one for your pack:
Which will remove just the "bold" effect. If the .lang file is older, don't worry, just add those lines. The .lang files work similar in a way to resource packs in general or like character usage, Minecraft knows where to get something if it isn't all there. You can chop out a majority of the .lang files and Minecraft doesn't even care, it finds all the names from the original .lang file in the .jar.
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
I've got this little bug with 4.3.0-beta2: skyboxes only render partially at render distance 4 or 5 basically leaving huge triangular "windows" in the sky. At distance 6 the problem seems to disappear.
What "custom potion partcicls" mean?
I mean, how can I use it, add what does it do?
Also, mcpatcher will ever support using random arrow texture for the model? (Arrow1.png arrow2.png etc)
And door/snow cover block ctm?
Potion colors for each potion type can be customized in color.properties. The custom colors are applied to the particle effects that appear around players too.
No plans for random arrow textures, and I don't know what "door/snow cover block ctm" is.
By the way, animated CTM textures cause a crash. I have an animated random horizontal CTM nether bookshelf that trips the game up.
There is an error in your mcmeta files. In 80.png.mcmeta and 112.png.mcmeta, you have index 1, 2, 3, 4. Index is 0-based, so it should be 0, 1, 2, 3. The fact that it's crashing instead of reporting the error is probably Mojang's fault, so try making the same error in a non-CTM texture and see if it crashes without MCPatcher. If so, file a bug report in Atlassian about it.
Would it make sense, or be possible, to have an exemption list of textures from Mojang's mipmapping? I'd like to disable the mipmapping on the splash screen, options background, font and glass.
Not that this has much to do with MCPatcher, but I've also noticed Mojang's mipmapping turns tall grass edges black. Anyone else having problems like this?
Yes, MCPatcher's mipmapping implementation dealt with these problems, but shoehorning just those bits of it into Mojang's code isn't feasible.
So again, I'd rather people file bug reports for stuff like this. In general, if it's a legitimate problem that you can reproduce without MCPatcher, it's better that Mojang fix it themselves.
Well I just checked again in your latest beta and the w39b snapshot, it appears to be happening with mipmapping on or off and with anisotropic filtering on or off as well. So basically it seems to be happening no matter what settings I use (I also checked all the lighting types, none made any sort of difference).
Mojang has been tweaking the min-alpha threshold in the last few snapshots. I think it went from 0.1 to 0.5, then back to 0.1, and I don't know what it is now. I suspect they're doing it to try to fix the black outline problem. Trust me, I went down that road myself and it's not going to work.
I have a nother question to do with random mobs. I would love to make my wolf textures to spawn in different biomes with help of mob.properties but i wouldn't like if they would spawn undergrond(if that is even posible) couse i dont know the how the heights go and am asking you if there is anywhere any information about hights or anything, hope you understand my wierdly asked question ~ Thank you!
Just remembered, i have one more question In mob.properties can i unite weights and biomes ?
like this:
skins.1=2-6
weights.1=9 7 5 3 10
biomes.1=Forest Taiga
minHeight.1=55
maxHight.1=85
or like this:
skins.1=2-6
weights.1=9 7 5 3 10
minHeight.1=55
maxHight.1=85
skins.1=2-6
biomes.1=Forest Taiga
minHeight.1=55
maxHight.1=85
or any other?
The height option doesn't dictate whether a mob will spawn at that given height, it denotes at what height the texture will be applied. That's all randomobs really does, it doesn't have any control over the spawn algorithms, it just applies a new texture to the mob depending on the defined conditions. The heights, also, can be used together with weight and biome conditions, there's no real reason to keep them separate unless you're daisy-chaining properties files for a complex purpose. Your first example is probably the best approach for using those conditions together.
It's also not really necessary to use the heights for everything unless you specifically want a texture to be applied at a certain height, like if you want pure white wolves to occur on high taiga mountains, or black creepers to occur very deep underground. Leaving the heights out just has that texture occur across the whole biome that's defined, if one is defined at all.
I'm getting some really crazy issues with this. Like, random mobs glitching out; specifically the mobs jump through loads of different textures every other tick; not even the correct textures (i.e. sheep using pig skin, etc.). Also, on my 128 pack, and sphax's and misa's, the terrain blocks completely disappear. When I load a world, I can see nothing but the mobs and particle effects.
However, when I turned my render chunks down to 6, and turned off mipmapping and anistropic filtering, everything showed up. Then I could turn on mipmapping with no problems. Unfortunately, I can't get this fix to work consistently.
I'm on OS 10.7.5 with an ATI Radeon HD 2400 XT 128 MB graphics card, if that helps at all.
So i have some more problems with mob.properties! I am really bad at codes and stuff like that or am just dumb. Anyways the plan at the first place was to make different kinds of wolves spawning on different biomes. I don't know now if that is even posible right now with random mobs and prbably i thought wrong that it is or really is posible and i don't know hot to make it.
First the wolf.properties didn't worked but i realised why it didn't i putted wolf.properties file to /mob/wolf/wolf.properties and instead it should be in /mob/wolf.properties.
here is the wolf.properties file i made. I just need someone that understands codes a lot better than me and tell me about my stupidity and what i did wrong and if wolves can be spawned in different biomes.
Aside from that it looks fine. Now I don't know if it changed for the 1.7 version, but also the wolf.properties file typically would go in the wolf folder. The whole path under your resource pack would be: assets\minecraft\mcpatcher\mob\wolf\wolf.properties, but if it works outside of the folder then no biggie.
Now, like I said in my previous post, the Randomobs mod doesn't affect any actual spawning algorithm or code. It only changes the look of a mob, depending on the conditions defined in the properties file. It's not gonna make mooshrooms spawn in a desert or cats spawn in a taiga, it just makes a mob look different depending on the textures you have for said mob, and the conditions defined for it. So you can make zombies look like mummies in deserts, or give them miner clothes for a certain depth underground, but you can't change their spawning behavior.
Mojang has been tweaking the min-alpha threshold in the last few snapshots. I think it went from 0.1 to 0.5, then back to 0.1, and I don't know what it is now. I suspect they're doing it to try to fix the black outline problem. Trust me, I went down that road myself and it's not going to work.
Hrm, hope they come to a solution soon enough, I only use anisotropic filtering anyway so the only thing I care about is what they're going to lock the threshold at. Hope I won't have to change my glass!
Sounds logic I totaly forgot that wolfes can't spawn in deserts and so lol It would work with zombies but not with wolves. Thanks for reminding me that and thank you again for your help!
No problem, mate. :3 If ya got any more questions I'm more than happy to help.
Kahr, I just discovered that now when you're in shadow (under a tree or overhang), the renderer changes the sky fog color to a dark grey. Will we be able to change this in the future? And I apologize if this has been around awhile. I've been away, and only returned since the terrain engine update.
And do you and Misa have any sort of time frame for getting her proposed 256-column biome color map up and running? Or are we in hold mode waiting to see what Mojang's going to put out next?
Thank you for all of your hard work. It's very much appreciated.
I've been reading every single guide I can find everywhere -- and the general consensus is I have NO idea what I'm doing.
I'd like to make redstone wiring and redstone particles green. I made the mcpatcher folder in my pack-name-here/assets/minecraft folder, and then made the ColorMap folder within my mcpatcher folder. Within this I made 3 files since there was NO agreement on what filename to use -- custom_redstonecolor.png, redstonecolor.png, and redstone.png. They are all 16x1 horizontal pngs that go from dark green to light green.
When I slip the resource pack in my rp folder and patch for 1.6.4 -- booting minecraft up in that profile and entering a singleplayer map does absolutely nothing. Redstone wiring and particles are all still completely and totally default in color.
What am I doing wrong? No one on any forum can agree on whether to put it in the /misc folder or the /mcpatcher folder, nor whether to create a horizontal or vertical file, nor whether you need the .properties file (which doesn't even list redstone) or where to put it, or what filename to use for this image. I've tried every combination I can think of, even going as far as unpatching and uninstalling minecraft and re-patching a second/third/fourth time -- no dice.
Help?
Edit: I've made sure to check "custom colors" regardless of what else I try -- but I've done just that box, and every box on your list. Better grass worked -- changing the sides of my grass blocks, but redstone still hasn't budged.
Problem has been resolved! It was a matter of folder names. Thanks for your help!
Mincraft 1.6.4 (and 1.6.2 before that) and MCpatcher 4.2.2
Also check me out on:
WordPress, Etsy, and Spore.
-
View User Profile
-
View Posts
-
Send Message
Curse Premiumhttps://minecraft.curseforge.com/projects/a-minecrafters-odyssey
-
View User Profile
-
View Posts
-
Send Message
ModeratorThis happens in vanilla, without mipmaps, with the default texture pack as well, as a result of the rendering engine(?). This used to happen at any distance from the player, now it is about 20-60 blocks, depending on if you are looking at the texture or not. Yes, anything under 50% opacity for blocks will be rendered selectively like this.
Putting the CENDENT back in transcendent!
Download exe jar.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumAh! Great stuff! I wasn't sure if I was doing something wrong when trying out the last download as lighting on trees was still borked, but I read you as saying it was fixed.
Many thanks, kahr.
I mean, how can I use it, add what does it do?
Also, mcpatcher will ever support using random arrow texture for the model? (Arrow1.png arrow2.png etc)
And door/snow cover block ctm?
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumWell I just checked again in your latest beta and the w39b snapshot, it appears to be happening with mipmapping on or off and with anisotropic filtering on or off as well. So basically it seems to be happening no matter what settings I use (I also checked all the lighting types, none made any sort of difference). I also noticed that it's not actually a specific distance either, I checked various distances and flying up and down (vertically) made the betterglass layer flash in and out, seemingly randomly, not at any specific height or distance as far as I could tell (although if the transition lagged behind at all it might've been happening more specifically than I noticed)
-
View User Profile
-
View Posts
-
Send Message
Retired StaffActually, it happens seemingly no matter what options are selected. Here's a Mojira issue about it. It used to affect rain and GUI, but now it just affects blocks, triggered and fixed based on a large number of odd factors.
The bold issue in that menu can be fixed. Try adding this to your .lang file if you have one for your pack:
resourcePack.available.title=§r§nAvailable Resource Packs
resourcePack.selected.title=§r§nSelected Resource Packs
Which will remove just the "bold" effect. If the .lang file is older, don't worry, just add those lines. The .lang files work similar in a way to resource packs in general or like character usage, Minecraft knows where to get something if it isn't all there. You can chop out a majority of the .lang files and Minecraft doesn't even care, it finds all the names from the original .lang file in the .jar.
"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
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumYes, use blend=replace in the properties file, which simply replaces pixels rather than adding to them.
Potion colors for each potion type can be customized in color.properties. The custom colors are applied to the particle effects that appear around players too.
No plans for random arrow textures, and I don't know what "door/snow cover block ctm" is.
There is an error in your mcmeta files. In 80.png.mcmeta and 112.png.mcmeta, you have index 1, 2, 3, 4. Index is 0-based, so it should be 0, 1, 2, 3. The fact that it's crashing instead of reporting the error is probably Mojang's fault, so try making the same error in a non-CTM texture and see if it crashes without MCPatcher. If so, file a bug report in Atlassian about it.
Yes, MCPatcher's mipmapping implementation dealt with these problems, but shoehorning just those bits of it into Mojang's code isn't feasible.
So again, I'd rather people file bug reports for stuff like this. In general, if it's a legitimate problem that you can reproduce without MCPatcher, it's better that Mojang fix it themselves.
Mojang has been tweaking the min-alpha threshold in the last few snapshots. I think it went from 0.1 to 0.5, then back to 0.1, and I don't know what it is now. I suspect they're doing it to try to fix the black outline problem. Trust me, I went down that road myself and it's not going to work.
The height option doesn't dictate whether a mob will spawn at that given height, it denotes at what height the texture will be applied. That's all randomobs really does, it doesn't have any control over the spawn algorithms, it just applies a new texture to the mob depending on the defined conditions. The heights, also, can be used together with weight and biome conditions, there's no real reason to keep them separate unless you're daisy-chaining properties files for a complex purpose. Your first example is probably the best approach for using those conditions together.
It's also not really necessary to use the heights for everything unless you specifically want a texture to be applied at a certain height, like if you want pure white wolves to occur on high taiga mountains, or black creepers to occur very deep underground. Leaving the heights out just has that texture occur across the whole biome that's defined, if one is defined at all.
I'm getting some really crazy issues with this. Like, random mobs glitching out; specifically the mobs jump through loads of different textures every other tick; not even the correct textures (i.e. sheep using pig skin, etc.). Also, on my 128 pack, and sphax's and misa's, the terrain blocks completely disappear. When I load a world, I can see nothing but the mobs and particle effects.
However, when I turned my render chunks down to 6, and turned off mipmapping and anistropic filtering, everything showed up. Then I could turn on mipmapping with no problems. Unfortunately, I can't get this fix to work consistently.
I'm on OS 10.7.5 with an ATI Radeon HD 2400 XT 128 MB graphics card, if that helps at all.
Any ideas?
Well, I can spot a couple mistakes. For starters, skins 7 and 8 are missing the biome condition. You have it as:
When it should be this:
Aside from that it looks fine. Now I don't know if it changed for the 1.7 version, but also the wolf.properties file typically would go in the wolf folder. The whole path under your resource pack would be: assets\minecraft\mcpatcher\mob\wolf\wolf.properties, but if it works outside of the folder then no biggie.
Now, like I said in my previous post, the Randomobs mod doesn't affect any actual spawning algorithm or code. It only changes the look of a mob, depending on the conditions defined in the properties file. It's not gonna make mooshrooms spawn in a desert or cats spawn in a taiga, it just makes a mob look different depending on the textures you have for said mob, and the conditions defined for it. So you can make zombies look like mummies in deserts, or give them miner clothes for a certain depth underground, but you can't change their spawning behavior.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumHrm, hope they come to a solution soon enough, I only use anisotropic filtering anyway so the only thing I care about is what they're going to lock the threshold at. Hope I won't have to change my glass!
No problem, mate. :3 If ya got any more questions I'm more than happy to help.
And do you and Misa have any sort of time frame for getting her proposed 256-column biome color map up and running? Or are we in hold mode waiting to see what Mojang's going to put out next?
Thank you for all of your hard work. It's very much appreciated.
I've been reading every single guide I can find everywhere -- and the general consensus is I have NO idea what I'm doing.
I'd like to make redstone wiring and redstone particles green. I made the mcpatcher folder in my pack-name-here/assets/minecraft folder, and then made the ColorMap folder within my mcpatcher folder. Within this I made 3 files since there was NO agreement on what filename to use -- custom_redstonecolor.png, redstonecolor.png, and redstone.png. They are all 16x1 horizontal pngs that go from dark green to light green.
When I slip the resource pack in my rp folder and patch for 1.6.4 -- booting minecraft up in that profile and entering a singleplayer map does absolutely nothing. Redstone wiring and particles are all still completely and totally default in color.
What am I doing wrong? No one on any forum can agree on whether to put it in the /misc folder or the /mcpatcher folder, nor whether to create a horizontal or vertical file, nor whether you need the .properties file (which doesn't even list redstone) or where to put it, or what filename to use for this image. I've tried every combination I can think of, even going as far as unpatching and uninstalling minecraft and re-patching a second/third/fourth time -- no dice.
Help?
Edit: I've made sure to check "custom colors" regardless of what else I try -- but I've done just that box, and every box on your list. Better grass worked -- changing the sides of my grass blocks, but redstone still hasn't budged.
Problem has been resolved! It was a matter of folder names. Thanks for your help!