• 1

    posted a message on [1.8.7 / 1.7.10 and earlier][update 4/23] MCPatcher HD fix 5.0.3
    EDIT: Updated to 4.3.2_01 with bugfixes and compatibility up to 14w11b.

    Also, these are the default colors for Endermite spawn eggs:
    egg.shell.Endermite=161616
    egg.spots.Endermite=6e6e6e


    Quote from markacashion

    Kahr, I am wondering if a feature like the "Connect Block Models" is possible? It would basically be like CTM, but for the new custom models feature in vanilla Minecraft.

    It is possible, and I'd like to do something eventually, but it will have to wait until Mojang stabilizes the the model json format. I know it's frustrating that we have custom models, but the mapping from blocks and metadata values to models is still hardcoded.

    Quote from markacashion

    Edit: I think found a bug by using the new launcher(4.3.2), it does some weird stuff with "matchTiles=" rules for some reason(tested with 1.7.2 & 1.7.5), but the old launcher(4.3.1_01) doesn't(tested with 1.7.2).

    Ex.: Beacons(their center texture) don't work, End portal frames don't connect unless they are exactly the same(they only connect if they are placed facing the same direction & whether or not they have a eye of ender in them or not). If you use the "matchTiles=" rule or name the .properties file the name of the texture you want to change (ex.: endframe_side.properties) it will some times work, but other times not.

    Could you try these again in 4.3.2_01?
    Posted in: Resource Packs
  • 2

    posted a message on Is the MOD API actually being developed?
    Quote from Wanderer

    I can only imagine

    Taken literally, I would say that is exactly the problem. After four years of alleged development we still "can only imagine"! There's still no overall roadmap for this API or even any indication that Mojang has one. As far as anyone can tell, there is no designer in charge there, just a bunch of coders making it up as they go along.

    Your post could have been written a year ago, with different examples: splitting tilesheets into separate textures, resource packs, or even further back, the client-server merge. Obviously those things didn't result in a finished API, and there's no reason to expect your list to be any different.

    Quote from Wanderer

    I don't know what to tell you except to, I don't know, find a new hobby? Wait it out for a while. Another year should be more than enough time.

    And people who do that probably won't come back. There are plenty of other projects out there for talented modders to apply their skills to. It's Mojang's problem if they release an API to an audience of 0.
    Posted in: Recent Updates and Snapshots
  • 7

    posted a message on [1.8.7 / 1.7.10 and earlier][update 4/23] MCPatcher HD fix 5.0.3
    Thanks for the kind words everyone, but let's drop the MCPatcher vs. Optifine stuff before it gets out of hand. I do want to comment on this though.

    Quote from Killjoy1221

    Could be if kahr implemented ITweaker.

    That's much easier said than done. For those who want the gory details, I'll just paste my reply to a PM asking about the same thing:
    It's not the use of Javassist that worries me. It's the way MCPatcher does its own deobfuscation and reobfuscation. As I understand it, FML relies on fixed mappings, which means it has all the information it needs for each class as soon as the class loader calls for it. MCPatcher often won't know what to do with, say, abc.class until it sees cba.class, which may not even be loaded yet. It takes multiple passes over the entire jar file to fully resolve these cross-dependencies before patching can begin.

    While this problem isn't unsolvable, it's a lot more complicated than I want to deal with. If you run into a situation where you can't resolve a particular class, say in a new snapshot, what do you do? Today I can just grey out that feature in MCPatcher's UI, but when you're in the middle of starting the game, an unceremonious crash is about your only option.

    Of course you could sidestep the issue by using fixed mappings. That ties you to one specific version of Minecraft, though, and defeats much of the purpose of MCPatcher's system. You couldn't necessarily use MCP's either, since I often have to name things well before any MCP release. (I already have mappings for several new 1.8 classes for example).


    Anyway, I wanted to show this:
    It may not look like much, but it's taken me days to get CTM working on rotated logs and pillars again after the last snapshot. What's nice is that there's no more special-case code for these blocks anymore. The models have all the information I need to tell me when the "top" face is actually on the north, etc.
    Posted in: Resource Packs
  • 2

    posted a message on Is the MOD API actually being developed?
    Quote from Debugman18

    There has been work done on the API itself, and plenty of it. Block models, refactoring, the SMP/SSP merge, command blocks, the change of block data mentioned here; a lot of changes. Many under the hood changes as well. Not just preparation, but factual observable changes.

    These "factual observable changes" aren't in dispute. Their relevance to the API is.

    Block models. Tell me how to add an entirely new model to the game, not merely replace an existing one. As it stands, block models are no more relevant to an API than terrain.png was in 2010.

    Refactoring. An ongoing process that is necessary with or without an API. It's not something you "finish".

    SSP/SMP merge. That was 18 months ago! See also: refactoring.

    Command blocks. They can't do anything most relevant to modders: Add new blocks or items, modify AI or terrain generation, or add new dimensions for example. May as well count redstone circuitry as work toward the API.


    The two fundamental barriers to modding have always been:
    1. Getting your code to run inside the game. There are no built-in hooks that cause vanilla Minecraft to call external code, so changing anything in the game requires overriding or modifying (obfuscated) base classes.
    2. Even when you solve #1, in order for your code to do anything useful, it has to reference (again, obfuscated) base classes and methods. Since the names change with every update even when the interface is functionally the same, you have nothing to compile against.
    Third-party tools like MCP and Forge have been developed at great effort to deal with these problems. But from Mojang? Nada.

    To me, "working on the API" means substantially addressing at least one of those two critical problems. But as far as I can tell, not one single line of code has been written toward either one. None of Mojang's changes even hint at how they might decide to solve them someday in the future. Nothing tells me how I should structure my code today to ease porting it to the official API when it arrives.

    All of the official channels Mojang started to discuss the API are utterly dead, leaving the community to mine Twitter feeds for minute particles of information. It is unbelievable that after four years we're still at this point.
    Posted in: Recent Updates and Snapshots
  • 2

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

    The last thing it says is "Minecraft exited with status 1".

    This is already fixed in 4.3.2.

    Quote from EzerArch

    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.

    Quote from Drazile12

    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.

    Quote from kwerti

    Also, custom colors doesn't seem to be re-loading properly for redstone, when switching resource packs.

    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.

    Quote from NekoEmmi

    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.

    Quote from DMagnus

    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.

    Quote from Merilix

    Missed half pane tops on the bottom left and right panes

    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.
    Quote from Merilix

    matchBlocks=glass_pane
    tiles=99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 
    renderPass=3


    Good god, why not use method=fixed?
    matchBlocks=glass_pane
    tiles=99
    method=fixed
    renderPass=3

    The default method if you don't specify is "ctm", which is why it expects 47 tiles.

    Quote from BrokenEye

    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.

    This is working for me (4.3.2 + 14w08a & 1.7.5):
    assets/minecraft/mcpatcher/ctm/bookshelf/bookshelf.properties:
    matchBlocks=bookshelf
    faces=sides
    method=horizontal
    tiles=0-3
    
    assets/minecraft/mcpatcher/ctm/bookshelf/variant1.properties:
    matchTiles=~/ctm/bookshelf/1.png
    method=random
    tiles=4-7


    Quote from Killjoy1221

    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.

    Quote from 13thMurder

    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.

    Is this what you're trying to do?
    ~/ctm/granite/base.properties:
    matchBlocks=stone:2
    method=vertical
    faces=sides
    tiles=0-3
    
    ~/ctm/granite/variant1.properties:
    matchTiles=~/ctm/granite/1.png
    method=horizontal
    faces=sides
    tiles=4-7
    connect=block

    I think there is a bug here as that "connect=block" shouldn't be necessary. I'll look into it more.

    Quote from Balthasarx

    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.

    Quote from Bastikeks

    java.lang.ArrayIndexOutOfBoundsException: 12
         at com.prupe.mcpatcher.cc.ColorizeBlock.setupBiomeSmoothing(ColorizeBlock.java:494)
         at com.prupe.mcpatcher.cc.ColorizeBlock.setupBlockSmoothing(ColorizeBlock.java:470)


    Fixed.

    Quote from darchangel89

    Im using 1.7.5 version 4.3.2 and iron bar textures arent rendering correctly. They work fine in vanilla, but not once I run MCpatcher

    Fixed.
    Posted in: Resource Packs
  • 0

    posted a message on Is the MOD API actually being developed?
    Quote from Milikeny

    You should learn to appreciate it for the rare gem that it is, and quit complaining

    Quote from Milikeny

    If you don't like this, you can complain, you can boycott,

    Glad we cleared that up.
    Posted in: Recent Updates and Snapshots
  • 2

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

    My renderpass=2 ctm is still showing up as invisible in Forge 1024.

    Fixed.

    Quote from Steelfeathers

    Okay, wow, just downloaded MC patch 4.3.2 and used it to patch a fresh copy of 1.7.5, but even on a brand new world my game crashes as soon as I start minecraft. Help?

    Kind of hard to help without a crash log.

    Quote from Glimmar

    I'm having problems with my new random ctm'd 'grass_side_overlay' since updating to MC 1.7.5 using MCPatcher 4.3.2. The grass overlay has just completely disappeared!

    Fixed.

    Quote from asikar

    I'm using MCPatcher on a forge modded survival world and I've run into some problems with BuildCraft. The pump and quarry arms aren't showing up properly. I've got HD textures for the mod as well but even without the HD textures this still happens.

    This is working for me in 4.3.2. Are you still having the problem after updating?

    Quote from kwerti

    The sugar cane CTM bug is back.

    Can't reproduce this, but I may know where the problem is.

    Quote from shaone

    zero insight into the issue I reported, removed MCpatcher and started using optifine. Problem solved and no more issues with connected textures.

    The bug you reported was fixed a day later.
    Posted in: Resource Packs
  • 4

    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.2 with support for 1.7.5 and 14w08a. See OP for download links and list of changes.
    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 13thMurder

    The stone would be rendered twice? I'm not sure i understand... i mean, i understand why the ores would because there are 2 layers, but why would the stone itself be rendered twice?

    You're right. I misread.

    Quote from BaseCrusher

    is there a way that you can add a feature that makes the texture of baby mobs other then the normal ones?

    When 1.8 settles down, I can start thinking about new features again. Right now every new feature is just more work the next time Mojang pulls the rug out from under everyone again.

    Quote from Bastikeks

    Can you have a look at the ctm-gets not-applied-when-.properties-names-are-the-same-bug i posted under the logfile?

    I'm looking into it. I think it is being applied, but the order of application is indeterminate if they have the same filename.

    Quote from Killjoy1221

    Has anyone else had the issue with mcpatcher 4.3.1_01 and forge 1024 where iron bars are invisible using a resource pack besides default?

    This should be fixed in 4.3.2-beta2. Could you confirm?

    Quote from MasterfulGamer

    From time to time my game crashes and I don't know why. Here's the crash report:

    java.lang.ClassCastException: xc cannot be cast to xq
    ...
    Server brand: craftbukkit

    xc is EntitySkeleton and xq is EntityPlayer. I'd say it's MC-38077. Is your server running the MobDisguise plugin mentioned in the comments?

    Quote from MGassailant

    I'm currently using MCPatcher on 1.6.4 just for "Minecraft Forge" and "Connected Textures. But It seems like the fluids in Buildcraft tanks don't render the liquid when its connected to pipes with gates, nor do the gate icons appear (although they still function). Is there any work around for this. The moment I remove the "Connected Textures" function, the fluids and pipe icons appear correctly, so I'm guessing connected textures has to do with the Buildcraft rendering.

    I've fixed a number of forge-related bugs lately that were causing problems like this, so there's a good chance it will work in the next release.

    Quote from Bastikeks

    Get a confusing issue with the custom compass/dial-animation.
    I applied a custom compass (with more than 2 layers) to my pack which works fantastic. but when i put it in an itemframe, the custom animation disappears and the vanilla-compass is rendered instead.

    Fixed for next release.

    The outputFrames option should create a file called custom_<clock,compass>.png in the .minecraft folder. There is a problem where the red/blue channels are swapped, which I've already fixed, but that shouldn't prevent the file from being written altogether. If you have set a custom game directory in the launcher it may have ended up there, however.

    Quote from Taiine

    Mojang has stated thay don't want people to be injecting stuff directly into the .jar for the game. Many launchers like MMC5 wont even run the game if it detects any edits to the .jar file.

    Has Mojang actually stated this or are people just inferring it from something else?

    The vanilla launcher does run modified jars, so I don't feel any obligation to go out of my way for a third-party launcher that doesn't.
    Posted in: Resource Packs
  • 0

    posted a message on Is the MOD API actually being developed?
    Quote from skinny121

    Since 1.3 SSP and SMP are the same, as SSP uses an internal server, nearly everything is done on the server know anyways, only rendering and other UI stuff as well as some prediction stuff i think(which i don't know how they are going to deal with). They have been rewriting the system since the SSP/SMP merge.

    "Only" rendering includes quite a lot actually. In MCP terms, block.colorMultiplier and block.getIcon are client-side methods that are commonly overridden by subclasses for example. Moving these calculations to the server would require another rewrite on the scale of the original SSP/SMP merge, with the result of adding still more load on the server and increasing the amount of traffic going to each client.

    So, realistically, if modders are to add new blocks to the game, they will need a way to override those client-side methods too. I have to agree with Zeno410. A server-only API will either be severely limited or never see the light of day.
    Posted in: Recent Updates and Snapshots
  • 3

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

    Is there any way to make top and bottom textures connect in a straight line?

    Currently, no, but I'll see what I can do.

    Quote from 13thMurder

    I want to do a massive repeat ctm sheet for stone, 12x12 or so. 144 tiles... it's kind of a lot. Rather than adding 1008 more tiles in for all the ores and making my pack absolutely massive (well, more than it is already) i thought i might just do up properties files for the ores that direct it to use the same repeat ctm as the stone, then do some random ctm ores to apply over the top of that with renderpass 3.

    Yeah, performance would definitely be a consideration there. Each stone block, of which there are many, would have to be rendered twice. I would measure your fps with and without it and maybe consider releasing it as a separate addon pack if it's too much.

    Quote from Bastikeks

    ---- Minecraft Crash Report ----
    // Why did you do that?
    Time: 22.02.14 03:19
    Description: Rendering item
    java.lang.ArrayIndexOutOfBoundsException: 60
    at ajp.g(SourceFile:164)
    at alj.f(SourceFile:613)
    at bsa.a(SourceFile:1008)
    at bru.a(SourceFile:110)
    at bru.a(SourceFile:77)
    at bru.a(SourceFile:150)


    Well that was a strange bug. It was crashing in the chunk cache while rendering an anvil. Fixed for next release.

    Quote from EzerArch

    @Kahr: I'm having an issue with MCPatcher and Mekanism: Mekanism pipes render completely black if run with MCPatcher.

    Turns out to be the same bug that Mr_Oyster_Meister reported with Thermal Expansion. Glad I was finally able to track that one down.

    Quote from OriAlon

    another small bug I found:
    connected texture for sugar canes works on patched 1.7.4 but not on a patched 14w07a

    Tentatively fixed. Read on if you want the gory details of this tricky problem.


    The root cause of this is in the model definition file sugarcane.json:
            {   "type": "plane",
                "from": [ 0, 0, 8 ],
                "to": [ 16, 16, 8 ],
                "uv": [ 0, 0, 16, 16, "down" ],
                "facing": "south",
                "tint": true,
                "rotation": [ 0, 45, 0 ],
                "cull": false
            },

    The "uv" direction is what the game uses when it asks for the block's texture, and also what CTM normally looks at. "facing" is more like where it is in the world. Pre-1.8 there was no distinction, and for non-cube blocks, the concept of "faces" is somewhat arbitrary to begin with. Since vertical CTM doesn't apply to the bottom face (and if it did it would look at the north-south or east-west neighbors, not up-down), it ends up using the default texture.

    It's possible that changing the uv to match facing would fix the problem, but I don't want to force texture artists to edit a bunch of model definition files just to make CTM work. So my plan is to use both face values to try to reconstruct something that makes sense for CTM rules.

    Quote from OriAlon

    1. ferns are colored by the vanilla colormap instead of the specified one.
    2. random textures for double plants are ignored

    Both fixed.

    Quote from Retarded_Pig

    And my second issue is with logs. It is a 4*16 sheet of a beam. In the properties file I put all the metadata for the different orientations of the spruce log,

    You don't actually need to do this. Just worry about the wood type (metadata 0-3) and lay out your textures as if they were in the up-down orientation. MCPatcher automatically handles the other orientations and remaps faces accordingly. This is true of stone and quartz pillars as well.
    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 insomniac_lemon

    Nope, no render pass specified. What I'm specifically saying is CC not being applied to the blocks in the inventory, which I'm not sure why render passes would create an issue.

    Gotcha. I have some ideas, I'll take a look.

    Quote from BrokenEye

    Alright, I need some help. I'm trying to do a Vertical+Horizontal CTM for all faces, but for some reason it isn't doing the top and bottom faces. What am I doing wrong?

    By design, vertical and horizontal CTM only apply to the side faces since there's no natural up/down or left/right in the xz-plane. Symmetric 8-way CTM should work, though admittedly it's not quite the same thing.

    Quote from OriAlon

    I'm trying to make a grid type colormap for vines
    but regardless of where the vines are placed in the world
    they are colored from a single pixel at: X (biome ID) = 1, Y (block height) = 64
    they look especially awful in swamps,

    Bug fixed.

    Quote from Bastikeks

    Ok. made a screenshot first to compare 1.7.4 with the newest snapshot. No properties changed btw.

    The thing which is very confusing, is that for example on block 95:12 vertical-ctm is applied and the top/bottom-properties (fixed-method) isnt. On the next block (95:5) everything is fine instead.

    Yes, please PM me the files if you don't mind. Also could you do another test with 4.3.2-beta2 and 1.7.4? I'm curious if it's something I changed or something Mojang changed. I did change the way properties files are loaded so that they respect the order of multiple resource packs. The odd behavior you're seeing suggests the properties files are being applied in a different order. I didn't intend to affect the behavior of a single resource pack, but it's possible something broke there.
    Posted in: Resource Packs
  • 3

    posted a message on Is the MOD API actually being developed?
    Quote from Wanderer

    Instead of searching the update bullet points for the string "API", try reading between the bullet points. There have been changes that clearly show work on the Mod API in every 14w-- snapshot so far (save for the latest one, 14w08?) - and if you'd look a little harder, I honestly think they should be readily apparent to anyone with a programming background.

    Have you considered that people have read between the lines, as you put it, and simply come to a different conclusion? Many people in this thread have programming backgrounds and Minecraft modding experience specifically, and they've laid out arguments doing exactly that.


    Examples: Clone and Fill commands and Testforblocks

    -- are poor substitutes for even the most basic loops and conditionals already built into the Java language. Then there are the IDEs, debuggers, profilers, tons of third-party libraries, and a knowledge base that come with the language. Say, if only there were a way for modders to use such well-established tools and save Mojang the trouble of reinventing the wheel. Some sort of "interface" for "programmers" to develop "applications".


    Especially: The /execute command will obviously be very important to mod developers when it comes time to summon projectile entities from a custom weapon, as well as uses too multitudinous to enumerate here. The ability to target any entity with @selectors is clearly majorly important when a mod developer wants to change the properties of an entity on use of a given item or under certain circumstances.

    Again you're describing stuff that is natural to express in Java. All I need is a way to bridge the gap between my code and theirs. I don't need or want this ad hoc, looks-like-CSS-tripped-and-fell-on-a-belt-sander command block language.


    All of these changes to commands clearly indicate changes to the way the internal code actually works and the necessity of allowing that code (which will obviously be VERY important to mod developers to get maximum functionality) to be tested and bug-fixed BEFORE the release of the first public version of the API.

    Yes, we know Mojang is making internal changes to the way the code works. I've been updating my mod for the 1.8 snapshots, so I'm well aware of what those changes are. What I claim is that they are mostly incidental or outright irrelevant to having a useable Java programming interface in modders' hands sometime this decade.


    This means that a technically unlimited amount of data can be stored in inventory spaces (within the confines of Java and/or your machine), as well as transferred to a block when placed in the world. If I have to explain the implications further, you honestly have no right to assume anything about the Mod API.

    Other than killing performance by turning every block into a potential tile entity? Can this add entirely new blocks with their own IDs, recipes, textures, material properties, etc., etc. to the game? What about new mobs, new biomes, new dimensions, new weather patterns, new cave generation, new AI? Are modders any closer to doing any of that than they were four years ago?


    Block Models: In 14w06a, the ability was added to define irregular block model shapes using resource packs. This is obviously a test-run for part of the API that defines block models for added mod blocks.

    As explained earlier, the old block rendering system is still in the code and will likely never go away. The new system can't feasibly represent dynamic blocks like glass panes, fences, or flowing liquids. Block models are great news for artists who don't write code, but they aren't needed for an API.

    In fact, if we had an API that exposed the existing block rendering system, modders could have built their own model data format on top of it. Same goes for command blocks actually. An API would allow either Mojang or the community to build them as a separate plugin. Especially for a team as small as Mojang's, it's simply unbelievable that they're putting so much time and effort into these distractions.
    Posted in: Recent Updates and Snapshots
  • 1

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

    EDIT: Found a bug, Kahr..... recolored CTM stained glass works fine in-world but not in the inventory:

    Are you using multiple render passes? That's never been supported in the inventory GUI. It's not an easy thing to fix unfortunately.

    Quote from Bastikeks

    A quick test showed, that stained glass has still a weird ctmhandling. sometimes it gets applied and sometimes not. Vertical ctm seem to work, but when you apply for example a second propertiesfile to the same block (for top/bottom) it wont work (All CTM was tested in 1.7.4 with no problems):

    I haven't been able to reproduce anything like this. Do you have sample files I could look at?

    Quote from Bastikeks

    Also it seems that CTM which is applied to Blocks with no actual metadata (e.g. 88:15) isnt applied, too (worked back in 1.7.4).

    I'm not sure what you mean by blocks with no actual metadata. An example file would probably help here too.


    I have an issue with the tabs in the Thermal Expansion gui and MCPatcher. For some reason the icons on the tabs are not rendered when MCP is running.

    Turns out to be a case where Forge and MCPatcher both modify the exact same piece of code, a very tricky bug to track down. Fixed for next release.
    Posted in: Resource Packs
  • 10

    posted a message on [1.8.7 / 1.7.10 and earlier][update 4/23] MCPatcher HD fix 5.0.3
    Download MCPatcher 4.3.2-beta2 for 14w07a and earlier: jar exe

    The snapshot-breakage-to-patcher-update cycle is getting shorter, so here's another beta release. Notable changes since beta1:
    • Compatible up to 14w07a. I'd like to eventually do something to expand on the custom block models Mojang introduced, but it's too early to plan anything while the format is still up in the air.
    • Fixed CTM not applying to the grass side texture. Use matchTiles=grass_side_overlay for the most reliable match.
    • Fixed useGlint=false not working for worn armor models.
    • Fixed CTM not applying to certain other textures.
    • Started to work on the render pass issues again, but everything Mojang changed in 1.7 changed again in 1.8, so it was all for naught. At this rate 1.8 may prove to be as painful an update for modders as 1.7.
    Posted in: Resource Packs
  • To post a comment, please .