• 0

    posted a message on Storage Drawers - [1.7.10 - 1.12]

    Aye. It looks like your scanning of nearby tiles is triggering that tile to scan you back again, rinse and repeat ad-nauseum. My suggestion would be to do nothing on neighbour updates *directly* but rather just flag for a deferred action in the next tick loop..

    Posted in: Minecraft Mods
  • 0

    posted a message on Storage Drawers - [1.7.10 - 1.12]

    Hey Jaquadro, like this mod, very stylish. Playing with it in the AS2 alpha and I encountered a nasty crash: https://gist.github.com/cpw/d5cfbfedbfbc35fb7549


    As explained here http://minecraft.curseforge.com/forums/jadeds-packs/agrarian-skies-2/773-agskies-2-alpha-bugs?comment=433 I was putting out a storagecontroller on my pipe pending re-adding a bunch of new drawers..

    Posted in: Minecraft Mods
  • 0

    posted a message on MAtmos - Environmental sound atmosphere simulator
    We should talk... Look me up on IRC.
    Posted in: Minecraft Mods
  • 0

    posted a message on Inventory Tweaks 1.61 (Jul 11)
    Kobata, You need to make a new build, with the additional Manifest marker "FMLCorePluginContainsFMLMod". I documented this in issue https://github.com/Kobata/inventory-tweaks/issues/93.

    You will not work with recent Forge/FML builds, until you make this change.
    Posted in: Minecraft Mods
  • 5

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

    Thanks to everyone who posted their support. I haven't made any final decisions yet.

    I would also like to thank cpw for his measured responses. My post was obviously made in frustration and I appreciate his willingness to keep things from getting out of hand.


    I wasn't aware of Grum's statement regarding distribution of modified class files. You'd think an announcement of that magnitude would be a little more prominent than a few tweets, but that's Mojang's professionalism for you. I can see how that puts you in a difficult position and it helps knowing you didn't make this change on a whim.

    Still, in my defense, and please take this as constructive criticism, you really could have handled this better. A request is not a requirement, and the best response to Grum is -- well the BEST response is "Sure, give us a proper API and we'll get right on that". But barring that, at the very least you could have waited until you had a more fully-featured patching system in place before springing this on everyone.

    Telling people "Sure you can modify base classes, just not any of these: *insert list of every base class anyone cares about*" comes across as glib and insulting. Forge has a spotty reputation as it is, one that goes well beyond one particular mod, and you didn't do yourself any favors here.

    I also apologize for missing your PM last year. No slight intended at all. I either missed it entirely in the deluge of PMs I get, or I saw it, put it aside because it was a complex question and simply forgot about it. I rely on decompilation in my own debugging, so I can fully sympathize with your frustration when it isn't working.

    I'm willing to work with you on possible compatibility between MCPatcher and forge, but I do insist on maintaining my independence. I have this weekend slated for the backlog of bug reports and remaining 1.6 issues, but I will PM you once I catch up.


    Well,thank you for your reply.
    Firstly, a request from Mojang, really should be considered an expectation of delivering results.

    The new launcher was sort of (not that I'm claiming responsibility) in response to "we need to be able to control how minecraft runs", which is a prerequirement for any runtime monkey patching.

    Note one of it's key capabilities is being able to direct other things to run, not just "vanilla", directly from configuration.

    As to timing, well, I promised to myself that as soon as no base class edits were needed, NONE would be distributed, and I try to keep my promises. I made public this intention about 6-7 months ago, when I first figured out how I could monkey patch Minecraft at runtime. This is NOT new news. I have tweet about it repeatedly as pieces of tech falled into place. Sadly, time and resources meant I couldn't complete the "sophisticated" system to my satisfaction, so the "crappy diffs" are the fallback position, but I intended to keep my word.

    On "changing classes", we do have a couple of systems we're working out with sp614x, and "don't change these classes" isn't actually mandatory- if you can patch in what fml/forge needs, there's a simple flag that stops the "crash and burn" behaviour and tries to soldier on (sp614x is already using it in optifine, though we have already come up with better ideas).

    Finally, editing the minecraft jar is simply a no-no for us, because again, Mojang is gonna start sig checking that thing. It took me a while to convince them not to straight out in 1.6. You can prepend any "modifications" even to base classes, to the classpath right from the launcher, so changing the actual jar should never be considered a necessary step (if you're worried about signature violations, Mojang has code at github.com/Mojang/LegacyLauncher that will step around signature violation checks in normal Java).

    I'm certain you could create a "modded.jar" file, and the json to go with it, from mcpatcher very easily (and probably install that version into the launcher while you're at it ;) ).

    Anyway, this is of course, your choice. I'm happy to work with you to try and figure out how mcpatcher and forge can coexist in the future, just as I'm working with sp614x. I suggest following me on twitter (minecraftcpw) if you don't want to be blindsided by these things in the future. Also, if you have any questions, just ping me on twitter, PM or IRC ([email protected]), if you want to talk further, I'm always happy to engage and solve problems..
    Quote from Kahr

    ...snip...
    I'm willing to work with you on possible compatibility between MCPatcher and forge, but I do insist on maintaining my independence. I have this weekend slated for the backlog of bug reports and remaining 1.6 issues, but I will PM you once I catch up.


    I would expect nothing less than complete independence from anything forge, except maybe inside a 'forge compatibility module'.
    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 Conraad

    Well obviously everyone has a valid point and will stand by their decisions and methods, so it's safe to say that stuff will go A-wire.

    What I do not understand is why Forge, which I believed was a community project for the community will now basically enforce implementation onto it's users and developers of mods that is asked for by the Minecraft Development team. What in the world do they actually have to do with the modding community, the most awesome mods came to life thru base edits simple functions better rendering, which the Mojang dev team could have added years ago, but never did.

    Some of these great ideas has turned into even more spectacular work from mod developers, but now all off a sudden no more base edits. Personally I'm against base edits it's just sometimes really bad, but I do not go and force my views of base edits onto everyone else, however this means huge and successful mods that uses base edits have to now work twice as hard on the same thing they already accomplished a year or more ago instead of spending time expanding there work.

    Forge is loosing face, and I can't really see how Forge in anyway can be seen as a community mod for the community when the implementation of the API is being done in such a way that developers is force to adapt to new code styles and new methods and that happens just about all the time, whats even worse is that not only are we force to comply, but every single method lex adds or changes nobody at first has any clue or idea how to use, you have to spend time on figuring out what the heck he just changed and how it affects your mod. Just for the record cpw this is where I have to say your are really good at when I open up a FML class file I can read exactly what I need to do to change and update my mod, unfortunately you group yourself with lex and he does exactly the opposite not to mention the way he talks to people that alone is actually sad.

    Anyways cpw your work is inspired, but Forge I'm sorry this last 1.6.2 update was like the cherry on top of the cake, the sad thing is I'm stuck with forge and stuck to abiding by the changes all the time, but Forge is in no ways for the public, it's just an API that helps and if you use it get use to code changes all the time, it never stops.

    So with that said freedom to do what we want with the code is what makes modding great for minecraft, start applying rules and crap whether it's for good intentions or not is taking away that freedom and theirs no other way to see this and this is going to split the community down the middle.

    Conraad, this is absurdly off topic, so I will not discuss it further here. If you have a beef with FML or Forge or any "perceived changes", you know where I am : IRC, twitter or PM here.
    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 Sage Harpuia

    I never said that the new Forge distribution method wouldn't go smoothly with MCPatcher.

    I see that the problem is pretty big, and difficult to solve. For as much as I care, they can be incompatible, as I don't use Forge mods and MCPatcher toghether (it's impossible to find a TP of my taste with all the texture needed for the mods I use). However I see the problem for others, and I thought that OF, that's still forge compatible can ship the custom texture support for Forge.

    After all, most of the people still don't use mods use MCPatcher for TPs, while people who use Forge usually run Optifine. In terms of costs/benefits this seems a much more sensible way.

    @nickhawaii sorry if that came out blunt, I forget how some people don't have a minimum of computer science background, so what was obvius to me wasn't to you. Anyway, to respond to your question, Mojang cannot, at least to my knowledge, make legal claims on MCPatcher, as it is all Kahr work. Morally he should oblige, and if I was him, I would say a f*ck you to them, considering I was doing a free service to the community...


    Sage, as far as I am aware, MC patcher isn't and never has been in violation of the MC ToU. Which is more than FML and Forge could say until recently. I have no problem with what he is doing - as you can see, FML is now in some ways emulating MC patcher, except it's doing it at runtime, rather than "pre-runtime". My problems with MC patcher were always and remain technical in nature - his method of class patching was causing FML and Forge to have a hard time functioning, and it was NOT obvious why this was the case, and the fact MC patched classes failed to decompile meant it was very difficult to diagnose.

    Speaking of optifine, I am working with sp614x on something that many forge and non-forge users should enjoy, more to come on that (hints exist in the FML github!). However that's not relevant for this thread, please ask on twitter or somewhere else, or better yet, just wait.

    Kahr, if you wish to work something out, so that we can resume coexistence, I am always available to talk, via twitter, IRC, or even here on PM (though I don't check in as often as I should here).
    Posted in: Resource Packs
  • 0

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

    Whoa whoa whoa, what did I do to earn your hostility? I was just asking a question, which was also left unanswered. Your comment had nothing to do with base class editing, either:



    So I ask you, what if it were Mojang, or even Notch himself, that requested a change in the way that the mod works?

    Nick, chill please. He's right, MC patcher works by shipping patches in the form of functional diffs, applied to classes in the jar file. FML/Forge's changes to use a runtime binary diffing strategy pretty much break his model entirely.
    Posted in: Resource Packs
  • 0

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

    If you are referring to Grum's and cpw's latest tweets, you see that they're talking about base class edits, wich MCPatcher doesn't do, because, duh, it's a patcher. I suggest to read more carefully next time before you make a fool of yourself, clueless fan.

    However, Forge, by complying, means that it's harder for MCPatcher to work. That's a sad side-effect of this action. It's one that I cannot easily change, without uncomplying with Mojang's request, however.
    Posted in: Resource Packs
  • 0

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

    Yea, he did. Just looked that up. It pales in comparison to the amount of sheer vitriol, negativity and personal attacks that FC has launched at CPW, etc. over the months.

    I guess it depends upon which side of the fence you stand on I guess, as it's been discussed elsewhere before. Despite it being an almost carbon copy, if it's not using any of the original code or assets, there's no problem whatsoever. People who use Forge want to play BTW, but FC doesn't want to produce a Forge version, so others are taking it upon themselves to do so. If anything, that's a huge compliment for FC if people are willing to recreate his mod because they want to play it that badly.

    Please don't bring up the FC debate. It's not relevant here.
    Posted in: Resource Packs
  • 23

    posted a message on [1.8.7 / 1.7.10 and earlier][update 4/23] MCPatcher HD fix 5.0.3
    Hello Kahr, I'm going to reply this one time to your post, I don't wish to start a flame war or anything else. Forge is not going to change our distribution method, and I don't believe you're going to change yours. That is fine. 100% compatibility is a goal, but it will never be attained.
    You will note a single theme, tweeted by ME frequently, but ignored by the more bombastic members of the modding community. I really hope you are not one of those.

    Please note, from my perspective, your compatibility with forge has been minimal for at least a year- I PMed you here about trying to fix some of your more egregious class modification issues, without a response. The runtime class modifications Forge/FML perform have long had a problem with your pre-launch class modifications, and we decided that trying to work around them was more irritating than it was worth. It was very hard to understand your custom class patching technology as it doesn't seem to be based on any byte code engineering technology I am aware of. ASM, our choice, certainly puked more often than not.

    Quote from Kahr

    Regarding forge support. For those who are unaware, forge's latest update is essentially an ultimatum to modders: Either be incompatible with us or be incompatible with everything else. As one of MCPatcher's core design principles is to be as compatible as possible, this is completely unacceptable. Making MCPatcher forge-compliant would represent an enormous effort for an inferior result. Among other things it would mean no snapshot support, leaving texture pack artists with no way to work on new features between major Minecraft releases.

    I was personally asked by Mojang to stop putting minecraft classes directly in my jar distributables. I complied with their request at the 1.6 release, since it was technically possible to do so at that point. I am sorry if that makes your life more difficult.

    Quote from Kahr

    There is no technical reason for this "no jar edits" requirement. With a few hours work I was able to bypass it and get a proof-of-concept MCPatcher+forge modified jar up and running with only minor incompatibilities. The result is essentially the same as the old way of adding a forge zip to MCPatcher and clicking Patch.

    I agree there is not technical limitation. There is simply Mojang's direct request to me "Don't do that please". The binary diff is crude, because it was simple and rapidly implemented. A more elaborate method-driven ASM technology was and still is in progress, but would result in less useful stack traces, so it's not in a hurry to happen.

    Quote from Kahr

    I am led to conclude that this change is more about promoting an ideology than a technology, and recent public behavior by Lex and cpw only confirms that. They repeatedly insist that any modder not doing things their way is "doing it wrong", as if there were only One True Way to create Minecraft mods. The condescension is especially rich considering forge's crude binary diffs method for base class edits is light years behind what MCPatcher has been doing for over two years now.

    Ideologically, yes, I don't like base edits. The less we have to do the better. However, that has nothing to do with Mojang's direct request "stop shipping minecraft classes".

    Quote from Kahr

    So while perhaps I could cobble together something that will work both with and without forge, having to bend over backward to accommodate a group with so little regard for others is extremely frustrating. I would much rather work on new features for artists than constantly jump through forge's ever-changing and utterly unnecessary hoops.


    That is your choice. As I say, MCpatcher has not been considered a recommended forge tool for applying code to the jar in some time, due to the class mangling you perform being incompatible with our runtime work.
    Posted in: Resource Packs
  • 1

    posted a message on [1.5] FML : a new mod loader
    A small bump because this is now available for 1.5. It supports the new MCP "srgnames" reobfuscation target, to allow some semblance of version independence from minecraft versions..
    Posted in: Minecraft Mods
  • 1

    posted a message on [1.5 and up] [FORGE] [UNIVERSAL]IronChests 5.0 - Minecraft 1.5 update!
    I guess I'll bump this a little bit since it's a 1.5 released mod :)
    Posted in: Minecraft Mods
  • 0

    posted a message on [1.5 and up] [FORGE] [UNIVERSAL]IronChests 5.0 - Minecraft 1.5 update!
    Yes, that is a mod file for the snapshot in the OP. I am not trolling.
    Posted in: Minecraft Mods
  • 0

    posted a message on [1.5] FML : a new mod loader
    Yes, there is a snapshot version available. It is under development, and will probably be in flux, but should give a taste for the upcoming texturing changes (they're pretty significant)
    Posted in: Minecraft Mods
  • To post a comment, please or register a new account.