No. Are you specifying the actual BLOCK as well? Try specifying both the carpenter block ID and the tile name.
so:
matchBlocks blah blah
matchTiles stone
Oh, I see what you're saying. But carpenter's blocks take texture's from whatever block you apply to them, they don't have a useful texture of their own. So if I was able to force the stone texture onto it, it would become useless if I wanted it to look like leaves or dirt or whatever.
Bah, got matchTiles working, but it still doesn't apply the CTM to the carpenter's blocks It seems to me that if connect=tile works, this should work too...
matchTiles=
method=
connect=
The 3 listed properties of CTM all act differently.
matchTiles=<list of matching tile names>
This determines what Texture Tile(s) that the specified CTM Method should affect.
method=<certain CTM method>
This determines what type of CTM that will be applied to the block
connect=<connect type>
This is an optional property, but can be used for methods that connect to adjacent blocks. It specifies how the game should decide if two blocks should be connected.
Just because connect=tile works, that doesn't mean that CTM should work. You are just saying that you want the CTM method to connect by checking the neighboring blocks tile & checking if they are the same. If they are both using the same tile, then it applies the desired CTM method to the block/tile that was specified.
Oh, I see what you're saying. But carpenter's blocks take texture's from whatever block you apply to them, they don't have a useful texture of their own. So if I was able to force the stone texture onto it, it would become useless if I wanted it to look like leaves or dirt or whatever.
@Deonyi, this wouldn't work because MCPatcher first checks all tile-based entries then it checks block ID-based ones. The first match wins. So by having:
matchBlocks=<name of the Carpenter's block internal name or Block ID>
matchTiles=stone
you are basically saying, FIRST check if the block has the stone.png texture from the /minecraft/assests/textures/blocks folder, if there is a match, then ignore matchBlocks properties, BUT if it doesn't match then check the matchBlocks properties.
Having both really isn't necessary for what you guys are trying to do.
@Tsuarok, Carpenter's Block applys overlays to the block, so by having the default Carpenter's Block have the stone texture, it will still act the same. If you want it to look like leaves, it will change from the (now) default stone-looking-like texture to the leaves texture. (That is if you have CTM target the default Carpenter's Block TILE, if you have it target the Carpenter's Block BLOCK, then what you said about the block being useless COULD be true.) (I don't really know how it actually works, because I don't use the Carpenter's Block mod)
NOTE: On the Carpenter's Block mod page, it says that ever since version 3.1.0 of the mod (was released on 4/4/2014) that it removed MCPatcher compatibility because it appears to no longer be needed.
Oh, I see what you're saying. But carpenter's blocks take texture's from whatever block you apply to them, they don't have a useful texture of their own. So if I was able to force the stone texture onto it, it would become useless if I wanted it to look like leaves or dirt or whatever.
If you could also post your .properties file, we can also help you better. We need your .properties file if you want us to test it too & help find the problem. By posting your .properties file, we can also make sure that there is no problem with your .properties files.
That method doesn't work on newer versions of Minecraft(it only works on versions of Minecraft that still used terrain.png for block textures)
matchTiles=
method=
connect=
The 3 listed properties of CTM all act differently.
matchTiles=<list of matching tile names>
This determines what Texture Tile(s) that the specified CTM Method should affect.
method=<certain CTM method>
This determines what type of CTM that will be applied to the block
connect=<connect type>
This is an optional property, but can be used for methods that connect to adjacent blocks. It specifies how the game should decide if two blocks should be connected.
Just because connect=tile works, that doesn't mean that CTM should work. You are just saying that you want the CTM method to connect by checking the neighboring blocks tile & checking if they are the same. If they are both using the same tile, then it applies the desired CTM method to the block/tile that was specified.
Right, but if it's checking to see that the tile is the same, and it's applying the CTM method based on the tile, it seems like part of the CTM code is recognizing the applied tile (the connect=tile), while the matchTiles part is not. i.e. it has to see the applied tile to use connect=tile, but it won't apply the CTM that matches that tile. It just seems like if one property can recognize the tile other should too.
@Deonyi, this wouldn't work because MCPatcher first checks all tile-based entries then it checks block ID-based ones. The first match wins. So by having:
matchBlocks=<name of the Carpenter's block internal name or Block ID>
matchTiles=stone
you are basically saying, FIRST check if the block has the stone.png texture from the /minecraft/assests/textures/blocks folder, if there is a match, then ignore matchBlocks properties, BUT if it doesn't match then check the matchBlocks properties.
Having both really isn't necessary what you guys are trying to do.
@Tsuarok, Carpenter's Block applys overlays to the block, so by having the default Carpenter's Block have the stone texture, it will still act the same. If you want it to look like leaves, it will change from the (now) default stone-looking-like texture to the leaves texture. (That is if you have CTM target the default Carpenter's Block TILE, if you have it target the Carpenter's Block BLOCK, then what you said about the block being useless COULD be true.)
NOTE: On the Carpenter's Block mod page, it says that ever since version 3.1.0 of the mod (was released on 4/4/2014) that it removed MCPatcher compatibility because it appears to no longer be needed.
He never supported CTM, says it's not interesting to him.
From the FAQ on that page he says:
Quote
Question: I'm having issues with this mod and MCPatcher, why?
-------
Answer: Versions of this mod for MC 1.6+ offer a compatibility setting in the config file to alleviate issues with MCPatcher. MC 1.7+ appears to no longer need correction, unless I'm mistaken.. and therefore the config setting was removed.
If you could also post your .properties file, we can also help you better. We need your .properties file if you want us to test it too & help find the problem. By posting your .properties file, we can also make sure that there is no problem with your .properties files.
Edit: the above code perfectly applies the CTM method to actual stone, and connects to carpenter's blocks that have the stone texture applied, but doesn't apply the CTM method to the stone textured carpenter's block
Honestly, I didn't think I'd be able to do this at all. I was really suggesting an extension of the CTM code. But now that I've delved into it, it really seems like the combination of matchTiles and connect properties should have the desired effect.
They don't, but they do point to a possible easily coded fix: getting matchTiles to... match tiles...
Right, but if it's checking to see that the tile is the same, and it's applying the CTM method based on the tile, it seems like part of the CTM code is recognizing the applied tile (the connect=tile), while the matchTiles part is not. i.e. it has to see the applied tile to use connect=tile, but it won't apply the CTM that matches that tile. It just seems like if one property can recognize the tile other should too.
I think you are getting the connect=tile rule & the matchTiles= properties mixed up.
connect=tile is what tells CTM to check if the neighboring blocks should connect, but it just CHECKS the neighboring block's texture tiles to see if it matches the same texture that is stated in matchTiles= property.
matchTiles= is what tells CTM what texture tile to change.
tiles= is what tells CTM what texture(s) should replace the texture(s)/block(s) that are listed in the matchTiles=/matchBlocks= properties, respectively.
connect=tile is checking that the tile is the same, but it's not applying the CTM method. The part of the CTM code that is recognizing the original texture tile is the matchTile= property, connect=tile is the part that you might say is broken.
With your current .properties file, which doesn't seem like there is no problems in it, it might just be the mod that is not letting CTM work properly. Understand that, currently, CTM only supports block selection via Blockname/Block-ID, & metadata. If the tile is being stored is via Tile Entity or NBT tag, CTM will not work. (I guess, theoretically, CTM can still work via tile selection by selecting the texture that you are trying to apply CTM to(like what you're trying to do), but this hasn't worked before & isn't currently working for you now.)
Edit: the above code perfectly applies the CTM method to actual stone, and connects to carpenter's blocks that have the stone texture applied, but doesn't apply the CTM method to the stone textured carpenter's block
What do you mean by "stone textured carpenter's block" & "carpenter's block that have the stone texture applied"?
I think you are getting the connect=tile rule & the matchTiles= properties mixed up.
connect=tile is what tells CTM to check if the neighboring blocks should connect, but it just CHECKS the neighboring block's texture tiles to see if it matches the same texture that is stated in matchTiles= property.
matchTiles= is what tells CTM what texture tile to change.
tiles= is what tells CTM what texture(s) should replace the texture(s)/block(s) that are listed in the matchTiles=/matchBlocks= properties, respectively.
connect=tile is checking that the tile is the same, but it's not applying the CTM method. The part of the CTM code that is recognizing the original texture tile is the matchTile= property, connect=tile is the part that you might say is broken.
With your current .properties file, which doesn't seem like there is no problems in it, it might just be the mod that is not letting CTM work properly. Understand that, currently, CTM only supports block selection via Blockname/Block-ID, & metadata. If the tile is being stored is via Tile Entity or NBT tag, CTM will not work. (I guess, theoretically, CTM can still work via tile selection by selecting the texture that you are trying to apply CTM to(like what you're trying to do), but this hasn't worked before & isn't currently working for you now.)
What do you mean by "stone textured carpenter's block" & "carpenter's block that have the stone texture applied"?
So connect=tile is working perfectly, it's the matchTiles that I feel is behaving poorly.
But first I think I need to explain Carpenter's blocks. It is a mod that allows you to create various blocks with unique shapes. If you right-click the carpenter's block with any other block, the texture of that block is applied to the carpenter's block; so you end up with, say, a dirt block in the shape of a vertical slab.
With the above properties file for stone, I can apply a stone texture to a carpenter's block, and the connect=tile property correctly recognizes the tile (i.e. stone texture) on the carpenter's block and the surrounding stone changes it's configuration to connect to it.
However, the carpenter's block texture becomes the base stone texture, not the texture that the CTM method would give it. Since the connect=tile property is working, mcpatcher is clearly recognizing that the carpenter's block now has the stone tile, but it doesn't apply the CTM method to it as it should via the matchTiles property.
connect=tile is checking that the tile is the same, but it's not applying the CTM method. The part of the CTM code that is recognizing the original texture tile is the matchTile= property, connect=tile is the part that you might say is broken.
But first I think I need to explain Carpenter's blocks. It is a mod that allows you to create various blocks with unique shapes. If you right-click the carpenter's block with any other block, the texture of that block is applied to the carpenter's block; so you end up with, say, a dirt block in the shape of a vertical slab.
I know what Carpenter's Blocks is. I have seen Let's Play & mod reviews of it before, not to include read over the whole mod page before.
With the above properties file for stone, I can apply a stone texture to a carpenter's block, and the connect=tile property correctly recognizes the tile (i.e. stone texture) on the carpenter's block and the surrounding stone changes it's configuration to connect to it.
However, the carpenter's block texture becomes the base stone texture, not the texture that the CTM method would give it. Since the connect=tile property is working, mcpatcher is clearly recognizing that the carpenter's block now has the stone tile, but it doesn't apply the CTM method to it as it should via the matchTiles property.
1st) The CTM Method is determined by the "method=" property, not the "matchTiles=" property.
2nd) If the CTM method you have determined isn't being applied to the tile textures, then the CTM for that .properties file doesn't work, so which means that "connect=tiles" is NOT working too.
3rd) If the CTM feature of MCPatcher can correctly recognize the tile on the carpenter's block is stone, then the "matchTiles=stone" property IS WORKING FINE!
You are saying the same thing after I have told you that you're wrong, 3 times. (Not saying you're wrong about the problem you're having, I'm saying you're wrong about what might be the cause of the problem that you are having).
There are some texture loading problems for some folks that don't appear to be specific to MCPatcher. Once I can figure out why textures sometimes don't work, MCPatcher will likely work as well without adjustment.
Yes, the CTM method is NOT applying to the carpenter's block with the stone texture. But the surrounding stone treat's it like it's stone, aka, connects to it. The carpenter's block texture remains unaffected.
I know what Carpenter's Blocks is. I have seen Let's Play &amp;amp;amp;amp;amp; mod reviews of it before, not to include read over the whole mod page before.
No offense intended, you just asked what I meant about the carpenter's block with the applied texture, so I thought, to be as clear as possible, I'd just describe the mod.
1st) The CTM Method is determined by the "method=" property, not the "matchTiles=" property.
2nd) If the CTM method you have determined isn't being applied to the tile textures, then the CTM for that .properties file doesn't work, so which means that "connect=tiles" is NOT working too.
3rd) If the CTM feature of MCPatcher can correctly recognize the tile on the carpenter's block is stone, then the "matchTiles=stone" property IS WORKING FINE!
You are saying the same thing after I have told you that you're wrong, 3 times. (Not saying you're wrong about the problem you're having, I'm saying you're wrong about what might be the cause of the problem that you are having).
I know that the CTM method is determined by the method=CTM.
MatchTiles tells the CTM mod where to apply the method. It says, "put this method where this tile is." As you previously stated, connect=tile looks at the neighboring block's tile to determine whether it should connect or not.
As I'd said, the actual stone has the CTM method properly applied. Actual stone connects to the carpenter's block when the stone texture is present, indicating that connect=tiles is in fact working perfectly. i.e. actual stone behaves as if the adjacent carpenter's block is stone too. It does this when I add the connect=tile property, which I did first, before adding any matchTiles.
EDIT: This is the part where the CTM (mod, not method) recognizes the carpenter's block's inherited tile correctly
The properties file does not apply the CTM method to the carpenter's block. It gets only the base stone tile texture.
In my property file, matchTiles allows the method to be applied to stone. I originally just named the file block1; after changing the name, without adding the matchTiles property, the CTM method did not apply to anything at all (which is exactly right, there was no reference). When I added the matchTiles property, it correctly applied the CTM method to the stone blocks, but did not do likewise to the stone textured carpenter's block.
Thus, the problem lies in matchTiles
I know you told me I'm wrong 3 times. Since I'm not wrong, I've been trying to explain more thoroughly the problem.
No offense intended, you just asked what I meant about the carpenter's block with the applied texture, so I thought, to be as clear as possible, I'd just describe the mod.
Oh ok, I see why you explained it, but I didn't take any offense to it.
I know that the CTM method is determined by the method=CTM.
MatchTiles tells the CTM mod where to apply the method. It says, "put this method where this tile is." As you previously stated, connect=tile looks at the neighboring block's tile to determine whether it should connect or not.
As I'd said, the actual stone has the CTM method properly applied. Actual stone connects to the carpenter's block when the stone texture is present, indicating that connect=tiles is in fact working perfectly. i.e. actual stone behaves as if the adjacent carpenter's block is stone too. It does this when I add the connect=tile property, which I did first, before adding any matchTiles.
The properties file does not apply the CTM method to the carpenter's block. It gets only the base stone tile texture.
In my property file, matchTiles allows the method to be applied to stone. I originally just named the file block1; after changing the name, without adding the matchTiles property, the CTM method did not apply to anything at all. When I added the matchTiles property, it correctly applied the CTM method to the stone blocks, but did not do likewise to the stone textured carpenter's block.
Thus, the problem lies in matchTiles
I know you told me I'm wrong 3 times. Since I'm not wrong, I've been trying to explain more thoroughly the problem.
OOOHHH OK, I thought you were meaning something else. I'm sorry.
But I have installed Carpenter's Block with Forge(Forge Version 10.12.0.1047) & MCPatcher(MCP version 4.3.2_02) on Minecraft 1.7.2 & I haven't been able to get any method of CTM(block-based & tiled-based selection with all types of CTM Methods) to work with anything. BUT here is what I have came across:
1) The metadata= property is pointless(having it in the .properties file or not having it, doesn't affect the outcome)
2) Having matchBlocks= on either 165(the Block-ID of the Carpenter's Block) or CarpentersBlocks:blockCarpentersBlock (the Blockname of the Carpenter's Block) effects the block's appearance in the inventory, but not when placed.(When placed, the block's texture is reverted back to the default Carpenter's Block).
3) Having matchTiles= property doesn't work at all. Doesn't work on the Carpenter's Block default texture, even when selected with matchTiles, nor does it work with block textures that are applied to it.
#Code to directly select the Carpenters Block default texture
matchTiles=carpentersblocks:textures/blocks/general/quartered_frame.png
4) The method= property doesn't matter either.
5) The connect= property doesn't matter either.
The Carpenter's Block mod doesn't support CTM at all, & I don't think it has anything to do with CTM itself, but maybe how the mod renders its blocks.
The Carpenter's Block mod doesn't support CTM at all, & I don't think it has anything to do with CTM itself, but maybe how the mod renders its blocks.
That's what I'd originally thought too, and when I made my first request it was for the implementation of some sort of API that modders could use to hook up to the CTM system.
But then I tried the connect=tiles property, and it worked, leading me to believe that the problem is entirely fixable from within the CTM system. Because the properties file had to recognize the overlay tile on the carpenter's block in order to affect the stone around it. So if it can read it, it should be able to alter it.
Hmmm.... which makes me wonder if it's a render pass order problem. Perhaps it is applying, but it's getting overlaid with the base texture by the carpenter's blocks mod. Maybe if I put the CTM textures in render pass 3 they can overwrite the carpenter's block overlay.
Or maybe I'm just sleepy.
Worth a try anyway.
Well, I'll report back tomorrow, it's 1am, and I need to go to bed.
Thanks for all the input, maybe we'll get this working eventually after all
That's what I'd originally thought too, and when I made my first request it was for the implementation of some sort of API that modders could use to hook up to the CTM system.
But then I tried the connect=tiles property, and it worked, leading me to believe that the problem is entirely fixable from within the CTM system. Because the properties file had to recognize the overlay tile on the carpenter's block in order to affect the stone around it. So if it can read it, it should be able to alter it.
Hmmm.... which makes me wonder if it's a render pass order problem. Perhaps it is applying, but it's getting overlaid with the base texture by the carpenter's blocks mod. Maybe if I put the CTM textures in render pass 3 they can overwrite the carpenter's block overlay.
Or maybe I'm just sleepy.
Worth a try anyway.
Well, I'll report back tomorrow, it's 1am, and I need to go to bed.
Thanks for all the input, maybe we'll get this working eventually after all
Yeah I know what you mean. When I was testing it, I saw the neighboring Vanilla Stone blocks have their CTM changed as if the Carpenter Block(that had the Stone block overlay) was a Vanilla Stone block. So you are right, it is recognizing it, but it's not applying the CTM to the Stone overlay.
You might also be right, it may not be applying the CTM because of Render Passes. It might just be that the CTM is being applied & then the Carpenter's Block is being applied to the over everything else. I'll also try it & see if it might be able to get it to work by using different Render Passes.
Set the weights on all of the less rare mobs to a really high number and set the weight on the rarest one(s) to a very low number.
The chance of a particular variant showing up is basically (Weight / Total Weights) so it's pretty easy to figure out about how high you want to set the common variants.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
-
View User Profile
-
View Posts
-
Send Message
Curse Premiumso:
matchBlocks blah blah
matchTiles stone
Oh, I see what you're saying. But carpenter's blocks take texture's from whatever block you apply to them, they don't have a useful texture of their own. So if I was able to force the stone texture onto it, it would become useless if I wanted it to look like leaves or dirt or whatever.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThat method doesn't work on newer versions of Minecraft(it only works on versions of Minecraft that still used terrain.png for block textures)
The 3 listed properties of CTM all act differently.
This determines what Texture Tile(s) that the specified CTM Method should affect.
This determines what type of CTM that will be applied to the block
This is an optional property, but can be used for methods that connect to adjacent blocks. It specifies how the game should decide if two blocks should be connected.
Just because connect=tile works, that doesn't mean that CTM should work. You are just saying that you want the CTM method to connect by checking the neighboring blocks tile & checking if they are the same. If they are both using the same tile, then it applies the desired CTM method to the block/tile that was specified.
@Deonyi, this wouldn't work because MCPatcher first checks all tile-based entries then it checks block ID-based ones. The first match wins. So by having:
you are basically saying, FIRST check if the block has the stone.png texture from the /minecraft/assests/textures/blocks folder, if there is a match, then ignore matchBlocks properties, BUT if it doesn't match then check the matchBlocks properties.
Having both really isn't necessary for what you guys are trying to do.
@Tsuarok, Carpenter's Block applys overlays to the block, so by having the default Carpenter's Block have the stone texture, it will still act the same. If you want it to look like leaves, it will change from the (now) default stone-looking-like texture to the leaves texture. (That is if you have CTM target the default Carpenter's Block TILE, if you have it target the Carpenter's Block BLOCK, then what you said about the block being useless COULD be true.) (I don't really know how it actually works, because I don't use the Carpenter's Block mod)
NOTE: On the Carpenter's Block mod page, it says that ever since version 3.1.0 of the mod (was released on 4/4/2014) that it removed MCPatcher compatibility because it appears to no longer be needed.
If you could also post your .properties file, we can also help you better. We need your .properties file if you want us to test it too & help find the problem. By posting your .properties file, we can also make sure that there is no problem with your .properties files.
Right, but if it's checking to see that the tile is the same, and it's applying the CTM method based on the tile, it seems like part of the CTM code is recognizing the applied tile (the connect=tile), while the matchTiles part is not. i.e. it has to see the applied tile to use connect=tile, but it won't apply the CTM that matches that tile. It just seems like if one property can recognize the tile other should too.
He never supported CTM, says it's not interesting to him.
From the FAQ on that page he says:
Sure
Edit: the above code perfectly applies the CTM method to actual stone, and connects to carpenter's blocks that have the stone texture applied, but doesn't apply the CTM method to the stone textured carpenter's block
Honestly, I didn't think I'd be able to do this at all. I was really suggesting an extension of the CTM code. But now that I've delved into it, it really seems like the combination of matchTiles and connect properties should have the desired effect.
They don't, but they do point to a possible easily coded fix: getting matchTiles to... match tiles...
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI think you are getting the connect=tile rule & the matchTiles= properties mixed up.
connect=tile is what tells CTM to check if the neighboring blocks should connect, but it just CHECKS the neighboring block's texture tiles to see if it matches the same texture that is stated in matchTiles= property.
matchTiles= is what tells CTM what texture tile to change.
tiles= is what tells CTM what texture(s) should replace the texture(s)/block(s) that are listed in the matchTiles=/matchBlocks= properties, respectively.
connect=tile is checking that the tile is the same, but it's not applying the CTM method. The part of the CTM code that is recognizing the original texture tile is the matchTile= property, connect=tile is the part that you might say is broken.
With your current .properties file, which doesn't seem like there is no problems in it, it might just be the mod that is not letting CTM work properly. Understand that, currently, CTM only supports block selection via Blockname/Block-ID, & metadata. If the tile is being stored is via Tile Entity or NBT tag, CTM will not work. (I guess, theoretically, CTM can still work via tile selection by selecting the texture that you are trying to apply CTM to(like what you're trying to do), but this hasn't worked before & isn't currently working for you now.)
What do you mean by "stone textured carpenter's block" & "carpenter's block that have the stone texture applied"?
So connect=tile is working perfectly, it's the matchTiles that I feel is behaving poorly.
But first I think I need to explain Carpenter's blocks. It is a mod that allows you to create various blocks with unique shapes. If you right-click the carpenter's block with any other block, the texture of that block is applied to the carpenter's block; so you end up with, say, a dirt block in the shape of a vertical slab.
With the above properties file for stone, I can apply a stone texture to a carpenter's block, and the connect=tile property correctly recognizes the tile (i.e. stone texture) on the carpenter's block and the surrounding stone changes it's configuration to connect to it.
However, the carpenter's block texture becomes the base stone texture, not the texture that the CTM method would give it. Since the connect=tile property is working, mcpatcher is clearly recognizing that the carpenter's block now has the stone tile, but it doesn't apply the CTM method to it as it should via the matchTiles property.
Ah, yes, sorry, I had removed that, I pasted this in from a different file and reconstructed what I'd had before. I'd deleted the original.
...
I know what Carpenter's Blocks is. I have seen Let's Play & mod reviews of it before, not to include read over the whole mod page before.
1st) The CTM Method is determined by the "method=" property, not the "matchTiles=" property.
2nd) If the CTM method you have determined isn't being applied to the tile textures, then the CTM for that .properties file doesn't work, so which means that "connect=tiles" is NOT working too.
3rd) If the CTM feature of MCPatcher can correctly recognize the tile on the carpenter's block is stone, then the "matchTiles=stone" property IS WORKING FINE!
You are saying the same thing after I have told you that you're wrong, 3 times. (Not saying you're wrong about the problem you're having, I'm saying you're wrong about what might be the cause of the problem that you are having).
Yes, the CTM method is NOT applying to the carpenter's block with the stone texture. But the surrounding stone treat's it like it's stone, aka, connects to it. The carpenter's block texture remains unaffected.
No offense intended, you just asked what I meant about the carpenter's block with the applied texture, so I thought, to be as clear as possible, I'd just describe the mod.
I know that the CTM method is determined by the method=CTM.
MatchTiles tells the CTM mod where to apply the method. It says, "put this method where this tile is." As you previously stated, connect=tile looks at the neighboring block's tile to determine whether it should connect or not.
As I'd said, the actual stone has the CTM method properly applied. Actual stone connects to the carpenter's block when the stone texture is present, indicating that connect=tiles is in fact working perfectly. i.e. actual stone behaves as if the adjacent carpenter's block is stone too. It does this when I add the connect=tile property, which I did first, before adding any matchTiles.
EDIT: This is the part where the CTM (mod, not method) recognizes the carpenter's block's inherited tile correctly
The properties file does not apply the CTM method to the carpenter's block. It gets only the base stone tile texture.
In my property file, matchTiles allows the method to be applied to stone. I originally just named the file block1; after changing the name, without adding the matchTiles property, the CTM method did not apply to anything at all (which is exactly right, there was no reference). When I added the matchTiles property, it correctly applied the CTM method to the stone blocks, but did not do likewise to the stone textured carpenter's block.
Thus, the problem lies in matchTiles
I know you told me I'm wrong 3 times. Since I'm not wrong, I've been trying to explain more thoroughly the problem.
Oh ok
Oh ok, I see why you explained it, but I didn't take any offense to it.
OOOHHH OK, I thought you were meaning something else. I'm sorry.
But I have installed Carpenter's Block with Forge(Forge Version 10.12.0.1047) & MCPatcher(MCP version 4.3.2_02) on Minecraft 1.7.2 & I haven't been able to get any method of CTM(block-based & tiled-based selection with all types of CTM Methods) to work with anything. BUT here is what I have came across:
1) The metadata= property is pointless(having it in the .properties file or not having it, doesn't affect the outcome)
2) Having matchBlocks= on either 165(the Block-ID of the Carpenter's Block) or CarpentersBlocks:blockCarpentersBlock (the Blockname of the Carpenter's Block) effects the block's appearance in the inventory, but not when placed.(When placed, the block's texture is reverted back to the default Carpenter's Block).
3) Having matchTiles= property doesn't work at all. Doesn't work on the Carpenter's Block default texture, even when selected with matchTiles, nor does it work with block textures that are applied to it.
4) The method= property doesn't matter either.
5) The connect= property doesn't matter either.
The Carpenter's Block mod doesn't support CTM at all, & I don't think it has anything to do with CTM itself, but maybe how the mod renders its blocks.
That's what I'd originally thought too, and when I made my first request it was for the implementation of some sort of API that modders could use to hook up to the CTM system.
But then I tried the connect=tiles property, and it worked, leading me to believe that the problem is entirely fixable from within the CTM system. Because the properties file had to recognize the overlay tile on the carpenter's block in order to affect the stone around it. So if it can read it, it should be able to alter it.
Hmmm.... which makes me wonder if it's a render pass order problem. Perhaps it is applying, but it's getting overlaid with the base texture by the carpenter's blocks mod. Maybe if I put the CTM textures in render pass 3 they can overwrite the carpenter's block overlay.
Or maybe I'm just sleepy.
Worth a try anyway.
Well, I'll report back tomorrow, it's 1am, and I need to go to bed.
Thanks for all the input, maybe we'll get this working eventually after all
Yeah I know what you mean. When I was testing it, I saw the neighboring Vanilla Stone blocks have their CTM changed as if the Carpenter Block(that had the Stone block overlay) was a Vanilla Stone block. So you are right, it is recognizing it, but it's not applying the CTM to the Stone overlay.
You might also be right, it may not be applying the CTM because of Render Passes. It might just be that the CTM is being applied & then the Carpenter's Block is being applied to the over everything else. I'll also try it & see if it might be able to get it to work by using different Render Passes.
In CIT, it's called "damage". Here's a list:
Putting the CENDENT back in transcendent!
-
View User Profile
-
View Posts
-
Send Message
ModeratorThe chance of a particular variant showing up is basically (Weight / Total Weights) so it's pretty easy to figure out about how high you want to set the common variants.