A quick test showed, that stained glass has still a weird ctmhandling. sometimes it gets applied and sometimes not. Vertical ctm seem to work, but when you apply for example a second propertiesfile to the same block (for top/bottom) it wont work (All CTM was tested in 1.7.4 with no problems):
I haven't been able to reproduce anything like this. Do you have sample files I could look at?
Are you using multiple render passes? That's never been supported in the inventory GUI. It's not an easy thing to fix unfortunately.
Nope, no render pass specified. What I'm specifically saying is CC not being applied to the blocks in the inventory, which I'm not sure why render passes would create an issue.
Here's a screenshot of it working fine in 14w05b with the exact same pack.
"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
Alright, I need some help. I'm trying to do a Vertical+Horizontal CTM for all faces, but for some reason it isn't doing the top and bottom faces. What am I doing wrong?
The Meaning of Life, the Universe, and Everything.
Join Date:
12/9/2011
Posts:
158
Minecraft:
SwordMasterA
Member Details
in my texture pack i am making cit "degredation" for items but I don't know what to do/put for armor, i want the armor to look broken when it is at a certain damaged value,
ex. My texture pack is called "RPG" in this scenario, for a diamond sword i would make four files (rpgswd1.png;rpgswd1.properties;rpgswd2.png;rpgswd2.properties) so what would the armor files be called?
If anyone can help I would greatly appreciate.
The Meaning of Life, the Universe, and Everything.
Join Date:
4/14/2012
Posts:
54
Member Details
I'm trying to make a grid type colormap for vines
but regardless of where the vines are placed in the world
they are colored from a single pixel at: X (biome ID) = 1, Y (block height) = 64
they look especially awful in swamps,
Nope, no render pass specified. What I'm specifically saying is CC not being applied to the blocks in the inventory, which I'm not sure why render passes would create an issue.
Alright, I need some help. I'm trying to do a Vertical+Horizontal CTM for all faces, but for some reason it isn't doing the top and bottom faces. What am I doing wrong?
By design, vertical and horizontal CTM only apply to the side faces since there's no natural up/down or left/right in the xz-plane. Symmetric 8-way CTM should work, though admittedly it's not quite the same thing.
I'm trying to make a grid type colormap for vines
but regardless of where the vines are placed in the world
they are colored from a single pixel at: X (biome ID) = 1, Y (block height) = 64
they look especially awful in swamps,
Ok. made a screenshot first to compare 1.7.4 with the newest snapshot. No properties changed btw.
The thing which is very confusing, is that for example on block 95:12 vertical-ctm is applied and the top/bottom-properties (fixed-method) isnt. On the next block (95:5) everything is fine instead.
Yes, please PM me the files if you don't mind. Also could you do another test with 4.3.2-beta2 and 1.7.4? I'm curious if it's something I changed or something Mojang changed. I did change the way properties files are loaded so that they respect the order of multiple resource packs. The odd behavior you're seeing suggests the properties files are being applied in a different order. I didn't intend to affect the behavior of a single resource pack, but it's possible something broke there.
By design, vertical and horizontal CTM only apply to the side faces since there's no natural up/down or left/right in the xz-plane. Symmetric 8-way CTM should work, though admittedly it's not quite the same thing.
Hmmm... no, that's not what I want at all. Damn. I suppose I'd be willing to settle for just vertical, although I was hoping it wouldn't come to that.
I wonder if its possible to have a second properties file for the tops and bottoms. Is there any way to make top and bottom textures connect in a straight line?
A question about renderpass layers: how badly do they hit performance?
I had an idea...
I want to do a massive repeat ctm sheet for stone, 12x12 or so. 144 tiles... it's kind of a lot. Rather than adding 1008 more tiles in for all the ores and making my pack absolutely massive (well, more than it is already) i thought i might just do up properties files for the ores that direct it to use the same repeat ctm as the stone, then do some random ctm ores to apply over the top of that with renderpass 3.
Then i realized that it may be somewhat problematic... i have no idea how rendrpass layers effect performance. I mean, this layer would be using partial transparency. Ores aren't all too common in large amounts, but i don't want to make something that most people's GPUs couldn't handle.
How would this effect performance? Is this a terrible idea?
I come back to the thread once again with two new issues.
For my vine texture, I have a 16*16 repeat sheet of cables. The textures uses renderpass 3. The vines normally repeat fine, but when they grow on the same block, the game only shows the first tile of the image over and over:
And my second issue is with logs. It is a 4*16 sheet of a beam. In the properties file I put all the metadata for the different orientations of the spruce log, and the end result was the texture being on all the logs, with random tiles missing at certain heights, along with the sideways log only repeating so much of the texture: (I apologise as the texture isn't seamless yet)
Not sure about the first issue, but with the second, are you certain you're not listing a tile in the properties that's not actually there for the game to find? I often have this issue when I number things. For instance, sometimes I'll have a total of 30 tiles and then set the property to tiles=0-30. It's a simple mistake to make. This will cause the listed (non-existent) tile to display as the default texture.
Not saying that this is what you're doing, but it's a possibility.
Rollback Post to RevisionRollBack
I used to maintain the Minecraft Forums Mod List. However, life has stepped in the way of that. Perhaps later...
I want to do a massive repeat ctm sheet for stone, 12x12 or so. 144 tiles... it's kind of a lot. Rather than adding 1008 more tiles in for all the ores and making my pack absolutely massive (well, more than it is already) i thought i might just do up properties files for the ores that direct it to use the same repeat ctm as the stone, then do some random ctm ores to apply over the top of that with renderpass 3.
Yeah, performance would definitely be a consideration there. Each stone block, of which there are many, would have to be rendered twice. I would measure your fps with and without it and maybe consider releasing it as a separate addon pack if it's too much.
---- Minecraft Crash Report ----
// Why did you do that?
Time: 22.02.14 03:19
Description: Rendering item
java.lang.ArrayIndexOutOfBoundsException: 60
at ajp.g(SourceFile:164)
at alj.f(SourceFile:613)
at bsa.a(SourceFile:1008)
at bru.a(SourceFile:110)
at bru.a(SourceFile:77)
at bru.a(SourceFile:150)
Well that was a strange bug. It was crashing in the chunk cache while rendering an anvil. Fixed for next release.
The "uv" direction is what the game uses when it asks for the block's texture, and also what CTM normally looks at. "facing" is more like where it is in the world. Pre-1.8 there was no distinction, and for non-cube blocks, the concept of "faces" is somewhat arbitrary to begin with. Since vertical CTM doesn't apply to the bottom face (and if it did it would look at the north-south or east-west neighbors, not up-down), it ends up using the default texture.
It's possible that changing the uv to match facing would fix the problem, but I don't want to force texture artists to edit a bunch of model definition files just to make CTM work. So my plan is to use both face values to try to reconstruct something that makes sense for CTM rules.
And my second issue is with logs. It is a 4*16 sheet of a beam. In the properties file I put all the metadata for the different orientations of the spruce log,
You don't actually need to do this. Just worry about the wood type (metadata 0-3) and lay out your textures as if they were in the up-down orientation. MCPatcher automatically handles the other orientations and remaps faces accordingly. This is true of stone and quartz pillars as well.
Yeah, performance would definitely be a consideration there. Each stone block, of which there are many, would have to be rendered twice. I would measure your fps with and without it and maybe consider releasing it as a separate addon pack if it's too much.
The stone would be rendered twice? I'm not sure i understand... i mean, i understand why the ores would because there are 2 layers, but why would the stone itself be rendered twice?
I'm currently using MCPatcher on 1.6.4 just for "Minecraft Forge" and "Connected Textures. But It seems like the fluids in Buildcraft tanks don't render the liquid when its connected to pipes with gates, nor do the gate icons appear (although they still function). Is there any work around for this. The moment I remove the "Connected Textures" function, the fluids and pipe icons appear correctly, so I'm guessing connected textures has to do with the Buildcraft rendering.
Can I ask, will we ever be getting a version of MCpatcher that don't inject stuff into the .jar? I ask as it seems people are getting iffy about such things these days sense Mojang has stated thay don't want people to be injecting stuff directly into the .jar for the game. Many launchers like MMC5 wont even run the game if it detects any edits to the .jar file.
Like my pack is having support for FTB, but FTB wont run at all if you touch the .jar so nothing from MCpatcher can be used. Such is just highly frustrating.
Can I ask, will we ever be getting a version of MCpatcher that don't inject stuff into the .jar? I ask as it seems people are getting iffy about such things these days sense Mojang has stated thay don't want people to be injecting stuff directly into the .jar for the game. Many launchers like MMC5 wont even run the game if it detects any edits to the .jar file.
Like my pack is having support for FTB, but FTB wont run at all if you touch the .jar so nothing from MCpatcher can be used. Such is just highly frustrating.
Is it really that hard to make a tweaker that does on-launch injection?
The stone would be rendered twice? I'm not sure i understand... i mean, i understand why the ores would because there are 2 layers, but why would the stone itself be rendered twice?
is there a way that you can add a feature that makes the texture of baby mobs other then the normal ones?
When 1.8 settles down, I can start thinking about new features again. Right now every new feature is just more work the next time Mojang pulls the rug out from under everyone again.
I'm currently using MCPatcher on 1.6.4 just for "Minecraft Forge" and "Connected Textures. But It seems like the fluids in Buildcraft tanks don't render the liquid when its connected to pipes with gates, nor do the gate icons appear (although they still function). Is there any work around for this. The moment I remove the "Connected Textures" function, the fluids and pipe icons appear correctly, so I'm guessing connected textures has to do with the Buildcraft rendering.
I've fixed a number of forge-related bugs lately that were causing problems like this, so there's a good chance it will work in the next release.
Get a confusing issue with the custom compass/dial-animation.
I applied a custom compass (with more than 2 layers) to my pack which works fantastic. but when i put it in an itemframe, the custom animation disappears and the vanilla-compass is rendered instead.
Fixed for next release.
The outputFrames option should create a file called custom_<clock,compass>.png in the .minecraft folder. There is a problem where the red/blue channels are swapped, which I've already fixed, but that shouldn't prevent the file from being written altogether. If you have set a custom game directory in the launcher it may have ended up there, however.
Mojang has stated thay don't want people to be injecting stuff directly into the .jar for the game. Many launchers like MMC5 wont even run the game if it detects any edits to the .jar file.
Has Mojang actually stated this or are people just inferring it from something else?
The vanilla launcher does run modified jars, so I don't feel any obligation to go out of my way for a third-party launcher that doesn't.
Are you using multiple render passes? That's never been supported in the inventory GUI. It's not an easy thing to fix unfortunately.
I haven't been able to reproduce anything like this. Do you have sample files I could look at?
I'm not sure what you mean by blocks with no actual metadata. An example file would probably help here too.
Turns out to be a case where Forge and MCPatcher both modify the exact same piece of code, a very tricky bug to track down. Fixed for next release.
-
View User Profile
-
View Posts
-
Send Message
Retired StaffNope, no render pass specified. What I'm specifically saying is CC not being applied to the blocks in the inventory, which I'm not sure why render passes would create an issue.
Here's a screenshot of it working fine in 14w05b with the exact same pack.
"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
Also check me out on:
WordPress, Etsy, and Spore.
ex. My texture pack is called "RPG" in this scenario, for a diamond sword i would make four files (rpgswd1.png;rpgswd1.properties;rpgswd2.png;rpgswd2.properties) so what would the armor files be called?
If anyone can help I would greatly appreciate.
but regardless of where the vines are placed in the world
they are colored from a single pixel at: X (biome ID) = 1, Y (block height) = 64
they look especially awful in swamps,
here are the details:
wanted colormap:
colormap for testing: (see green pixel)
assets\minecraft\mcpatcher\colormap\vine.properties file contents:
assets\minecraft\mcpatcher\color.properties file contents:
please try to fix
Gotcha. I have some ideas, I'll take a look.
By design, vertical and horizontal CTM only apply to the side faces since there's no natural up/down or left/right in the xz-plane. Symmetric 8-way CTM should work, though admittedly it's not quite the same thing.
Bug fixed.
Yes, please PM me the files if you don't mind. Also could you do another test with 4.3.2-beta2 and 1.7.4? I'm curious if it's something I changed or something Mojang changed. I did change the way properties files are loaded so that they respect the order of multiple resource packs. The odd behavior you're seeing suggests the properties files are being applied in a different order. I didn't intend to affect the behavior of a single resource pack, but it's possible something broke there.
Hmmm... no, that's not what I want at all. Damn. I suppose I'd be willing to settle for just vertical, although I was hoping it wouldn't come to that.
I wonder if its possible to have a second properties file for the tops and bottoms. Is there any way to make top and bottom textures connect in a straight line?
Also check me out on:
WordPress, Etsy, and Spore.
-
View User Profile
-
View Posts
-
Send Message
Retired StaffI had an idea...
I want to do a massive repeat ctm sheet for stone, 12x12 or so. 144 tiles... it's kind of a lot. Rather than adding 1008 more tiles in for all the ores and making my pack absolutely massive (well, more than it is already) i thought i might just do up properties files for the ores that direct it to use the same repeat ctm as the stone, then do some random ctm ores to apply over the top of that with renderpass 3.
Then i realized that it may be somewhat problematic... i have no idea how rendrpass layers effect performance. I mean, this layer would be using partial transparency. Ores aren't all too common in large amounts, but i don't want to make something that most people's GPUs couldn't handle.
How would this effect performance? Is this a terrible idea?
I made a bug report but the Mekanism developer said it is a "MCPatcher issue": https://github.com/a...ism/issues/1077
I'm using the latest MCPatcher with 1.6.4 + Forge 965.
EzerArch.com | Armourer's Workshop Skins | MCHeli Content Pack Addons | Resource Packs | YouTube | G+ | Twitter
connected texture for sugar canes works on patched 1.7.4 but not on a patched 14w07a
[edit]
more bugs:
1. ferns are colored by the vanilla colormap instead of the specified one.
2. random textures for double plants are ignored
both things again works fine on patched 1.7.4 but not on a patched 14w07a
-
View User Profile
-
View Posts
-
Send Message
Retired StaffNot sure about the first issue, but with the second, are you certain you're not listing a tile in the properties that's not actually there for the game to find? I often have this issue when I number things. For instance, sometimes I'll have a total of 30 tiles and then set the property to tiles=0-30. It's a simple mistake to make. This will cause the listed (non-existent) tile to display as the default texture.
Not saying that this is what you're doing, but it's a possibility.
Currently, no, but I'll see what I can do.
Yeah, performance would definitely be a consideration there. Each stone block, of which there are many, would have to be rendered twice. I would measure your fps with and without it and maybe consider releasing it as a separate addon pack if it's too much.
Well that was a strange bug. It was crashing in the chunk cache while rendering an anvil. Fixed for next release.
Turns out to be the same bug that Mr_Oyster_Meister reported with Thermal Expansion. Glad I was finally able to track that one down.
Tentatively fixed. Read on if you want the gory details of this tricky problem.
The root cause of this is in the model definition file sugarcane.json:
{ "type": "plane", "from": [ 0, 0, 8 ], "to": [ 16, 16, 8 ], "uv": [ 0, 0, 16, 16, "down" ], "facing": "south", "tint": true, "rotation": [ 0, 45, 0 ], "cull": false },The "uv" direction is what the game uses when it asks for the block's texture, and also what CTM normally looks at. "facing" is more like where it is in the world. Pre-1.8 there was no distinction, and for non-cube blocks, the concept of "faces" is somewhat arbitrary to begin with. Since vertical CTM doesn't apply to the bottom face (and if it did it would look at the north-south or east-west neighbors, not up-down), it ends up using the default texture.
It's possible that changing the uv to match facing would fix the problem, but I don't want to force texture artists to edit a bunch of model definition files just to make CTM work. So my plan is to use both face values to try to reconstruct something that makes sense for CTM rules.
Both fixed.
You don't actually need to do this. Just worry about the wood type (metadata 0-3) and lay out your textures as if they were in the up-down orientation. MCPatcher automatically handles the other orientations and remaps faces accordingly. This is true of stone and quartz pillars as well.
-
View User Profile
-
View Posts
-
Send Message
Retired StaffThe stone would be rendered twice? I'm not sure i understand... i mean, i understand why the ores would because there are 2 layers, but why would the stone itself be rendered twice?
is there a way that you can add a feature that makes the texture of baby mobs other then the normal ones?
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumMods I work on and maintain:
TabbyChat | Mine Little Pony
My Blog
-
View User Profile
-
View Posts
-
Send Message
Retired StaffLike my pack is having support for FTB, but FTB wont run at all if you touch the .jar so nothing from MCpatcher can be used. Such is just highly frustrating.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumIs it really that hard to make a tweaker that does on-launch injection?
Mods I work on and maintain:
TabbyChat | Mine Little Pony
My Blog
You're right. I misread.
When 1.8 settles down, I can start thinking about new features again. Right now every new feature is just more work the next time Mojang pulls the rug out from under everyone again.
I'm looking into it. I think it is being applied, but the order of application is indeterminate if they have the same filename.
This should be fixed in 4.3.2-beta2. Could you confirm?
xc is EntitySkeleton and xq is EntityPlayer. I'd say it's MC-38077. Is your server running the MobDisguise plugin mentioned in the comments?
I've fixed a number of forge-related bugs lately that were causing problems like this, so there's a good chance it will work in the next release.
Fixed for next release.
The outputFrames option should create a file called custom_<clock,compass>.png in the .minecraft folder. There is a problem where the red/blue channels are swapped, which I've already fixed, but that shouldn't prevent the file from being written altogether. If you have set a custom game directory in the launcher it may have ended up there, however.
Has Mojang actually stated this or are people just inferring it from something else?
The vanilla launcher does run modified jars, so I don't feel any obligation to go out of my way for a third-party launcher that doesn't.