Is there a post of thread i should look at to find the current proper use of metadata= and matchBlocks= ? for the latest version?
Not that I'm aware of. Seems like most everyone who would want to write something up is waiting for the other shoe to drop or just doesn't have the time.
For my own part... I would write something up but I'm not sure I understand it myself. A lot of things that seem like they should be working aren't anymore, and I'm not sure if it's because of bugs in MCPatcher or something I'm doing wrong. Sorry.
You can ask specific questions, though I can't guarantee anyone will have good answers right now.
I'm mostly confused about how to reference specific blocks.
Does the title of the properties file matter at all?
I used to use stuff like...
matchBlocks=double_stone_slab:5
But that seems to be a bit unreliable now.
I've been told to use a metadata line...
matchBlocks=double_stone_slab
metadata=5
Which seems to work better, but it just looks like the same information formatted differently, and aren't we no longer using metadata in 1.8?
And then i see query above promoting the use of...
matchBlocks=sand:variant=normal
which i haven't seen before, but i can use F3 to find "variant" info from some blocks, but other blocks don't have "variant" but have "facing", "half", and "shape".
And on a more theoretical level, most of my CTM is simple random CTM which i have replicated with 1.8 Block models. I'd happily get rid of the random CTM, but i'd like it to stay for people who use my pack pre-1.8. Weird stuff is happening with my packs and it would be helpful to know what is supposed to take priority over what, and how stacked packs that also have CTM and Blockmodels are supposed to override or not.
which i haven't seen before, but i can use F3 to find "variant" info from some blocks, but other blocks don't have "variant" but have "facing", "half", and "shape".
This is what works in 1.8. For cases where you have ones like "facing" you would use that instead of "variant". For example "matchBlock=furnace:facing=north" should work. If you want it to work for both 1.6/7 and 1.8, the I think you use the block name, followed by the metadata, followed by the variant. For example "thisBlock:5:variant=theFifthOne".
And on a more theoretical level, most of my CTM is simple random CTM which i have replicated with 1.8 Block models. I'd happily get rid of the random CTM, but i'd like it to stay for people who use my pack pre-1.8. Weird stuff is happening with my packs and it would be helpful to know what is supposed to take priority over what, and how stacked packs that also have CTM and Blockmodels are supposed to override or not.
This is where there's problems... but it's really no different than it's ever been. There's just a second level of the same problem that's always existed with CTM.
Generally speaking, any CTM or block model will take president over vanilla stuff even if the pack is lower on the list than the vanilla-only one. This is actually intended behavior. Where you run into problems is when you have multiple things modifying the same thing stacking. Then stuff gets tricky.
First, for block models, this is pretty easy. Whichever set of models the top-most blockstate file for a particular block points to wins. Period. If a pack doesn't have a blockstate file for a particular block, then it doesn't matter when taking this into account. Unless of course it's model file overrides the default model (which I consider bad practice unless it's a simple tweak like changing the lighting ), at which point that model will replace the vanilla one if no blockstate files point to anything different. This is just like how the top-most texture for a given block is the one that's used. Same concept, different application.
Stacking CTM is a little different. MCPatcher has its own set of rules for which file takes precedent and it doesn't generally care about what order the packs are stacked in. This is an unfortunate side-effect of MCPatcher predating the ability to stack packs. As I understand it, MCPatcher looks at all of the possibilities for any given block or item state and the one with the highest Weight attribute wins. If none of the possibilities have a weight attribute, the first file name alphabetically wins.
This is where the problem comes in since there's no universal naming convention for CTM. Everyone does their own stuff differently. Ideally a single pack should be set up where there's no question about what should be happening in any given situation... but with multiple packs there's no real control and bad things might happen. Someone might use a 0-10 scale with their weights while the next guy might use a 1-100 scale, some might use folders or have different names that cause problems with ordering, etc.
And now here's the part that I'm REALLY not sure on: Mixing CTM with block models. For example... I have a custom anvil model in my pack which is effectively replacing the old anvil CTM I was using. Now, the CTM files should apply to the model... but they don't. I'm not totally sure why they don't either. I had originally thought that it was because I avoided using the same references for textures that MCPatcher does ("side" instead "north" and "south"), but this doesn't make any sense to me since it still seems to work with vanilla blocks that do the same thing. Unfortunately I haven't really played with it since most of the CTM I've done is easily replaceable with block models anyway so I'm migrating as much as I can in that direction to make it more accessible to the greatest amount of people.
There are also other problems like CTM overriding item model rotations for some reason.
I hope that answered some of your questions at least. Keep in mind that I'm not 100% sure on most of this stuff, so you're probably going to have to go through a little bit of trial and error. I've never been big on CTM anyway, being much more well versed in CIT and Custom Colors.
I keep getting this crash report when I try to run minecraft with optifine and mcpatcher installed.
---- Minecraft Crash Report ----
// Sorry
Time: 1/31/15 12:38 PM
Description: Rendering item
java.lang.NullPointerException: Rendering item
at com.prupe.mcpatcher.cit.CITUtils18.getModelFace(CITUtils18.java:47)
at cqh.a(SourceFile:187)
at cqh.a(SourceFile:105)
at cqh.a(SourceFile:89)
at cqh.a(SourceFile:127)
at cqh.a(SourceFile:347)
at cqh.b(SourceFile:383)
at byy.a(SourceFile:732)
at byy.a(SourceFile:623)
at byk.a(SourceFile:80)
at bzc.a(SourceFile:36)
at byy.a(SourceFile:558)
at cjh.b(EntityRenderer.java:1308)
at bss.at(SourceFile:906)
at bss.a(SourceFile:317)
at net.minecraft.client.main.Main.main(SourceFile:124)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at net.minecraft.launchwrapper.Launch.launch(Launch.java:131)
at net.minecraft.launchwrapper.Launch.main(Launch.java:27)
A detailed walkthrough of the error, its code path and all known details is as follows:
---------------------------------------------------------------------------------------
-- Head --
Stacktrace:
at com.prupe.mcpatcher.cit.CITUtils18.getModelFace(CITUtils18.java:47)
at cqh.a(SourceFile:187)
at cqh.a(SourceFile:105)
at cqh.a(SourceFile:89)
at cqh.a(SourceFile:127)
at cqh.a(SourceFile:347)
-- Item being rendered --
Details:
Item Type: [email protected]
Item Aux: 5
Item NBT: null
Item Foil: false
Stacktrace:
at cqh.b(SourceFile:383)
at byy.a(SourceFile:732)
at byy.a(SourceFile:623)
at byk.a(SourceFile:80)
at bzc.a(SourceFile:36)
at byy.a(SourceFile:558)
-- Screen render details --
Details:
Screen name: byy
Mouse location: Scaled: (213, 119). Absolute: (427, 240)
Screen size: Scaled: (427, 240). Absolute: (854, 480). Scale factor of 2
-- Affected level --
Details:
Level name: MpServer
All players: 1 total; [cin['MST3K'/0, l='MpServer', x=912.84, y=56.00, z=-573.65]]
Chunk stats: MultiplayerChunkCache: 600, 600
Level seed: 0
Level generator: ID 01 - flat, ver 0. Features enabled: false
Level generator options:
Level spawn location: 869.00,4.00,-578.00 - World: (869,4,-578), Chunk: (at 5,0,14 in 54,-37; contains blocks 864,0,-592 to 879,255,-577), Region: (1,-2; contains chunks 32,-64 to 63,-33, blocks 512,0,-1024 to 1023,255,-513)
Level time: 970889 game time, 1611 day time
Level dimension: 0
Level storage version: 0x00000 - Unknown?
Level weather: Rain time: 0 (now: false), thunder time: 0 (now: false)
Level game mode: Game mode: creative (ID 1). Hardcore: false. Cheats: false
Forced entities: 1 total; [cin['MST3K'/0, l='MpServer', x=912.84, y=56.00, z=-573.65]]
Retry entities: 0 total; []
Server brand: vanilla
Server type: Integrated singleplayer server
Stacktrace:
at cem.a(WorldClient.java:399)
at bss.b(SourceFile:2278)
at bss.a(SourceFile:326)
at net.minecraft.client.main.Main.main(SourceFile:124)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at net.minecraft.launchwrapper.Launch.launch(Launch.java:131)
at net.minecraft.launchwrapper.Launch.main(Launch.java:27)
-- System Details --
Details:
Minecraft Version: 1.8.1
Operating System: Windows 8.1 (amd64) version 6.3
Java Version: 1.8.0_25, Oracle Corporation
Java VM Version: Java HotSpot(TM) 64-Bit Server VM (mixed mode), Oracle Corporation
Memory: 272455512 bytes (259 MB) / 773324800 bytes (737 MB) up to 3817865216 bytes (3641 MB)
JVM Flags: 2 total; -XX:HeapDumpPath=MojangTricksIntelDriversForPerformance_javaw.exe_minecraft.exe.heapdump -Xmx4G
IntCache: cache: 0, tcache: 0, allocated: 0, tallocated: 0
Launched Version: 1.8.1-OptiFine_HD_U_C3-mcpatcher
LWJGL: 2.9.1
OpenGL: Intel(R) HD Graphics 4400 GL version 4.2.0 - Build 10.18.10.3412, Intel
GL Caps: Using GL 1.3 multitexturing.
Using GL 1.3 texture combiners.
Using framebuffer objects because OpenGL 3.0 is supported and separate blending is supported.
Shaders are available because OpenGL 2.1 is supported.
VBOs are available because OpenGL 1.5 is supported.
Using VBOs: No
Is Modded: Very likely; Jar signature invalidated
Type: Client (map_client.txt)
Resource Packs: [BDcraft Musics Pack.zip, BDcraft Sounds Pack.zip, Sphax PureBDcraft 128x MC18.zip]
Current Language: English (US)
Profiler Position: N/A (disabled)
Does somebody work with nested ctm and/or can give me a hint on how to make this work?
First off, the properties are case-sensitive, so the proper line is "matchTiles". You can remove "matchtiles" and "variant" from the original properties file. Secondly, any texture not in /textures/blocks has to be specified using the full path, so in this case
Thanks a lot, but I'm afraid this did not work.
I removed "matchtiles" and "variant" from the sandstone_smooth.properties, and then the file did not work at all. After that I re-entered the lines step by step and the CTM did not work until I had changed it back to what it has been before - including the lower-case t in "matchtiles".
Also, do I have to make an extra properties-file for the 27.png or do I have to include this in the sandstone_smooth.properties? None of both seemed to work...
You may have to weight one of the files higher (weight=1), but I've never used anything like this in CTM.
First off I'd like to preface this with: I'm a noob when it comes to this kind of modding (a resource-pack which uses MCPatcher), and I also have no coding knowledge on top of that; however, I've been around computers since 1994 and in all my days of tinkering have picked up some things through things like modding game INI files and driver INFs. That being said, some (ok quite a few) aspects of MCPatcher's properties files have me perplexed at times.
I'll start out by saying that on my server I'm using nether_star:10 to act as a unique item in crafting recipes, as with the Bukkit plugin I use it requires that level of difference in order to not be able to craft the item with a "vanilla" one. Example: Making a sword with one of the recipe items being a Nether Star that is called something else (with lore as well) can unfortunately be bypassed by using a vanilla Nether Star. I happened to find that the drops from another plugin curiously would not work in recipes as anticipated, not appearing to be caused by it's red and bold name, but by it's DV meta of "10" (which I confirmed with /i netherstar:10 1). I wanted to make it so that the alternate texture would be triggered by that DV of "10" so I tried putting in items:nether_star:10 but that didn't work. As I mentioned I know little about this level of stuff, and I'm still trying to wrap my head about datavalues (damagevalues? even if not on a damageable item?) and NBT stuff. As such I had to fallback to using the NBT trigger where I had it look for the specific colorized name of the item (albeit after quite a bit of trial and error to get that working). Except... I ran into an odd issue that I can't say I expected when it finally did work. Instead of the item being an item as swords I had made an alt texture for in the exact same way, it was for some reason treated as a block: it was a cube, the texture repeated on all six sides, instead of the expected "flat" 2D texture. This was the case when held, in item frames and when dropped.
properties file is inside the pack's: /assets/minecraft/mcpatcher/CIT folder which carries the same name as the PNG file (same as the rest which display right), and contains this:
Also... crap! I did not want to see that Opti and MCPatcher will not work together The texture pack I started working on for my server requires the CIT mod, which after having the same issue as the rest of the people had tried installing only the CIT mod, but still was unable to have stuff work. I can't live w/o OptiFine (nor ask anyone else to for that matter), so this sure sucks *sigh*
Non-vanilla data values are not supported in 1.8. Period. You'll have to use something else.
Sort of, yea. I mean, generally speaking there is no texture for it and it gets the evil Pink/Black "No Texture" Block of Doom, but it is still functional for everything I need it for, thankfully. (Making unique recipes). It's simply it ends up looking like the attached pic, as apposed to a traditional Nether Star like it should I was just hoping it did that due to some error on my part, but oh well. I can make something work so not ALL hope is lost!
Maybe when (if?) CIT supports alternate models to go along with the textures, we'll be able to have non-vanilla DV items function how they did prior to 1.8 heh
Well, I know how to do it, but I haven't done it. So basically for the custom 3D items, you get the default model, then you create the CIT model and combine them, and then you make the CIT images one resolution higher (e.g 12x12-32x32) and done
I searched the forums but I didn't find any answer: is it possible to make the resource pack turn off clouds? I ask because a custom sky with realistic clouds looks bad with those white boxes up there and it would be easier to disable them automatically instead of telling people to do it by hand.
matchBlocks=sand
method=random
tiles=0-4
weights=33 5 5 5 2
is there any way to fix this?
matchBlocks=sand:variant=normal
(use the F3 screen to see the metadata for any block)
Putting the CENDENT back in transcendent!
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumIs there a post of thread i should look at to find the current proper use of metadata= and matchBlocks= ? for the latest version?
• Follow Lithos on Twitter for release announcments
* Join the Lithos Discord for previews and to help
-
View User Profile
-
View Posts
-
Send Message
ModeratorNot that I'm aware of. Seems like most everyone who would want to write something up is waiting for the other shoe to drop or just doesn't have the time.
For my own part... I would write something up but I'm not sure I understand it myself. A lot of things that seem like they should be working aren't anymore, and I'm not sure if it's because of bugs in MCPatcher or something I'm doing wrong. Sorry.
You can ask specific questions, though I can't guarantee anyone will have good answers right now.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumDoes the title of the properties file matter at all?
I used to use stuff like...
But that seems to be a bit unreliable now.
I've been told to use a metadata line...
Which seems to work better, but it just looks like the same information formatted differently, and aren't we no longer using metadata in 1.8?
And then i see query above promoting the use of...
which i haven't seen before, but i can use F3 to find "variant" info from some blocks, but other blocks don't have "variant" but have "facing", "half", and "shape".
And on a more theoretical level, most of my CTM is simple random CTM which i have replicated with 1.8 Block models. I'd happily get rid of the random CTM, but i'd like it to stay for people who use my pack pre-1.8. Weird stuff is happening with my packs and it would be helpful to know what is supposed to take priority over what, and how stacked packs that also have CTM and Blockmodels are supposed to override or not.
• Follow Lithos on Twitter for release announcments
* Join the Lithos Discord for previews and to help
-
View User Profile
-
View Posts
-
Send Message
ModeratorThis is what works in 1.8. For cases where you have ones like "facing" you would use that instead of "variant". For example "matchBlock=furnace:facing=north" should work. If you want it to work for both 1.6/7 and 1.8, the I think you use the block name, followed by the metadata, followed by the variant. For example "thisBlock:5:variant=theFifthOne".
This is where there's problems... but it's really no different than it's ever been. There's just a second level of the same problem that's always existed with CTM.
Generally speaking, any CTM or block model will take president over vanilla stuff even if the pack is lower on the list than the vanilla-only one. This is actually intended behavior. Where you run into problems is when you have multiple things modifying the same thing stacking. Then stuff gets tricky.
First, for block models, this is pretty easy. Whichever set of models the top-most blockstate file for a particular block points to wins. Period. If a pack doesn't have a blockstate file for a particular block, then it doesn't matter when taking this into account. Unless of course it's model file overrides the default model (which I consider bad practice unless it's a simple tweak like changing the lighting ), at which point that model will replace the vanilla one if no blockstate files point to anything different. This is just like how the top-most texture for a given block is the one that's used. Same concept, different application.
Stacking CTM is a little different. MCPatcher has its own set of rules for which file takes precedent and it doesn't generally care about what order the packs are stacked in. This is an unfortunate side-effect of MCPatcher predating the ability to stack packs. As I understand it, MCPatcher looks at all of the possibilities for any given block or item state and the one with the highest Weight attribute wins. If none of the possibilities have a weight attribute, the first file name alphabetically wins.
This is where the problem comes in since there's no universal naming convention for CTM. Everyone does their own stuff differently. Ideally a single pack should be set up where there's no question about what should be happening in any given situation... but with multiple packs there's no real control and bad things might happen. Someone might use a 0-10 scale with their weights while the next guy might use a 1-100 scale, some might use folders or have different names that cause problems with ordering, etc.
And now here's the part that I'm REALLY not sure on: Mixing CTM with block models. For example... I have a custom anvil model in my pack which is effectively replacing the old anvil CTM I was using. Now, the CTM files should apply to the model... but they don't. I'm not totally sure why they don't either. I had originally thought that it was because I avoided using the same references for textures that MCPatcher does ("side" instead "north" and "south"), but this doesn't make any sense to me since it still seems to work with vanilla blocks that do the same thing. Unfortunately I haven't really played with it since most of the CTM I've done is easily replaceable with block models anyway so I'm migrating as much as I can in that direction to make it more accessible to the greatest amount of people.
There are also other problems like CTM overriding item model rotations for some reason.
I hope that answered some of your questions at least. Keep in mind that I'm not 100% sure on most of this stuff, so you're probably going to have to go through a little bit of trial and error. I've never been big on CTM anyway, being much more well versed in CIT and Custom Colors.
---- Minecraft Crash Report ----
// Sorry
Time: 1/31/15 12:38 PM
Description: Rendering item
java.lang.NullPointerException: Rendering item
at com.prupe.mcpatcher.cit.CITUtils18.getModelFace(CITUtils18.java:47)
at cqh.a(SourceFile:187)
at cqh.a(SourceFile:105)
at cqh.a(SourceFile:89)
at cqh.a(SourceFile:127)
at cqh.a(SourceFile:347)
at cqh.b(SourceFile:383)
at byy.a(SourceFile:732)
at byy.a(SourceFile:623)
at byk.a(SourceFile:80)
at bzc.a(SourceFile:36)
at byy.a(SourceFile:558)
at cjh.b(EntityRenderer.java:1308)
at bss.at(SourceFile:906)
at bss.a(SourceFile:317)
at net.minecraft.client.main.Main.main(SourceFile:124)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at net.minecraft.launchwrapper.Launch.launch(Launch.java:131)
at net.minecraft.launchwrapper.Launch.main(Launch.java:27)
A detailed walkthrough of the error, its code path and all known details is as follows:
---------------------------------------------------------------------------------------
-- Head --
Stacktrace:
at com.prupe.mcpatcher.cit.CITUtils18.getModelFace(CITUtils18.java:47)
at cqh.a(SourceFile:187)
at cqh.a(SourceFile:105)
at cqh.a(SourceFile:89)
at cqh.a(SourceFile:127)
at cqh.a(SourceFile:347)
-- Item being rendered --
Details:
Item Type: [email protected]
Item Aux: 5
Item NBT: null
Item Foil: false
Stacktrace:
at cqh.b(SourceFile:383)
at byy.a(SourceFile:732)
at byy.a(SourceFile:623)
at byk.a(SourceFile:80)
at bzc.a(SourceFile:36)
at byy.a(SourceFile:558)
-- Screen render details --
Details:
Screen name: byy
Mouse location: Scaled: (213, 119). Absolute: (427, 240)
Screen size: Scaled: (427, 240). Absolute: (854, 480). Scale factor of 2
-- Affected level --
Details:
Level name: MpServer
All players: 1 total; [cin['MST3K'/0, l='MpServer', x=912.84, y=56.00, z=-573.65]]
Chunk stats: MultiplayerChunkCache: 600, 600
Level seed: 0
Level generator: ID 01 - flat, ver 0. Features enabled: false
Level generator options:
Level spawn location: 869.00,4.00,-578.00 - World: (869,4,-578), Chunk: (at 5,0,14 in 54,-37; contains blocks 864,0,-592 to 879,255,-577), Region: (1,-2; contains chunks 32,-64 to 63,-33, blocks 512,0,-1024 to 1023,255,-513)
Level time: 970889 game time, 1611 day time
Level dimension: 0
Level storage version: 0x00000 - Unknown?
Level weather: Rain time: 0 (now: false), thunder time: 0 (now: false)
Level game mode: Game mode: creative (ID 1). Hardcore: false. Cheats: false
Forced entities: 1 total; [cin['MST3K'/0, l='MpServer', x=912.84, y=56.00, z=-573.65]]
Retry entities: 0 total; []
Server brand: vanilla
Server type: Integrated singleplayer server
Stacktrace:
at cem.a(WorldClient.java:399)
at bss.b(SourceFile:2278)
at bss.a(SourceFile:326)
at net.minecraft.client.main.Main.main(SourceFile:124)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at net.minecraft.launchwrapper.Launch.launch(Launch.java:131)
at net.minecraft.launchwrapper.Launch.main(Launch.java:27)
-- System Details --
Details:
Minecraft Version: 1.8.1
Operating System: Windows 8.1 (amd64) version 6.3
Java Version: 1.8.0_25, Oracle Corporation
Java VM Version: Java HotSpot(TM) 64-Bit Server VM (mixed mode), Oracle Corporation
Memory: 272455512 bytes (259 MB) / 773324800 bytes (737 MB) up to 3817865216 bytes (3641 MB)
JVM Flags: 2 total; -XX:HeapDumpPath=MojangTricksIntelDriversForPerformance_javaw.exe_minecraft.exe.heapdump -Xmx4G
IntCache: cache: 0, tcache: 0, allocated: 0, tallocated: 0
Launched Version: 1.8.1-OptiFine_HD_U_C3-mcpatcher
LWJGL: 2.9.1
OpenGL: Intel(R) HD Graphics 4400 GL version 4.2.0 - Build 10.18.10.3412, Intel
GL Caps: Using GL 1.3 multitexturing.
Using GL 1.3 texture combiners.
Using framebuffer objects because OpenGL 3.0 is supported and separate blending is supported.
Shaders are available because OpenGL 2.1 is supported.
VBOs are available because OpenGL 1.5 is supported.
Using VBOs: No
Is Modded: Very likely; Jar signature invalidated
Type: Client (map_client.txt)
Resource Packs: [BDcraft Musics Pack.zip, BDcraft Sounds Pack.zip, Sphax PureBDcraft 128x MC18.zip]
Current Language: English (US)
Profiler Position: N/A (disabled)
Kahr has stated many times.
Do not use Optifine with MCPatcher as they are incompatible
Please avoid posting these crash threads.
Thank you
http://hypixel.net/threads/diax-resource-pack.199998/
If you got a jar then you just downloaded the non windows version. You can still use it though. Just run it normally as if it were a exe.
First off, the properties are case-sensitive, so the proper line is "matchTiles". You can remove "matchtiles" and "variant" from the original properties file. Secondly, any texture not in /textures/blocks has to be specified using the full path, so in this case
Putting the CENDENT back in transcendent!
You may have to weight one of the files higher (weight=1), but I've never used anything like this in CTM.
Putting the CENDENT back in transcendent!
I'll start out by saying that on my server I'm using nether_star:10 to act as a unique item in crafting recipes, as with the Bukkit plugin I use it requires that level of difference in order to not be able to craft the item with a "vanilla" one. Example: Making a sword with one of the recipe items being a Nether Star that is called something else (with lore as well) can unfortunately be bypassed by using a vanilla Nether Star. I happened to find that the drops from another plugin curiously would not work in recipes as anticipated, not appearing to be caused by it's red and bold name, but by it's DV meta of "10" (which I confirmed with /i netherstar:10 1). I wanted to make it so that the alternate texture would be triggered by that DV of "10" so I tried putting in items:nether_star:10 but that didn't work. As I mentioned I know little about this level of stuff, and I'm still trying to wrap my head about datavalues (damagevalues? even if not on a damageable item?) and NBT stuff. As such I had to fallback to using the NBT trigger where I had it look for the specific colorized name of the item (albeit after quite a bit of trial and error to get that working). Except... I ran into an odd issue that I can't say I expected when it finally did work. Instead of the item being an item as swords I had made an alt texture for in the exact same way, it was for some reason treated as a block: it was a cube, the texture repeated on all six sides, instead of the expected "flat" 2D texture. This was the case when held, in item frames and when dropped.
properties file is inside the pack's: /assets/minecraft/mcpatcher/CIT folder which carries the same name as the PNG file (same as the rest which display right), and contains this:
type=item
items=nether_star
texture=astraea_star.png
nbt.display.Name=pattern:*\u00a74\u00a7lA\u00a7c\u00a7ls\u00a76\u00a7lt\u00a7f\u00a7lr\u00a7b\u00a7la\u00a79\u00a7le\u00a71\u00a7la
Also... crap! I did not want to see that Opti and MCPatcher will not work together
Non-vanilla data values are not supported in 1.8. Period. You'll have to use something else.
Putting the CENDENT back in transcendent!
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumWe just discussed this a page back. The answer is not yet.
Sort of, yea. I mean, generally speaking there is no texture for it and it gets the evil Pink/Black "No Texture" Block of Doom, but it is still functional for everything I need it for, thankfully. (Making unique recipes). It's simply it ends up looking like the attached pic, as apposed to a traditional Nether Star like it should
Maybe when (if?) CIT supports alternate models to go along with the textures, we'll be able to have non-vanilla DV items function how they did prior to 1.8 heh
Thanks
We said we could.
Just make a compound model.
http://hypixel.net/threads/diax-resource-pack.199998/
http://hypixel.net/threads/diax-resource-pack.199998/
-
View User Profile
-
View Posts
-
Send Message
Curse Premium