• 3

    posted a message on [1.8.7 / 1.7.10 and earlier][update 4/23] MCPatcher HD fix 5.0.3
    MCPatcher is updated to 4.3.1 with numerous bugfixes and support for the 1.7.3 prerelease. Note that Mojang changed the way assets are organized. To avoid problems, please ensure your Mojang launcher is up to date (1.3.6 or newer) and start the game at least once from the launcher before using MCPatcher.

    See OP for full list of changes and download links. The main download may not update right away, so try the alternate link if you are still getting the 4.3.0 version.
    Posted in: Resource Packs
  • 2

    posted a message on [1.8.7 / 1.7.10 and earlier][update 4/23] MCPatcher HD fix 5.0.3
    Quote from chumon

    ---- Minecraft Crash Report ---- // Quite honestly, I wouldn't worry myself about that. Time: 12/1/13 8:49 PM Description: Unexpected error java.lang.ArrayIndexOutOfBoundsException: -1 at
    mod_ZanMinimap{0.9.4} [Zan's Minimap] (ZansMinimap1.6.4.zip) Unloaded->Constructed->Pre-initialized->Initialized->Post-initialized->Available->Available->Available->Available

    A known problem with Zan's minimap and MCPatcher. There's a fix in 4.3.1-beta1 but it doesn't work with the forge version unfortunately. I should have both versions working in 4.3.1 final.

    Quote from eleazzaar
    EDIT: Well-- actually it works for the dirt, but any tall grass or ferns planted on the dirt:1 uses that dirt texture too--biome colored. Saplings, flowers, and double tall ferns or grass work as expected.

    Should be fixed in 4.3.1-beta1. Could you confirm, in case I still need to look into this?

    Quote from XSSheep
    Just wondering, are custom skies with the blending mode set to replace supposed to just disappear at the fade out time? They currently don't seem to fade out at all, they just immediately disappear which really looks peculiar and it's sorta stopping me from wanting to use it even though it looks the best.

    Well replace is inherently all-or-nothing, that's kind of what the word means. Maybe you want alpha blending?

    Quote from Kyrodragon
    Something changed with the minecraft launcher a few days ago, which means it isn't looking for things in quite the same directories as before. For me, the solution to this was to copy my launcher_profiles.json and mcpatcher.json files in .minecraft into assets\virtual, after which the fonts return to looking normal. (If this is your problem, your client logs atm should contain an error about the json parser not finding those two files in that directory.) Hope this helps.

    Yes, Mojang retroactively changed the assets directory to assets/virtual/legacy, which confused a lot of things (font spacing, configuration, etc.). Oddly, it didn't break 1.7.3, which I have working in a dev version, but only 1.7.2 and earlier. Fixed for the next release.

    Quote from mmtr1x3
    This is one of the things I'd looked a lot but don't trust anymmore because it stopped working when I have mass convered ressource packs Now I'm currently making a tool to convert any version of texture pack to any more recent one (it's hard to make it but for now there are things like "smooth biome converter that ransform a old-misa-like biome map to a full biome map" that works very well). My aim is to have the ability to convert ressources of old minecraft versions to latest one automaticaly.

    Finally sat down and looked at this. The 1.4 to 1.5 conversion should work in the next release.

    You probably already know this, but for the benefit of others, texture packs can be converted from the command line:
    java -jar mcpatcher-x.y.z.jar -convert15 <path to 1.4 texture pack>
    java -jar mcpatcher-x.y.z.jar -convert16 <path to 1.5 texture pack>

    Quote from ZeroLevels
    Bug Report - MCPatcher 4.3.1 BETA, Minecraft 13w48b: Random CTM for Iron Bars seemingly forces the rendering to change regardless of whether or not you specify any renderpass. Causes you to see both sides of the bars when looking at one side.


    Quote from Killjoy1221
    Is there a huge reason you removed AA for 1.7.2? I understand why for mipmapping and AF, but why AA? The fxaa and antialias filters suck. All they do is make things blurry.

    MCPatcher's mipmapping, AA, and aniso filtering implementation were tied together. When I removed one, I had to remove them all.

    Quote from GoodKingFilms
    With McPatcher the "grass.png" and "foliage.png" dont work properly. I have tested with Minecraft 1.7.2 and McPatcher 4.3.0 and 4.3.1 Beta1

    Disable Smooth biome colors and/or reduce the block blend radius in the Options tab under Custom Colors.
    Posted in: Resource Packs
  • 2

    posted a message on [1.8.7 / 1.7.10 and earlier][update 4/23] MCPatcher HD fix 5.0.3
    Quote from The__Doctor__

    I keep having trouble using the patcher and can't seem to find any help in the log or on the OP.
    I've attached the most recent log below in case anyone else can make sense of it.
    JVM: Oracle Corporation 1.8.0-ea (64 bit)

    I think Java 8 is your problem here. Try using an official Java release instead of a beta.

    Quote from PopuliMinistrum

    It tells you right in your error log why it's not working:
    "WARNING: version is newer than any known version"
    You are using the wrong version, idk if a version for 13w38a is out yet, but 4.3.0 is for 1.7.2

    Like it says, that's only a warning. The Minecraft version is newer than what was released when MCPatcher was built. It means you may experience problems, most likely mods being greyed out because some relevant bit of code changed.

    Quote from The__Doctor__

    If the patcher doesn't support 13w48b (the version I was trying to patch), the author should not advertise that it does.

    I don't change the thread title until I've confirmed that the latest release works with the new snapshot/version. I also compare the patch log with a known good one (ignoring changes in the class mapping).
    Posted in: Resource Packs
  • 2

    posted a message on [1.8.7 / 1.7.10 and earlier][update 4/23] MCPatcher HD fix 5.0.3
    Quote from Kahr

    useSameSeedForMultiblockObjects=true doesn't exactly roll off the tongue, does it? :)

    Gonna go with linked=true for this property. It is per-file, applies only to method=random, and defaults to false. For now it affects only double plants, plants (useful for reeds), and doors.

    Quote from _zombiehunter

    Found a little issue --> swampgrass.png is not applied to double tall grass, it always uses the default color:
    Same problem with large ferns too ...

    Both fixed.

    Quote from Deepblue686

    Using MC Patcher for 1.7.2 crashes minecraft the moment I enter a server.
    1.6.4 is fine. (one server I frequent uses the latest patch, another uses 1.6.4

    The moment I enter a server (or start a singleplayer world), I see the sky and my hand and the game freezes instantly with the cursor showing up.

    No problems with that texture pack here. And unfortunately there's not much in that log to go on either.

    Quote from Dread Boy

    I think I found a bug in CTM in MCPatcher 4.3. I'm trying to write CTM rules for glass in Dandelion texture pack but textures are behaving strangely and it seems rendering depends on orientation.

    This is a vanilla 1.7.2 bug that is fixed in the latest snapshots.
    Posted in: Resource Packs
  • 1

    posted a message on [1.8.7 / 1.7.10 and earlier][update 4/23] MCPatcher HD fix 5.0.3
    Quote from Rayvolution
    Odd request, but could you add a flag that disables this feature? I know it sounds strange, but all of my double tall plants are actually designed to be totally random tops/bottoms (I made sure their middle points all line up).

    Fair point, and that's one of the reasons I wanted to do a beta before making it official. The old behavior (independent tops and bottoms) should probably be the default with an option to turn on the new behavior, just so no one is caught by surprise. I'm just not sure what to call it. useSameSeedForMultiblockObjects=true doesn't exactly roll off the tongue, does it? :)

    Quote from Alvoria
    If you make one extra variation for either the top or bottom, or delete an existing one, that should effectively throw off the matching thing and make it random again. At least, that's my understanding of Kahr's post. &lt;_&lt;

    More precisely, (ignoring the weights property for the moment)

    T = number of top textures
    B = number of bottom textures
    • If T and B are relatively prime: Tops and bottoms are completely scrambled.
    • If gcd(T,B) > 1: Somewhat scrambled, but certain pairings will never occur.
    • If T is an exact multiple of B or vice versa: Each bottom has its own separate set of potential tops (or vice versa).
    • If T = B: Tops and bottoms are always in sync.
    • For weighted lists, just pretend that they're unweighted lists with the textures repeated: tiles=a b c weights=1 2 3 is equivalent to tiles=a b b c c c.
    Yes I was a math major, why do you ask? :)

    Quote from Glimmar
    Actually, how possible would it be to have both the original randomness and the matching ctm type at the same time? Meaning with some unique double plants you might want the top and bottom to match up, whereas with some similar types of double plants you might desire the extra, but limited randomness that we got from pre- 4.3.1-beta1 update.

    You could possibly do it with the divisor trickery above. Or, assuming I make the new behavior optional, by chaining two random CTMs together:

    tiles=rare_top1 rare_top2 dummy_top
    weights=1 1 98
    useSameSeedForMultiblockObjects=true (* name TBD)
    tiles=rare_bottom1 rare_bottom2 dummy_bottom
    weights=1 1 98
    useSameSeedForMultiblockObjects=true (* name TBD)

    dummy_top and dummy_bottom aren't real textures. Their only purpose is to get matched by the next set of rules:

    tiles=random_top1 random_top2 random_top3 random_top4
    tiles=random_bottom1 random_bottom2 random_bottom3 random_bottom4

    Quote from insomniac_lemon
    Ok, so I did a bit more after my reply from before, and got it all set-up and it should work. But, as said before, partial transparency does not work, and rendering order is all screwed up, seemingly even on single blocks (some sides render right, some don't). Here's a link for you to test with: http://www.mediafire...ained_glass.zip

    I think this problem will have to wait until mcp is updated. There's more to Mojang's new transparency handling than I originally thought, but it's too complicated to figure out in obfuscated code.
    Posted in: Resource Packs
  • 2

    posted a message on [1.8.7 / 1.7.10 and earlier][update 4/23] MCPatcher HD fix 5.0.3
    Because of the number of changes in this release with the potential to break something, I'm going to release a beta first. Download MCPatcher 4.3.1-beta1 exe jar.

    • Force consistent coloring and random CTM between top and bottom half of double_plant blocks.
    • Fixed CTM problems with metadata 15.
    • Fixed custom grass, foliage.png always using the vanilla format.
    • Fixed beacon particle effects transparency.
    • Support texture.* syntax in CIT type=enchantment.
    • Added yOffset property to grid format colormap.
    • Fixed Test Minecraft button with 13w47e.
    • Fixed crash with zan's minimap.
    • Fixed transparency issues with 13w47e.
    • Fixed CIT ignoring weight property in some cases.
    • Allow CIT matching of damage as a % of max in addition to an absolute value.
    • Preserve Mojang's hard-coded biome colors for packs with no grass, foliage.png.
    • Fix inconsistent water particle colors.
    • Ignore neighbor's metadata when checking connect=material.
    • New property enableColormap.3 to enable custom colormaps during render pass 3.
    Posted in: Resource Packs
  • 1

    posted a message on [1.8.7 / 1.7.10 and earlier][update 4/23] MCPatcher HD fix 5.0.3
    Quote from thecrazydudesrd

    I found out something about trying "connect=material" with glass and stained glass, It will register with other glass type stuff like the glowstone, it will register with the white glass (meta 0 I believe) but it will not register with other colors. Don't know if they are not set up as 'glass' or if the material property is not working with all metadata values.

    In general, connectedness requires that the two blocks have the same metadata value. I'm considering removing this restriction for connect=material but am unsure if there would be any negative side effects (like block A connecting to block B, but not vice versa).

    Quote from insomniac_lemon

    In 1.7.2/13w47 the flowing/still water and rain splashes are significantly more blue than they should be (but not completely blue as if it was using default CC). Dripping water is fine. Removing the water.png file fixes the coloration but makes dripping water gray.

    Turns out the particle.color property wasn't being used at all since the new colormap system. I've fixed that problem and a few others, so water particles should be colored more consistently now.

    Quote from insomniac_lemon

    Also, Kahr, have you tried anything with the new CC applying to CTM? As I said before, render pass 3 does not work right with 1 layer (it shows regular textures under it), but with 2 layers CC does not recolor the second layer. So to work, it would either need for a "replace" style blending mode, or for CC to recolor all CTM layers on given block.

    Does blend.3=replace work now? Any of the Better Skies blending methods should be recognized.

    I'll look into making colormaps more render pass-aware, which should address the second problem.

    Quote from 13thMurder

    Can someone help me out here? I am trying to control biome shading with the new grid format, but am having no luck getting it working. I think i'm just not understanding the proper file structure. Is there a template anywhere that shows exactly where the files go and what should be in the properties file?

    You're probably not doing anything wrong. There's currently a bug applying the grid format to grass and foliage. You can work around it by setting grid format globally (palette.format=grid in color.properties) or by naming the files something other than "grass" or "foliage".

    Quote from 13thMurder

    Is it possible to make randomized double tall plants cooperate?

    I've changed random CTM so that the top and bottom halves of double plants use the same seed value. If you have the same number of tiles and weights, it should behave consistently.

    tiles=red_bottom green_bottom blue_bottom

    tiles=red_top green_top blue_top

    Quote from Freso

    Alvoria is on the right track. Minecraft simply joins all the texture/resource packs that are enabled, so if a file exists in, say, the 2nd choice, but not the 1st one, it will still be included in Minecraft's "internal resource pack".

    This is exactly right. When the game requests a texture it has no way of knowing which pack it came from. All of that information is abstracted away.

    I'm not sure what the correct behavior should be either. The current behavior works for a base pack + addon packs that are designed to go together. Like a base pack with just vanilla textures, another pack for mods, an MCPatcher addon pack with CTM, Random Mobs, etc., and possibly even additional packs with more CTM variants. But merging two base packs from two different authors is problematic no matter how you do it.
    Posted in: Resource Packs
  • 2

    posted a message on [1.8.7 / 1.7.10 and earlier][update 4/23] MCPatcher HD fix 5.0.3
    Quote from OzGuard345

    When using the default textures, the color of grass gets brighter.
    This happens in the Canyon- and swamp-biome. In another one too, but I can't remember, which one. It is really annoying, because I love the colors of the normal grass-textures, but I don't want to unpatch my game everytime I play with default textures.

    Fixed for next release.
    Posted in: Resource Packs
  • 3

    posted a message on [1.8.7 / 1.7.10 and earlier][update 4/23] MCPatcher HD fix 5.0.3
    Quote from Alvoria

    When I get rid of my "last resort" option, it seems to work normally. It also seems to be working normally for swords, axes, shovels, hoes, and pickaxes... but not for any sort of armor or other tools. :( This is true even for files like the ones that govern the Unbreaking enchantment in my pack, which are applied to anything with that enchantment regardless of its type.

    Ok, at long last I think I figured this one out. Naturally the fix was a one-line change. :)

    Quote from _zombiehunter

    CIT causes this. Just patched 13w47e only with CIT checked in the patcher, the creative menu showed exactly the glitch seen on my screenshot above. Patched the snapshot again with everything except CIT checked, the glitch was gone.[/img]

    Thanks, that helped. Mojang changed the transparency settings yet again. Fixed for next release.

    Quote from camham49

    Umm hi I have an question, when I launch MCpatcher it won't let me pick things like extented HD or connected textures. How do I make these work?

    Quote from TehN00b

    Technical description: java.lang.IllegalAccessError: tried to access field bqh.a from class com.prupe.mcpatcher.TextureAPI

    Both are fixed in the latest version (4.3.0). All the download links in the OP are up to date, but there may be some older links out there on other sites. Please use the OP to ensure you get the latest version.

    Quote from DMagnus

    I'd hazard a guess the 4.3.0 version of Mcpatcher is compatible with the latest snapshot, hence why the title indicates as such.

    Yes, no changes were needed for this week's snapshots. It's been a while since I've been able to say that. There are a few minor glitches that I'm working on, so there will probably be a 4.3.0_01 at some point.
    Posted in: Resource Packs
  • 5

    posted a message on Snapshot 13w47a Ready for Testing!
    By now we've all gotten used to the cycle of Mojang getting distracted from bugfixes to play with a shiny new toy, but they really raised the bar this time. What exactly was the thought process here?

    From a business standpoint, twitch.tv obviously benefits, but what does Mojang get out of it? Is a little ad revenue worth tying their flagship game and their players to another company?

    On the technical side, why make your game dependent on a third-party feature that 99% of players will never use? Some players can't even start the snapshots because the twitch library is missing or crashing. And the timing. They delay a much-needed 1.7.3 to cram in a major new third-party library dependency. One that by necessity must hook fairly deeply into the rendering code. Is it any surprise that we're already up to 13w47e?

    Even the players who do want to stream won't necessarily want to be locked into one streaming service. And presumably the dedicated LPers will continue to post pre-recorded and edited videos, so again I ask, what is the point of this?
    Posted in: Minecraft News
  • 1

    posted a message on [1.8.7 / 1.7.10 and earlier][update 4/23] MCPatcher HD fix 5.0.3
    Quote from Rayvolution

    Of course, I'm sure you know better than most people here just how messy the code is. I'm a java programmer myself, and even though I haven't actually looked at MC's source it's pretty obvious to me, just judging by the filenames they pick for the textures, they have no professional education on java programming. They seem to operate more like advanced amateurs. They seem to just do "eh whatever!" with no regard what so ever to any kind of organizational pattern, industry standard or their own.

    The code's messy in places for sure, but not horrible. I think you touched on a deeper problem though. It's a cycle. They sit down to fix bugs or do other grunt work, get distracted by some "cool" new feature -- this streaming thing being the latest example -- and the community fawns over it. The boring work of fixing/balancing the old stuff gets pushed to the background, piling onto the debt. No one at Mojang seems to be willing to crack the whip, so the backlog gets bigger and even easier to get distracted from next time.

    Quote from _zombiehunter

    Done. The original report is closed, so I made a new one specifically for flowing water: MC-40621 (please upvote this everyone).

    I added my two cents as well. Everyone please upvote this one if you want to see it fixed.

    Quote from _zombiehunter

    What also bothers me is a little graphical glitch on my creative inventory tabs:

    Strange. MCPatcher doesn't even modify the GUI classes, so it must be a side effect of something else. Do you happen to know which MCPatcher feature in particular causes it? I'll check myself later, but it will help me narrow the problem down.

    Quote from Deonyi

    I noticed in some old posts you stated that jukebox CTM does not work after 1.2.5. Does the server send NBT data about the music playing to the client? Perhaps using the way comparators detect it would work.

    I haven't actually looked if anything changed, but the fact that comparators can detect it doesn't mean anything. Like all game logic, that's likely done on the server.
    Posted in: Resource Packs
  • 1

    posted a message on [1.8.7 / 1.7.10 and earlier][update 4/23] MCPatcher HD fix 5.0.3
    So is anyone else not happy with Mojang's "fix" for not being able to see the water surface from underwater? (See MC-34751)

    The setup:




    Quote from Killjoy1221

    Hey, Kahr, I'm using mcpatcher 4.3.0 on 1.6.4 and I'm crashing while using Zan's Minimap on multiplayer.

    This is surprisingly complicated to fix, but I may have something that will work.
    Posted in: Resource Packs
  • 1

    posted a message on [1.8.7 / 1.7.10 and earlier][update 4/23] MCPatcher HD fix 5.0.3
    Quote from Alvoria

    Any luck figuring out why CIT is ignoring weights one some items yet? :huh:

    I found part of the problem at least. It turns out this syntax

    doesn't work for enchantments. It should be fixed now, and it might explain why certain enchantments of yours just weren't working.

    Quote from insomniac_lemon

    Why? Why can't up=up and down=down, what you'd logically assume?

    Well, which would you prefer? Flip the texture upside down, or mentally calculate 255 - y all the time?

    Quote from insomniac_lemon

    I think it would be more useful if this were opposite of how it is..... as in anything underground has a fixed color, and anything above 64 uses the color map.... because you don't generally find grass at lower elevations (in vanilla generation) so the variation is useless there. Maybe the "start" and "stop" elevations could be defined?

    I figured it could be useful for underground strata. But regardless, this feature is more accidental than anything. I could add a yOffset property to do what you suggest though.

    Quote from insomniac_lemon

    Relating, is y-variance based on actual block y-coordinate, or colormap y-coordinate that it should use? Theoretically, if I was to make a 4px high colormap and set y-variation to 4, 2 possible results (too lazy to test this, just figured I'd ask):

    Variance is applied directly to the block y coordinate, before anything else. In pseudocode,
    y = block.y + variance * random(-1, 1)
    if (y < 0)
        y = 0
    if (y > colormapHeight - 1)
        y = colormapHeight - 1
    return map[biomeID][y]

    (It's a bit more complicated. Calculation is done in floating point and linearly interpolates if it's between two integers.)

    So in your example, blocks at 7 or higher would always use the bottom (y=3) pixel.

    Quote from insomniac_lemon

    Can you possibly make <disable backfaceculling>, <disable lightmaps>, and blending their own per-ctm options instead of renderPass features?

    Unfortunately it's a limitation of the renderer. GL options like blending and culling have to apply to the whole render pass, and a block is either in a particular pass or it isn't. This limitation has always been there, but it wasn't an issue until there were suddenly 16 new kinds of glass blocks.

    It's also why depth sorting is such a mess now. Mojang's "fix" for stained glass was simply to turn off writing to the z-buffer during render pass 1. To be fair, doing it right is vastly more complicated, but it still leaves me in a ditch.

    Quote from insomniac_lemon

    Also, a little error here:

    # false: Culling off. Do not render backfacing sides.

    Whoops. Silly double negatives. Fixed.
    Posted in: Resource Packs
  • 3

    posted a message on [1.8.7 / 1.7.10 and earlier][update 4/23] MCPatcher HD fix 5.0.3
    Quote from Alvoria

    Any luck figuring out why CIT is ignoring weights one some items yet? :huh:

    No, not yet.

    Quote from Rayvolution

    I think I figured out what is going on, I don't think CTM is working on stained glass panes at all. After I stripped it down to just the basic CTM, with a basic wireframe (no partial transparency what so ever just a basic CTM border) I realized its only loading the textures in /blocks/, and ignoring my CTM all together.

    I downloaded your pack and took out all the renderPass=2 lines from all 16 glass_*_pane.properties files. Is this how it should look?

    Posted in: Resource Packs
  • 3

    posted a message on [1.8.7 / 1.7.10 and earlier][update 4/23] MCPatcher HD fix 5.0.3
    Quote from Shaillon

    I don't know whether this belongs here or in Misa's thread but I'll post it anyways.
    Black Hardened Clay and White Hardened clay now share the same appearance while all other Colored Hardened Clay blocks remain as they should be.


    Quote from kwerti

    It seems that custom colors on double plants randomly breaks on the tops of the plants at certain times and places.


    Quote from Dracyoshi

    So, quick issue here.I've been trying to get fixed colormaps to work, and I succeeded, but only by making all colormaps fixed by using the global variable in color.properties.


    Quote from Leischii

    Kahr i recognised,that with mcpatcher the mushroomcows don't have mushrooms on their back...I think that's a bug or?


    Quote from eleazzaar

    With v4.3.0 & MC 1.7.2 Iron golems hold out their hands to offer roses/poppies, but the flower is not displayed. This is the same with the default pack as with a texture pack.

    Possibly fixed. I'm pretty sure this is the same as Leischii's problem.

    Quote from Rayvolution

    Glass Panes are still ignoring the new partial transparency added in 1.7, but only when you load a resource pack that uses Better Glass (even if Better Glass isnt even applied to the block!)

    Regular CTM .properties file
    tiles=0-11 12-23 24-35 36-46

    Render pass 2 isn't supposed to support transparency. It only differs from render pass 0 in that it disables backface culling. Use render pass 1 instead.

    Here are the render passes in the order they happen in-game:

    0: On/off transparency, with backface culling (vanilla)
    2: On/off transparency, without backface culling (added by Better Glass)
    1: Transparent blocks with alpha blending and no depth sorting (vanilla)
    3: Transparent blocks with customizable blending (added by Better Glass)

    When you put renderPass=n in a ctm properties file, you are assigning the block a new render pass, either by replacing (0-2) or adding (3).

    If I'm not mistaken there's no reason to use render pass 3 anymore unless you need finer control over the blending method.

    Quote from _zombiehunter

    On my side, sugarcanes randomly fail to connect, see screenshot:

    Fixed. Related to the black/white stained clay bug it turns out.

    Quote from Alvoria

    With MCPatcher installed, the particles that surround the player when under the effect of a potion are completely opaque. This happens even when under the effect of a beacon, where the particles are barely visible in vanilla.

    Posted in: Resource Packs
  • To post a comment, please .