Is it possible, when using random ctm, to make one specific tile cover all faces of the block when it is picked?
For some perspective, here's what i'm doing: My pack is steampunk-apocalyptic themed with a lot of surrealistic elements added in.
I want to make my redwood trees (biome specific spruce for whatever that biome with podzol is) well, i want these trees to have rusty metal rings around them occasionally covering up cracks, as though the tree split and the metal rings are bracing them back together. Of course, i don't want these appearing on every block that makes up the tree, that would just look bad. But very rarely appearing on a few trees here and there i think would be a nice touch.
Of course to make a metal ring around a tree with random ctm would require making that specific tile chosen effect all sides of the tree at once. Can i do it?
Would putting faces=sides in the file give the effect you wanted?
Would putting faces=sides in the file give the effect you wanted?
No... since this effecting logs, it basically already uses that property.
Also, anyone know how to remove biome coloring from the mega taiga biome? The green color overlay isn't doing my leaves any good. I have foliagecolor.png grayed out to no effect.
Of course to make a metal ring around a tree with random ctm would require making that specific tile chosen effect all sides of the tree at once. Can i do it?
Would putting faces=sides in the file give the effect you wanted?
What he wants to add is symmetry=all. He should already have faces=sides.
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 was going to suggest that, but I thought it might affect the log tops as well.
Nope. faces=sides will prevent that, because those are the only faces that the .properties files is allowed to influence.
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 can't seem to get different metadata of the same block to connect together. For instance I have several variants of sandstone under different metadata that all have the same top CTM method texture and using connect=tile, block, or material doesn't connect them together at all. I just wondered if I missed something, it's an issue with 1.7.2 or if this is an intentional change?
Is it possible, when using random ctm, to make one specific tile cover all faces of the block when it is picked?
Even if you did that, it would look weird. The trees are often 2x2. I'm no expert, but i don't see how you could make the band go all the way around a 2x2, but not every other block at that level.
I'm having trouble getting a texture to apply specifically to the new non-grass-growing dirt (metadata 1). It worked with a previous version of MCPatcher, but now anything i try applies to all dirt blocks, even if i put in for instance the nonexistent metadata 3.
I am having a lot of trouble with the extended hd allowing hd font. I am using a 64x font resource pack and it simply doesn't work. I made sure that Extended HD is checked and "Enable HD fonts" is checked under the options tab. It works when I run "Test Minecraft" just fine, but when I try to do it on actual minecraft, the font is all spaced out weird.
Here is the patch I applied:
__Base
added assets/minecraft/mcpatcher/blank.png
added com/prupe/mcpatcher/Config$FileEntry.class
added com/prupe/mcpatcher/Config$ModEntry.class
added com/prupe/mcpatcher/Config$ProfileEntry.class
added com/prupe/mcpatcher/Config$VersionEntry.class
added com/prupe/mcpatcher/Config.class
added com/prupe/mcpatcher/JsonUtils.class
added com/prupe/mcpatcher/MAL.class
added com/prupe/mcpatcher/MCLogger$1$1.class
added com/prupe/mcpatcher/MCLogger$1.class
added com/prupe/mcpatcher/MCLogger$ErrorLevel.class
added com/prupe/mcpatcher/MCLogger.class
added com/prupe/mcpatcher/MCPatcherUtils.class
added com/prupe/mcpatcher/ProfilerAPI.class
GameSettings (azw.class)
[1] use options.<version>.txt if present
Minecraft (azd.class)
[1] MCPatcherUtils.setMinecraft(this)
Profiler (ov.class)
__TexturePackBase
added com/prupe/mcpatcher/BlendMethod.class
added com/prupe/mcpatcher/InputHandler.class
added com/prupe/mcpatcher/TexturePackAPI$1.class
added com/prupe/mcpatcher/TexturePackAPI.class
added com/prupe/mcpatcher/TexturePackChangeHandler$1.class
added com/prupe/mcpatcher/TexturePackChangeHandler.class
added com/prupe/mcpatcher/WeightedIndex$1.class
added com/prupe/mcpatcher/WeightedIndex$2.class
added com/prupe/mcpatcher/WeightedIndex.class
AbstractResourcePack (bqf.class)
[1] make field file public
AbstractTexture (bph.class)
[1] insert method finalize ()V
[1] insert method unloadGLTexture ()V
[1] make field glTextureId public
DefaultResourcePack (bqg.class)
[1] make field file public
DynamicTexture (bpi.class)
FallbackResourceManager (bqh.class)
[1] make field resourcePacks public
FileResourcePack (bqi.class)
[1] make field zipFile public
FolderResourcePack (bqj.class)
Icon (ps.class)
Minecraft (azd.class)
[1] check for texture pack change
[1] init texture pack handlers on startup
ReloadableResourceManager (bqm.class)
Resource (bqn.class)
ResourceLocation (bqo.class)
ResourceManager (bqp.class)
ResourcePack (bqr.class)
SimpleReloadableResourceManager (bqx.class)
[1] after texture pack change
[1] before texture pack change
[1] make field namespaceMap public
SimpleTexture (bpm.class)
TextureAtlas (bpr.class)
TextureManager (bpx.class)
[1] make field texturesByName public
TextureUtil (bqa.class)
ThreadDownloadImageData (bpj.class)
Extended HD
added com/prupe/mcpatcher/hd/CustomAnimation$1.class
added com/prupe/mcpatcher/hd/CustomAnimation.class
added com/prupe/mcpatcher/hd/FancyDial$FBO.class
added com/prupe/mcpatcher/hd/FancyDial$Layer.class
added com/prupe/mcpatcher/hd/FancyDial.class
added com/prupe/mcpatcher/hd/FontUtils$1.class
added com/prupe/mcpatcher/hd/FontUtils.class
added com/prupe/mcpatcher/hd/MipmapHelper.class
AbstractTexture (bph.class)
FontRenderer (bag.class)
[1] 4.0f -> charWidthf[32]
[1] FontUtils.computeCharWidthsf on init
[1] insert field charWidthf [F
[1] insert field defaultFont LResourceLocation;
[1] insert field fontAdj F
[1] insert field hdFont LResourceLocation;
[1] insert field isHD Z
[1] make field fontResource not final
[1] make method readFontData public
[1] override font name
[1] override getStringWidth
[1] override unicode font name
[4] undo font adjustment
[1] use charWidthf instead of charWidth
Icon (ps.class)
Resource (bqn.class)
ResourceLocation (bqo.class)
SimpleResource (bqz.class)
Texture (bpi.class)
TextureAtlas (bpr.class)
[1] make field animations public
TextureAtlasSprite (bpv.class)
TextureClock (bqd.class)
[1] make field currentAngle public
[1] render custom clock
[1] setup custom clock
TextureCompass (bqe.class)
[1] render custom compass
[1] setup custom compass
TextureManager (bpx.class)
[1] update custom animations
TextureObject (bpz.class)
If anyone can help or needs more details to help me, EVERYTHING is appreciated!
EDIT: Well-- actually it works for the dirt, but any tall grass or ferns planted on the dirt:1 uses that dirt texture too--biome colored. Saplings, flowers, and double tall ferns or grass work as expected.
Just wondering, are custom skies with the blending mode set to replace supposed to just disappear at the fade out time? They currently don't seem to fade out at all, they just immediately disappear which really looks peculiar and it's sorta stopping me from wanting to use it even though it looks the best.
I see an ability convert texture pack, what's that for? Does it let me turn new textures into old or turn old textures into new?
Old formats into new. There's a couple of updates where packs made for previous versions stop working. 1.4 and below > 1.5 > 1.6 and above require conversion as they're three separate formats.
Something changed with the minecraft launcher a few days ago, which means it isn't looking for things in quite the same directories as before. For me, the solution to this was to copy my launcher_profiles.json and mcpatcher.json files in .minecraft into assets\virtual, after which the fonts return to looking normal. (If this is your problem, your client logs atm should contain an error about the json parser not finding those two files in that directory.)
Hope this helps.
I looked in assets\virtual and I couldn't find those two files. I found the solution but I lost the files because I wanted to test how they were created. I found a file in a few of my resource packs under assets\minecraft and it was called mcpatcher. It was a folder, and when I used those resource packs, hd font was loaded. I copied that folder into the same place in the resource pack that I wanted to use and it worked!
To see how that folder was created, I deleted all of my resource packs except for one without the assets\minecraft\mcpatcher folder to see if the folder would be created when I patched my minecraft. IT DID NOT. So now my solution is lost.
If anyone could tell me how this is supposed to work, that would be great.
Bug Report - MCPatcher 4.3.1 BETA, Minecraft 13w48b:
Random CTM for Iron Bars seemingly forces the rendering to change regardless of whether or not you specify any renderpass. Causes you to see both sides of the bars when looking at one side. Screenshots below:
Without CTM:
With CTM:
matchTiles=iron_bars
method=random
tiles=0-15
Rollback Post to RevisionRollBack
I used to maintain the Minecraft Forums Mod List. However, life has stepped in the way of that. Perhaps later...
Do lightmaps still work the same way they work as shown on the wiki/texture artist section? I did as said and used the top 16 rows for sunlight and the bottom 16 rows for torchlight, but it seems that the whole map is using the torchlight half--I made it a constant solid light blue, and now the whole map is just always cast in a light blue light, and torches don't make it any lighter! xD
*Note: I'm only using the 32px height, I haven't bothered with the nightvision part yet! I'm still trying to figure this one out! hehe.
This is pretty much what it looks like right now, as I hadn't changed the top much from the example yet: http://prntscr.com/299qzq
(I'm still playing with it).
Do lightmaps still work the same way they work as shown on the wiki/texture artist section? I did as said and used the top 16 rows for sunlight and the bottom 16 rows for torchlight, but it seems that the whole map is using the torchlight half--I made it a constant solid light blue, and now the whole map is just always cast in a light blue light, and torches don't make it any lighter! xD
Yes, it still works the same. I don't think you quite understand how it all works, though.
First, as you said, the top 16 rows are for sunlight. The top row is when you're deep in a cave, and the bottom row is when you're directly under the open sky. The far-right column is the light during lightning. Just to the left is daylight. The far left column is night time. Everything in-between is sunrise and sunset.
The bottom sixteen rows are light from a lightsource (not just torches). The top row is no extra light at all (light level 0), and the bottom row is basically glowstone (light level 15).
The way the game deals with light is that it looks at what the value is on three axies: time of day - sun exposure - light from a light source. It then picks whichever pixel is brightest and uses that as the light.
What's happening with your current layout, you're basically telling the game that torch light should be used all of the time regardless of any other features. Why? Because the blue you're using for the bottom 16 is always the brightest pixel. Even zero torch light (the top row of the bottom sixteen) is still "brighter" than any daylight value.
Try making the bottom sixteen a gradient with the top nearly black, and the bottom nearly white. Do the same thing for the daylight set. Now you'll begin to see variation.
Yes, it still works the same. I don't think you quite understand how it all works, though.
First, as you said, the top 16 rows are for sunlight. The top row is when you're deep in a cave, and the bottom row is when you're directly under the open sky. The far-right column is the light during lightning. Just to the left is daylight. The far left column is night time. Everything in-between is sunrise and sunset.
The bottom sixteen rows are light from a lightsource (not just torches). The top row is no extra light at all (light level 0), and the bottom row is basically glowstone (light level 15).
The way the game deals with light is that it looks at what the value is on three axies: time of day - sun exposure - light from a light source. It then picks whichever pixel is brightest and uses that as the light.
What's happening with your current layout, you're basically telling the game that torch light should be used all of the time regardless of any other features. Why? Because the blue you're using for the bottom 16 is always the brightest pixel. Even zero torch light (the top row of the bottom sixteen) is still "brighter" than any daylight value.
Try making the bottom sixteen a gradient with the top nearly black, and the bottom nearly white. Do the same thing for the daylight set. Now you'll begin to see variation.
I hope that helps you.
Wow, that makes so much more sense! This post you just wrote should be copied into the wiki ;D
Would putting faces=sides in the file give the effect you wanted?
No... since this effecting logs, it basically already uses that property.
Also, anyone know how to remove biome coloring from the mega taiga biome? The green color overlay isn't doing my leaves any good. I have foliagecolor.png grayed out to no effect.
What he wants to add is symmetry=all. He should already have faces=sides.
"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 was going to suggest that, but I thought it might affect the log tops as well.
Nope. faces=sides will prevent that, because those are the only faces that the .properties files is allowed to influence.
"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 can't seem to get different metadata of the same block to connect together. For instance I have several variants of sandstone under different metadata that all have the same top CTM method texture and using connect=tile, block, or material doesn't connect them together at all. I just wondered if I missed something, it's an issue with 1.7.2 or if this is an intentional change?
Even if you did that, it would look weird. The trees are often 2x2. I'm no expert, but i don't see how you could make the band go all the way around a 2x2, but not every other block at that level.
• Follow Lithos on Twitter for release announcments
* Join the Lithos Discord for previews and to help
Is this not correct?
Using MCPatcher 4.3 and MC 1.7.2 or 13w48b
• Follow Lithos on Twitter for release announcments
* Join the Lithos Discord for previews and to help
I am having a lot of trouble with the extended hd allowing hd font. I am using a 64x font resource pack and it simply doesn't work. I made sure that Extended HD is checked and "Enable HD fonts" is checked under the options tab. It works when I run "Test Minecraft" just fine, but when I try to do it on actual minecraft, the font is all spaced out weird.
Here is the patch I applied:
If anyone can help or needs more details to help me, EVERYTHING is appreciated!
Thanks in advance!
Thanks, that works!
EDIT: Well-- actually it works for the dirt, but any tall grass or ferns planted on the dirt:1 uses that dirt texture too--biome colored. Saplings, flowers, and double tall ferns or grass work as expected.
• Follow Lithos on Twitter for release announcments
* Join the Lithos Discord for previews and to help
I looked in assets\virtual and I couldn't find those two files. I found the solution but I lost the files because I wanted to test how they were created. I found a file in a few of my resource packs under assets\minecraft and it was called mcpatcher. It was a folder, and when I used those resource packs, hd font was loaded. I copied that folder into the same place in the resource pack that I wanted to use and it worked!
To see how that folder was created, I deleted all of my resource packs except for one without the assets\minecraft\mcpatcher folder to see if the folder would be created when I patched my minecraft. IT DID NOT. So now my solution is lost.
If anyone could tell me how this is supposed to work, that would be great.
Random CTM for Iron Bars seemingly forces the rendering to change regardless of whether or not you specify any renderpass. Causes you to see both sides of the bars when looking at one side. Screenshots below:
Without CTM:
With CTM:
Where can I find the 4.3.1 beta? Is it on the wiki or do I have to compile it myself?Found it.
http://www.minecraftforum.net/topic/1496369-13w48b-172-164-and-earlierupdate-1116-mcpatcher-hd-fix-430/page__st__9660#entry26330482
Mods I work on and maintain:
TabbyChat | Mine Little Pony
My Blog
*Note: I'm only using the 32px height, I haven't bothered with the nightvision part yet! I'm still trying to figure this one out! hehe.
This is pretty much what it looks like right now, as I hadn't changed the top much from the example yet: http://prntscr.com/299qzq
(I'm still playing with it).
First, as you said, the top 16 rows are for sunlight. The top row is when you're deep in a cave, and the bottom row is when you're directly under the open sky. The far-right column is the light during lightning. Just to the left is daylight. The far left column is night time. Everything in-between is sunrise and sunset.
The bottom sixteen rows are light from a lightsource (not just torches). The top row is no extra light at all (light level 0), and the bottom row is basically glowstone (light level 15).
The way the game deals with light is that it looks at what the value is on three axies: time of day - sun exposure - light from a light source. It then picks whichever pixel is brightest and uses that as the light.
What's happening with your current layout, you're basically telling the game that torch light should be used all of the time regardless of any other features. Why? Because the blue you're using for the bottom 16 is always the brightest pixel. Even zero torch light (the top row of the bottom sixteen) is still "brighter" than any daylight value.
Try making the bottom sixteen a gradient with the top nearly black, and the bottom nearly white. Do the same thing for the daylight set. Now you'll begin to see variation.
I hope that helps you.
Wow, that makes so much more sense! This post you just wrote should be copied into the wiki ;D