There is no download link. TimmyCheeseburgr explained in great detail how to do this, it's up to you to take the information provided above and put it in your own resource pack.
After playing around with optifine and custom block models this is looking like you can get it working, although not flawlessly, and it comes down to whether it is worth it or not. The first problem with the custom model is that the snow layer doesn't support transparency which means you need to either create your model to perfectly match the pixel configuration of your overlay texture or you have to use optifine's block.properties to add a transparent rendering layer to it, without it any part of the texture with transparency will turn white and opaque. By adding a block.properties in optifine my model started displaying as I would've hoped, however I ran into another problem with the texture displaying z-fighting when moving and getting worse the further you get from it. This could possibly be fixed by increasing the model size (my model is just 4 thousandths of a pixel bigger than the normal block) however the final issue I encountered when place cobblestone next to the layer: for some unknown reason it reverted to the old snow_height2 model even though that doesn't exist in the pack I made. Again, this may be correctable (blockstates would be a good place to start), however given the number of issues I've run into so far I stopped playing with it. It seems like it's possible- it's just a matter of if you think the juice is worth the squeeze.
I tried fixing this for you by altering numerous things in the properties file with no success. After searching around I found an optifine issue that indicates it currently isn't possible and that sp614x hopes to try fixing it, although the issue was reported nearly 2 years ago. https://github.com/sp614x/optifine/issues/1068
What you want is probably possible using a custom model for the snow_height2-14 block models that extends below the bounds of the block and out just enough to eliminate z-fighting but I haven't played with this idea yet. I'll let you know if I get something working.
If your pack is already 1.13 compatible then there really isn't too much needed to make it 1.14 compatible beyond adding all of the new 1.14 assets. A couple other changes from 1.13 to 1.14 are that villagers were redone which means none of those old textures will work anymore, can't avoid that, and textures that used to be in a single image (like paintings, particles) are now broken into multiple smaller files and I believe the mob_effect folder was also added using the images that used to be in the GUI (been a while since I updated my pack). Adapting 1.13 to 1.14 isn't nearly as complex as 1.12 to 1.13 was, I would recommend just getting started with what I've said and if/when you run into something odd you can ask back here and someone should be able to help you once you have a specific problem to address.
The easiest way for you to do what you want would be with optifine and using their CIT so you can target NBT strings and the name of the item for a texture change. While it's not really clean and streamline to require another mod for people to use yours properly optifine is the only method I know of to add variations the way you're talking about/wanting to add them. In the long run it would be a better idea to have the cards contained in the mod but if you want to try using CIT to do what you want the documentation for that can be read here: https://github.com/sp614x/optifine/blob/master/OptiFineDoc/doc/cit_single.properties
Except that mobs won't spawn more than 128 blocks away from players and hostile mobs despawn if they are more than 128 blocks away unless they are nametagged or holding items, spawn chunks or not.
(The /forceload command may allow mobs to spawn away from players.)
Since he mentioned specifically that his zombies are used for repeated farming behavior it would stand to reason that they are either nametagged or are holding an item to prevent despawning which is why I felt it important to mention that it won't matter how far away from them he is if they are in the spawn chunks. If they aren't in spawn chunks being 128 blocks away should be sufficient for them to unload from the world, if they are in the spawn chunks they won't unload- simple enough.
If those zombies are within 128 blocks of where you afk* then yes; those 2 zombies will be loaded and counted as part of the mob cap but, with an SSP hostile cap of 70, they should've be an issue as long as the farm is the only place the other 68 have to spawn. The slime chunk is going to try to do its job as long as the area is loaded so even if you do nothing to the surrounding area you'll likely find an occasional slime but if you can lock down everywhere that isn't in the slime chunk you should notice some pretty impressive spawning inside your farm.
*Edit: Or if that farm is in the 'spawn chunks' of the world- that area is always loaded into the game and any farm (passive or hostile) will impact spawning throughout the world no matter how far away you go.
To localize mob spawning in your slime chunk you need to spawn-proof everything within a 128 block radius of where you afk where hostile mobs can spawn: surface, caves and water. Slime have a low spawn rate compared to other hostiles and they'll never spawn if you've already reached your cap of 70 hostile mobs loaded into the world. The number of valid spawn locations in your farm is comparatively low to the rest of the world around it so you need to reduce the number of valid spawn points outside of the chunk- you could also light up the farm itself since the slime can spawn there in an light level. Hope that helps.
The enchanting table in your GUI doesn't have its own image by default, it uses the enchanting_table.json model located in assets/minecraft/models/item to insert the block into your inventory and GUI. If you have a checker pattern then I imagine at some point this model was altered and it no longer points to the correct model for the game to use. Since I don't know if you are using a custom model for the table itself or what may have been done to create your issue I would suggest going into your item model for the table and making sure any textures or file pathways assigned in it are correct, but if you are just using the normal vanilla model for your table then simply deleting your item model should cause the default to work as intended.
Why would you change something that's working? Them using a code to insert special characters may look a little ugly when staring at the json file but if everything is displaying properly in game then why go through the time and effort to change how the text looks in the files if you don't want to actually change how it's displaying in game? When I activate the language in 1.14 it displays perfectly in the chat and GUI, what exactly are you wanting it to do differently?
I helped someone do this 2 different ways in 1.13 and there is quite a bit of detail about it here: https://www.minecraftforum.net/forums/mapping-and-modding-java-edition/resource-packs/resource-pack-help/2940489-mc-1-13-help-with-custom-item-textures Both of the example packs I linked there are still active on mediafire and will work for 1.12 with minor modification. Because these examples were made for 1.13 to adapt them to 1.12 you need to: change the pack format in pack.png for 4 to 3, rename the folder in assets/minecraft/textures from 'item' to 'items', and in the folder assets/minecraft/models/item (do not change this folder name) open all of the json files and make sure they are using the new 'items' folder for their texture instead of my originally name 'item' folder. I have tested and doing this to both packs makes them fully functional in 1.12.
If you are trying to insert custom items to the game using the unbreakable tag and damage values, rather than material degradation, the syntax of the command will be different for 1.12 than the 1.13 command, for 1.12 it would be:
/give InfiniteCorners minecraft:golden_shovel 1 1 {Unbreakable:1b} For a golden shovel that looks like a diamond axe and
/give InfiniteCorners minecraft:golden_shovel 1 2 {Unbreakable:1b} for a golden shovel that looks like a diamond sword.
If you're switching textures to show deterioration of the item as it breaks down then the other pack would just be a matter of expanding the predicate array to whatever you want it for the item breaking down. Hope that helps, let us know if you need more help.
There isn't a whole lot of advice I can give you because you haven't provided a whole lot of information. Since you have some files working I imagine you have the correct file pathway assigned but without seeing properties files and more basic information about what you've done and what version you are updating from/to all I can do is guess. Depending on how old the pack you're trying to update is and what version you are updating it to you may have an issue with the properties files referencing what blocks to apply CTM to using numeric data values which is no longer supported, names are used instead. An example would be glowstone used to be able to be referenced as 89 in the properties files and the name of the file would often be block89 however that file now should say 'glowstone' and if it says '89' instead then it won't work.
You could also have a problem with the fact that carpet uses the wool textures by default and doesn't have their own image to use. I remember doing carpet CTM for a guy and I re-did my block models for all of the colors of carpet so they had a unique texture and then I used matchTiles to apply CTM to yellow_carpet and all the others. I'm not sure you would need to to this if you used matchBlocks=yellow_carpet in your CTM but that won't change the appearance of the carpet in your inventory so I still think altering the block models to use unique images would be the way to go.
If you want to show us some of your directory pathways, properties files and some more detail about what isn't working I may be able to help more. If you uploaded a minimum example of what you're working with I could guarantee we'd get it working. Unfortunately that's about as much help as I can offer without more info, hope it helps.
This has been a reported bug with optifine for almost a year now. I just made a comment on it today to raise its awareness but all we can do is sit and wait for it to be fixed https://github.com/sp614x/optifine/issues/2131
It would be easier if they were screenshots we could zoom in on. Kind of hard to tell from this distance but those logs look distinctly DokuCraft to me: https://dokucraft.co.uk/
1
There is no download link. TimmyCheeseburgr explained in great detail how to do this, it's up to you to take the information provided above and put it in your own resource pack.
0
After playing around with optifine and custom block models this is looking like you can get it working, although not flawlessly, and it comes down to whether it is worth it or not. The first problem with the custom model is that the snow layer doesn't support transparency which means you need to either create your model to perfectly match the pixel configuration of your overlay texture or you have to use optifine's block.properties to add a transparent rendering layer to it, without it any part of the texture with transparency will turn white and opaque. By adding a block.properties in optifine my model started displaying as I would've hoped, however I ran into another problem with the texture displaying z-fighting when moving and getting worse the further you get from it. This could possibly be fixed by increasing the model size (my model is just 4 thousandths of a pixel bigger than the normal block) however the final issue I encountered when place cobblestone next to the layer: for some unknown reason it reverted to the old snow_height2 model even though that doesn't exist in the pack I made. Again, this may be correctable (blockstates would be a good place to start), however given the number of issues I've run into so far I stopped playing with it. It seems like it's possible- it's just a matter of if you think the juice is worth the squeeze.
1
I tried fixing this for you by altering numerous things in the properties file with no success. After searching around I found an optifine issue that indicates it currently isn't possible and that sp614x hopes to try fixing it, although the issue was reported nearly 2 years ago. https://github.com/sp614x/optifine/issues/1068
What you want is probably possible using a custom model for the snow_height2-14 block models that extends below the bounds of the block and out just enough to eliminate z-fighting but I haven't played with this idea yet. I'll let you know if I get something working.
0
If your pack is already 1.13 compatible then there really isn't too much needed to make it 1.14 compatible beyond adding all of the new 1.14 assets. A couple other changes from 1.13 to 1.14 are that villagers were redone which means none of those old textures will work anymore, can't avoid that, and textures that used to be in a single image (like paintings, particles) are now broken into multiple smaller files and I believe the mob_effect folder was also added using the images that used to be in the GUI (been a while since I updated my pack). Adapting 1.13 to 1.14 isn't nearly as complex as 1.12 to 1.13 was, I would recommend just getting started with what I've said and if/when you run into something odd you can ask back here and someone should be able to help you once you have a specific problem to address.
0
Using model predicated to try to add variants to items isn't going to work quite the way you want it to, and since you and on 1.12 you can't use custom_model_data which could've helped. Items only have so many predicates that they can use and those can be read here: https://minecraft.gamepedia.com/Model#Item_tags and item naming isn't one of them. If you were using an item with durability and the unbreakable tag you could add variations as I was describing for this guy: https://www.minecraftforum.net/forums/mapping-and-modding-java-edition/resource-packs/resource-pack-help/2982867-minecraft-java-1-12-2-resource-pack-help although I'm not sure how much that would help.
The easiest way for you to do what you want would be with optifine and using their CIT so you can target NBT strings and the name of the item for a texture change. While it's not really clean and streamline to require another mod for people to use yours properly optifine is the only method I know of to add variations the way you're talking about/wanting to add them. In the long run it would be a better idea to have the cards contained in the mod but if you want to try using CIT to do what you want the documentation for that can be read here: https://github.com/sp614x/optifine/blob/master/OptiFineDoc/doc/cit_single.properties
0
Since he mentioned specifically that his zombies are used for repeated farming behavior it would stand to reason that they are either nametagged or are holding an item to prevent despawning which is why I felt it important to mention that it won't matter how far away from them he is if they are in the spawn chunks. If they aren't in spawn chunks being 128 blocks away should be sufficient for them to unload from the world, if they are in the spawn chunks they won't unload- simple enough.
0
If those zombies are within 128 blocks of where you afk* then yes; those 2 zombies will be loaded and counted as part of the mob cap but, with an SSP hostile cap of 70, they should've be an issue as long as the farm is the only place the other 68 have to spawn. The slime chunk is going to try to do its job as long as the area is loaded so even if you do nothing to the surrounding area you'll likely find an occasional slime but if you can lock down everywhere that isn't in the slime chunk you should notice some pretty impressive spawning inside your farm.
*Edit: Or if that farm is in the 'spawn chunks' of the world- that area is always loaded into the game and any farm (passive or hostile) will impact spawning throughout the world no matter how far away you go.
0
To localize mob spawning in your slime chunk you need to spawn-proof everything within a 128 block radius of where you afk where hostile mobs can spawn: surface, caves and water. Slime have a low spawn rate compared to other hostiles and they'll never spawn if you've already reached your cap of 70 hostile mobs loaded into the world. The number of valid spawn locations in your farm is comparatively low to the rest of the world around it so you need to reduce the number of valid spawn points outside of the chunk- you could also light up the farm itself since the slime can spawn there in an light level. Hope that helps.
0
The enchanting table in your GUI doesn't have its own image by default, it uses the enchanting_table.json model located in assets/minecraft/models/item to insert the block into your inventory and GUI. If you have a checker pattern then I imagine at some point this model was altered and it no longer points to the correct model for the game to use. Since I don't know if you are using a custom model for the table itself or what may have been done to create your issue I would suggest going into your item model for the table and making sure any textures or file pathways assigned in it are correct, but if you are just using the normal vanilla model for your table then simply deleting your item model should cause the default to work as intended.
0
Why would you change something that's working? Them using a code to insert special characters may look a little ugly when staring at the json file but if everything is displaying properly in game then why go through the time and effort to change how the text looks in the files if you don't want to actually change how it's displaying in game? When I activate the language in 1.14 it displays perfectly in the chat and GUI, what exactly are you wanting it to do differently?
0
I helped someone do this 2 different ways in 1.13 and there is quite a bit of detail about it here: https://www.minecraftforum.net/forums/mapping-and-modding-java-edition/resource-packs/resource-pack-help/2940489-mc-1-13-help-with-custom-item-textures Both of the example packs I linked there are still active on mediafire and will work for 1.12 with minor modification. Because these examples were made for 1.13 to adapt them to 1.12 you need to: change the pack format in pack.png for 4 to 3, rename the folder in assets/minecraft/textures from 'item' to 'items', and in the folder assets/minecraft/models/item (do not change this folder name) open all of the json files and make sure they are using the new 'items' folder for their texture instead of my originally name 'item' folder. I have tested and doing this to both packs makes them fully functional in 1.12.
If you are trying to insert custom items to the game using the unbreakable tag and damage values, rather than material degradation, the syntax of the command will be different for 1.12 than the 1.13 command, for 1.12 it would be:
/give InfiniteCorners minecraft:golden_shovel 1 1 {Unbreakable:1b} For a golden shovel that looks like a diamond axe and
/give InfiniteCorners minecraft:golden_shovel 1 2 {Unbreakable:1b} for a golden shovel that looks like a diamond sword.
If you're switching textures to show deterioration of the item as it breaks down then the other pack would just be a matter of expanding the predicate array to whatever you want it for the item breaking down. Hope that helps, let us know if you need more help.
0
The documentation for how to use CTM can be read here: https://github.com/sp614x/optifine/blob/master/OptiFineDoc/doc/ctm.properties and some template images for CTM and CTM_compact can be seen here: https://github.com/sp614x/optifine/tree/master/OptiFineDoc/doc/images
There isn't a whole lot of advice I can give you because you haven't provided a whole lot of information. Since you have some files working I imagine you have the correct file pathway assigned but without seeing properties files and more basic information about what you've done and what version you are updating from/to all I can do is guess. Depending on how old the pack you're trying to update is and what version you are updating it to you may have an issue with the properties files referencing what blocks to apply CTM to using numeric data values which is no longer supported, names are used instead. An example would be glowstone used to be able to be referenced as 89 in the properties files and the name of the file would often be block89 however that file now should say 'glowstone' and if it says '89' instead then it won't work.
You could also have a problem with the fact that carpet uses the wool textures by default and doesn't have their own image to use. I remember doing carpet CTM for a guy and I re-did my block models for all of the colors of carpet so they had a unique texture and then I used matchTiles to apply CTM to yellow_carpet and all the others. I'm not sure you would need to to this if you used matchBlocks=yellow_carpet in your CTM but that won't change the appearance of the carpet in your inventory so I still think altering the block models to use unique images would be the way to go.
If you want to show us some of your directory pathways, properties files and some more detail about what isn't working I may be able to help more. If you uploaded a minimum example of what you're working with I could guarantee we'd get it working. Unfortunately that's about as much help as I can offer without more info, hope it helps.
0
Nice, that's a clever way of targeting the sword.
0
This has been a reported bug with optifine for almost a year now. I just made a comment on it today to raise its awareness but all we can do is sit and wait for it to be fixed https://github.com/sp614x/optifine/issues/2131
0
It would be easier if they were screenshots we could zoom in on. Kind of hard to tell from this distance but those logs look distinctly DokuCraft to me: https://dokucraft.co.uk/