Did anyone else notice the luminosity change in the glowstone recently?
A few days ago, I was running Minecraft on snapshot 14w06b when I tried out a new glowstone texture I made, and was VERY pleased with it! It looked REALLY luminous--I loved the way it actually looked lit up. I was quite proud of myself. The next day, I updated to snapshot 14w08a, and the luminosity was completely gone! The glowstone still gives off the same amount of light, but the block itself just doesn't look nearly as luminous. All I did was update the client and the patcher. Anyone know what happened?
EDIT: I am wondering if maybe the odd luminosity I liked so much may have been a bug itself--but even if it was I'd like to try and get it back!
14w06b:
14w08a:
Probably glowstone used to have ambient occlusion off in its model, but has it on in the current snapshot.
Ahh, thank you. Mousing over Connected Textures it says:
"requires __BlockAPI, which cannot be applied
RenderBlockCustom: no classes matched (best match: bsz.class, 2 signatures)"
My friend's server uses the snapshot 14w06b so perhaps it's that version that's making things funky? I know Optifine sure didn't want to work on that server when I tried it.
Any ideas on where to go from here?
Well, maybe. If you're actively trying to patch 14w06b and CTM is grayed out, then it might not quite be compatible, especially since it seems the class file CTM modifies doesn't exist anymore, according to the notification. But, to be clear, are you trying to patch the client version of Minecraft, or the server.jar? If the latter, then that might be your problem right there, MCpatcher isn't exactly designed to patch the server. But, if that's not the case then it may just simply be it doesn't agree very well with 14w06b.
Probably glowstone used to have ambient occlusion off in its model, but has it on in the current snapshot.
Ooh, a term I haven't heard before! How exciting. What is ambient occlusion? Can I change it for the glowstone in my texture pack using any of the Patcher mods?
Thanks for the tip!
Well, maybe. If you're actively trying to patch 14w06b and CTM is grayed out, then it might not quite be compatible, especially since it seems the class file CTM modifies doesn't exist anymore, according to the notification. But, to be clear, are you trying to patch the client version of Minecraft, or the server.jar? If the latter, then that might be your problem right there, MCpatcher isn't exactly designed to patch the server. But, if that's not the case then it may just simply be it doesn't agree very well with 14w06b.
Yeah, client version here. Bummer! Custom Colors and Better Glass don't work for the same reason but I wasn't too concerned with those. Everything else seems to be okay. I'll just have to wait and see if in the future my friends will change up the version they're on. Thanks for the help!
Ooh, a term I haven't heard before! How exciting. What is ambient occlusion? Can I change it for the glowstone in my texture pack using any of the Patcher mods?
Thanks for the tip!
Ambient occlusion is basically smooth lighting, and the "shadows" that appear on certain blocks to make them look 3D. Glowstone, despite being a light source, does cast these shadows (transparent blocks like stained glass do not). The glowstone block probably got overlooked when Mojang made the models, and somehow the bottom face got a brightness value of 1.0 instead of 0.5.
Bug report.
With mcpatcher 4.3.2 and minecraft 1.7.5, ctm doesn't work on beacons, torches and brewing stands.
As far as I know, CTM has never worked on these blocks. The beacon and brewing stand need to use matchTiles, and torches...well, torches just can't be CTM'd.
Yeah, client version here. Bummer! Custom Colors and Better Glass don't work for the same reason but I wasn't too concerned with those. Everything else seems to be okay. I'll just have to wait and see if in the future my friends will change up the version they're on. Thanks for the help!
Yeah, that definitely sounds like an incompatibility with the snapshot if Custom Colors and Better Glass are greyed out too, so your friends'll have to change the version they use or Kahr'll have to address the incompatibility. But, either way, glad to have been of aid. :3
Ambient occlusion is basically smooth lighting, and the "shadows" that appear on certain blocks to make them look 3D. Glowstone, despite being a light source, does cast these shadows (transparent blocks like stained glass do not). The glowstone block probably got overlooked when Mojang made the models, and somehow the bottom face got a brightness value of 1.0 instead of 0.5.
Not sure if it's important, but it wasn't just one face--it was the whole block. I even laid a wall of them out to double check the tiling of the texture, and all sides of it looked great. It glowed so beautifully!
Do you think it's possible for me to change it back to its lovely glowing state?
Alright, I'm trying to do the thing where I randomize each tile of the horizontal connected texture bookshelves. I'm starting with the non-connected bookshelf (tile 3.png of the horizontal CTM texture). I've got the base textures for the horizontal CTM in "assets\minecraft\mcpatcher\ctm\bookshelf" and inside that folder is another folder called "single" where the randomized tiles for tile 3 are kept. There are two randomized tiles so far, 0.png and 1.png. The properties file for that randomization is also in the "~\ctm\bookshelf\single" folder, and is titled "single.properties". The properties reads thusly:
For some reason, all instances of tile 3 are still showing as just the base horizontal CTM texture with no randomization. What am I doing wrong?Also, in case its relevant, tile 3.png (the base texture) is animated.
try using the normal "/" and start from mcpatcher folder in matchTiles instead of using matchBlocks:
also you can add tile 3 to the tileslist, so that it will also appear sometimes
Still not working. Also: Tile 3 is already part of the tileset.
Just thought I'd ask this again, since it appears to have gotten lost in the deluge and rapidly approaching forgotten as well, and I'd really rather get it over with before putting it behind us. Then it can be lost and forgotten again.
Hello there. I want to ask, is it possible to patch a modpack from Feed The Beast with McPatcher ? I am using sphax and it has some cool random and ctm textures but if it is not patched I can't use it. Optifine doesn't work because 1-st - it crashes with the pack and 2-nd - It causes gliches.So yeah is it possible to patch ftb ? If not, is there another program that does that ? Thank you.
I made a small program that extracts the things mcpatcher adds to the jar and puts it in a new one in the form of a library. Right now, it can't tell if forge is installed, but it won't matter if you're just going to move the library into FTB. I may package it in a bit.
Not sure if it's important, but it wasn't just one face--it was the whole block. I even laid a wall of them out to double check the tiling of the texture, and all sides of it looked great. It glowed so beautifully!
Do you think it's possible for me to change it back to its lovely glowing state?
Yes, then it was definitely ambient occlusion, or rather, the lack of it (it's actually the "shade" property in the model file, not the actual "ambientOcclusion"). And no, there is no way currently to change glowstone back, not unless you want every other cube-model block to have the same lighting.
http://www.mediafire...ackager-1.0.jar
Just select your mcpatcher jar and it will do the rest. When it finishes, it will tell you where it put it. Usually in .minecraft/libraries/com/prupe/mcpatcher/version-mcversion/.
You should just need to put that in the instmods folder of ftb. I haven't tested it thoroughly, so you may need to change the extension to .zip. You also still need to add "-Dfml.ignorePatchDiscrepancies=true -Dfml.ignoreInvalidMinecraftCertificates=true" to your jvm arguments.
If you're on Mac/Linux, tell me if it finds your minecraft directory.
Edit: If you have issues where the library wasn't created, redownload. It was because I didn't create the directory before the file.
Edit 2: I don't think FTB supports instmods anymore, so you'll have to add it as a library. Copy .minecraft/libraries/com/prupe into ftb/libraries/com/. Then edit modpack.json in your modpack's mcdirectory to add mcpatcher to the libraries section. I suggest you learn how to write JSON. It's super easy. If it doesn't work, you did it wrong.
With the new 1.8 blocks, when i try to use multiple ctm methods per block, or off the output of another ctm method, it doesn't work.
For example, with smooth granite, i am trying to use vertical ctm, but make each vertical tile repeat horizontally, then have a seperate texture for the top/bottom faces. Only the base vertical ctm is working. It won't repeat, and it won't apply the face specific ctm.
I've done used this method for many other blocks without issue.
Is this a known issue? Or am i likely just doing something wrong in the .properties files?
OMG!!! Yes!!! You did it! ))) You finally fixed that mess with Forestry fluids))) I am so happy now... (removing Optifine to the trash can, where it belongs) Thank you! Thank you so much!
Did you use the repaker that killjoy provided ? If yes how did you do it so that it work, like what did you do?
Just have downloaded latest version of Mcpatcher, available at the main page. Just have runned it, upon forge 965 version. Playing MC 1.6.4, opsys - Win 7
All wuz simple)
OK, ftb doesn't support instmods for 1.6 packs, so you'll need to add mcpatcher as a library. The json is in your modpack game directory named either modpack.json or pack.json.
Kahr, I'm very glad you fixed the bug with Mekanism. But from mcpatcher-4.3.1_01 to mcpatcher-4.3.2, all glass and iron fence blocks of the resource pack I use (http://www.planetminecraft.com/texture_pack/aeon-1355543/) and a few others became completely invisible or renders white.
Reported earlier, renderPass 2 and 3 aren't currently working with Forge. Another instance where we both modify the exact same line of code and it requires some tricky merging on my part. Fixed for next release.
I know that this has probably been requested before (by me, perhaps), and there are still lots of bugs that people are reporting, but adding the ability to make custom skies biome-specific would be a god send.
The problem with that is keeping so many large skybox textures in memory at once in order to smoothly transition between them.
So it seems that the random mobs feature is selecting a random colour for my animals each time the chunk is loaded, not just the first time! Is this supposed to happen?
Ah, I've tried several times and never been able to nail this bug down since the SSP/SMP merge. In singleplayer it's supposed to save the skin used to the NBT data when it saves the chunk. And it worked perfectly in 1.2 and still mostly works now. But not always as you've noted.
For multiplayer, it's more complicated, but as long as the chunk stays loaded on the server it should get the same skin each time until it is rebooted. That's the best that can be done without patching the server code.
Well, maybe. If you're actively trying to patch 14w06b and CTM is grayed out, then it might not quite be compatible,
I probably broke compatibility with 14w06b when I updated to 14w08a. The custom block model code changed so much between the two versions (and again in 14w10, which I'm currently dealing with) that it no longer recognizes one of the classes. I'll see if there's an easy fix, but no promises.
Just thought I'd ask this again, since it appears to have gotten lost in the deluge and rapidly approaching forgotten as well, and I'd really rather get it over with before putting it behind us. Then it can be lost and forgotten again.
I made a small program that extracts the things mcpatcher adds to the jar and puts it in a new one in the form of a library. Right now, it can't tell if forge is installed, but it won't matter if you're just going to move the library into FTB. I may package it in a bit.
Interesting, but if I'm understanding this right, don't you still have to install Forge via MCPatcher and use that patched jar as input to your program for this to work? Otherwise none of Forge's base class changes will be in the library.
For example, with smooth granite, i am trying to use vertical ctm, but make each vertical tile repeat horizontally, then have a seperate texture for the top/bottom faces. Only the base vertical ctm is working. It won't repeat, and it won't apply the face specific ctm.
Quick question since block ids are being phased out entirely is it possible to specify renderpass with MatchBlocks or MatchTiles?
matchBlocks yes, matchTiles no. I would strongly recommend getting out of the habit of relying on naming your files block###.properties though. There's no telling when Mojang will remove the last vestiges of numerical IDs.
java.lang.ArrayIndexOutOfBoundsException: 12
at com.prupe.mcpatcher.cc.ColorizeBlock.setupBiomeSmoothing(ColorizeBlock.java:494)
at com.prupe.mcpatcher.cc.ColorizeBlock.setupBlockSmoothing(ColorizeBlock.java:470)
I think there is a bug here as that "connect=block" shouldn't be necessary. I'll look into it more.
More or less. By repeat horizontally i meant repeat ctm, but in a single block high multiple block wide horizontal pattern.
Also, just plain repeat ctm with "faces=top bottom" not relying on the output of another properties isn't working either.
All of my plank textures use all of these ctm methods together with no problem. I've never heard of "connect=block" before, but i'll give it a try and let you know what happens. Thanks
Edit: I just tried it. Unfortunately adding "connect=block" had no effect.
Probably glowstone used to have ambient occlusion off in its model, but has it on in the current snapshot.
Putting the CENDENT back in transcendent!
Well, maybe. If you're actively trying to patch 14w06b and CTM is grayed out, then it might not quite be compatible, especially since it seems the class file CTM modifies doesn't exist anymore, according to the notification. But, to be clear, are you trying to patch the client version of Minecraft, or the server.jar? If the latter, then that might be your problem right there, MCpatcher isn't exactly designed to patch the server. But, if that's not the case then it may just simply be it doesn't agree very well with 14w06b.
Ooh, a term I haven't heard before! How exciting. What is ambient occlusion? Can I change it for the glowstone in my texture pack using any of the Patcher mods?
Thanks for the tip!
Yeah, client version here. Bummer! Custom Colors and Better Glass don't work for the same reason but I wasn't too concerned with those. Everything else seems to be okay. I'll just have to wait and see if in the future my friends will change up the version they're on.
Ambient occlusion is basically smooth lighting, and the "shadows" that appear on certain blocks to make them look 3D. Glowstone, despite being a light source, does cast these shadows (transparent blocks like stained glass do not). The glowstone block probably got overlooked when Mojang made the models, and somehow the bottom face got a brightness value of 1.0 instead of 0.5.
As far as I know, CTM has never worked on these blocks. The beacon and brewing stand need to use matchTiles, and torches...well, torches just can't be CTM'd.
Putting the CENDENT back in transcendent!
Yeah, that definitely sounds like an incompatibility with the snapshot if Custom Colors and Better Glass are greyed out too, so your friends'll have to change the version they use or Kahr'll have to address the incompatibility. But, either way, glad to have been of aid. :3
Not sure if it's important, but it wasn't just one face--it was the whole block. I even laid a wall of them out to double check the tiling of the texture, and all sides of it looked great. It glowed so beautifully!
Do you think it's possible for me to change it back to its lovely glowing state?
Probably we are having some issues with glass rendering: http://www.minecraftforum.net/topic/1496369-14w08a-175-172-164-and-earlierupdate-227-mcpatcher-hd-fix-432/page__st__10160#entry29399883
EDIT:
My solution was downgrade MCPatcher a version back.
EzerArch.com | Armourer's Workshop Skins | MCHeli Content Pack Addons | Resource Packs | YouTube | G+ | Twitter
Just thought I'd ask this again, since it appears to have gotten lost in the deluge and rapidly approaching forgotten as well, and I'd really rather get it over with before putting it behind us. Then it can be lost and forgotten again.
Also check me out on:
WordPress, Etsy, and Spore.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI made a small program that extracts the things mcpatcher adds to the jar and puts it in a new one in the form of a library. Right now, it can't tell if forge is installed, but it won't matter if you're just going to move the library into FTB. I may package it in a bit.
Mods I work on and maintain:
TabbyChat | Mine Little Pony
My Blog
Yes, then it was definitely ambient occlusion, or rather, the lack of it (it's actually the "shade" property in the model file, not the actual "ambientOcclusion"). And no, there is no way currently to change glowstone back, not unless you want every other cube-model block to have the same lighting.
Putting the CENDENT back in transcendent!
-
View User Profile
-
View Posts
-
Send Message
Curse Premiumhttp://www.mediafire...ackager-1.0.jar
Just select your mcpatcher jar and it will do the rest. When it finishes, it will tell you where it put it. Usually in .minecraft/libraries/com/prupe/mcpatcher/version-mcversion/.
You should just need to put that in the instmods folder of ftb. I haven't tested it thoroughly, so you may need to change the extension to .zip. You also still need to add "-Dfml.ignorePatchDiscrepancies=true -Dfml.ignoreInvalidMinecraftCertificates=true" to your jvm arguments.
If you're on Mac/Linux, tell me if it finds your minecraft directory.
Edit: If you have issues where the library wasn't created, redownload. It was because I didn't create the directory before the file.
Edit 2: I don't think FTB supports instmods anymore, so you'll have to add it as a library. Copy .minecraft/libraries/com/prupe into ftb/libraries/com/. Then edit modpack.json in your modpack's mcdirectory to add mcpatcher to the libraries section. I suggest you learn how to write JSON. It's super easy. If it doesn't work, you did it wrong.
"libraries":[ { "name": "com.prupe:mcpatcher:<patcherversion>-mc<mcversion>" },I'm wanting to make another program to easilly edit the json in any version in the default and ftb launcher. Technic is more complex.
Mods I work on and maintain:
TabbyChat | Mine Little Pony
My Blog
-
View User Profile
-
View Posts
-
Send Message
Retired StaffWith the new 1.8 blocks, when i try to use multiple ctm methods per block, or off the output of another ctm method, it doesn't work.
For example, with smooth granite, i am trying to use vertical ctm, but make each vertical tile repeat horizontally, then have a seperate texture for the top/bottom faces. Only the base vertical ctm is working. It won't repeat, and it won't apply the face specific ctm.
I've done used this method for many other blocks without issue.
Is this a known issue? Or am i likely just doing something wrong in the .properties files?
Just have downloaded latest version of Mcpatcher, available at the main page. Just have runned it, upon forge 965 version. Playing MC 1.6.4, opsys - Win 7
All wuz simple)
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumMods I work on and maintain:
TabbyChat | Mine Little Pony
My Blog
This is already fixed in 4.3.2.
Reported earlier, renderPass 2 and 3 aren't currently working with Forge. Another instance where we both modify the exact same line of code and it requires some tricky merging on my part. Fixed for next release.
The problem with that is keeping so many large skybox textures in memory at once in order to smoothly transition between them.
Good catch, switching from a pack with redstone.png to one without doesn't clear out the old colors. That bug's probably been there since 1.5. Fixed.
Ah, I've tried several times and never been able to nail this bug down since the SSP/SMP merge. In singleplayer it's supposed to save the skin used to the NBT data when it saves the chunk. And it worked perfectly in 1.2 and still mostly works now. But not always as you've noted.
For multiplayer, it's more complicated, but as long as the chunk stays loaded on the server it should get the same skin each time until it is rebooted. That's the best that can be done without patching the server code.
I probably broke compatibility with 14w06b when I updated to 14w08a. The custom block model code changed so much between the two versions (and again in 14w10, which I'm currently dealing with) that it no longer recognizes one of the classes. I'll see if there's an easy fix, but no promises.
Not going to spend a lot of time on these. As of 14w10, glass pane rendering is completely out of my hands, so these issues are basically moot.
Good god, why not use method=fixed?
The default method if you don't specify is "ctm", which is why it expects 47 tiles.
This is working for me (4.3.2 + 14w08a & 1.7.5):
Interesting, but if I'm understanding this right, don't you still have to install Forge via MCPatcher and use that patched jar as input to your program for this to work? Otherwise none of Forge's base class changes will be in the library.
Is this what you're trying to do?
I think there is a bug here as that "connect=block" shouldn't be necessary. I'll look into it more.
matchBlocks yes, matchTiles no. I would strongly recommend getting out of the habit of relying on naming your files block###.properties though. There's no telling when Mojang will remove the last vestiges of numerical IDs.
Fixed.
Fixed.
-
View User Profile
-
View Posts
-
Send Message
Retired StaffMore or less. By repeat horizontally i meant repeat ctm, but in a single block high multiple block wide horizontal pattern.
Also, just plain repeat ctm with "faces=top bottom" not relying on the output of another properties isn't working either.
All of my plank textures use all of these ctm methods together with no problem. I've never heard of "connect=block" before, but i'll give it a try and let you know what happens. Thanks
Edit: I just tried it. Unfortunately adding "connect=block" had no effect.