plnx

Thanks again guys, this is all basically what I'm saying too, or would have said if I had more experience here. Right, that's the error I was pointing out when I said "Some people are even then duplicating it repeatedly for every new furnace they add..." Again, it's not, I said it's probably not very useful. Creating a "common furnace" was a tangent I didn't mean to get so far into; this was all just an excuse to cut my teeth, I personally don't actually care that much about furnaces. Yep, it's in that static method setState I mentioned. I wouldn't be trying to make something more flexible, I was only thinking about "relaxed protections, more setters and so on", in other words just the vanilla class, refactored to allow people to extend it (this is why I was at first thinking maybe this is something forge should patch). If you wan more than one slot, ovverride. If that means you'd need to basically override everything anyway, then right, not for you. Well, I'm satisfied, and have some more specifics to look into now. Just to be clear, I'm not arguing for a common furnace, and am not about to embark on some kind of Furnace Makers API. I guess I don't even know the right way to ask questions yet... turns out what I really got from all this was a better grasp on the architecture in general.

> But sure, feel free to create that library if you want to. Dollars to doughnuts no one will use it. Eh, you're probably right, and I'm not that dead-set on it anyway. Really just feeling things out at this point. (and, hm, I can't seem to work the "insert quote" link) But, pretending I am, allowing other mods to care about how a furnace smelts wasn't my point. More like, allowing mods (and MC itself) just to know this thing is a furnace, however it works (like I said, "not like trying to predict all bespoke variations of that logic.."). Is that very useful, particularly compared to something like liquids? Nah, probably not. As for the library, I meant that less about providing a common furnace than giving people a base to extend, save some time. Going back to my original example of a furnace that just looks different (it was a sandstone furnace), it seems kinda silly that I have to repeat all these classes just to do that (though I understand the reasons). Even if no one else used it, if I was creating a mod that added a bunch of furnace, such set of classes would be my first step anyway.

Thanks guys, both those comment help. As an aside, being new around here, I'm often not sure when I'm looking at examples and tutorials if what I'm seeing is "crazy" because it has to be, or because the author doesn't know any better. Don't get me wrong, I've see a lot of good stuff, but I also get the sense many people get into this with no prior development experience; and often tutorials will tell you what to do, but not why it has to be that way. Anyway, I suppose I could argue what is deemed "needed" can be subjective (maybe I want "oh that's a furnace", and don't really care about liquids--just playing devil's advocate), or that one of forge's design goals in general should be to avoid plug-in authors duplicating code as much as possible (as in the case, "I want this to behave exactly like the vanilla version, even if the MC changes", not like trying to predict all bespoke variations of that logic, in which case I'd totally agree you should be on your own) ... but I take your points that this specific case is really pretty niche, I'd call it only "nice to have" too, and it make sense that forge should keep it's patches as minimal as possible or risk becoming unmaintainable. When I'm farther along, maybe I'll write that "common package" (or "good example"), something along the lines of duplicating TileEntityFurnace and children only with relaxed protections, more setters and so on; but for now thanks for helping me get my head on straight.

Ha, as much as I'd agree every topic could use XKCD, I'm not advocating for a standard, and I didn't notice any competing "standards" (if by that you mean libraries) out there. With the little experience I have around here, I'd be leaning towards the forge solution anyway--I just don't know what that means yet.

This might belong in "Forge Suggestions", but I feel too new to be sure of what I'm saying, and am looking for some more general comment. Just as an excuse to explore the code, I wanted to add a new type of furnace, and found even if all I wanted was for it to appear differently, it isn't a trivial exercise. Before I read it, my first thought was to sub-class BlockFurnace (basically empty, just to have something to hang new asset files on) but ran first into the call to the static method setState in BlockFurnace causing my furnace to be replaced with a vanilla one when activated in-game; and shutting down my hopes of inheritance (among other points I then noticed that would make it impossible). Poking around git hub, seems the going strategy instead is to sub-class farther up, resulting in a ton of copied code handling the common furnace logic. Some people are even then duplicating it repeatedly for every new furnace they add, making it worse. I know we're making a system do things it's designers didn't intend--this sort of thing is probably unavoidable at times--but it still just feels so wrong, especially for something I thought would be a basic change. So... [*]Should I work towards a contribution to Forge? I have a feeling there's some issues I'm not aware of causing this to not already be in place. (and I still have a lot to learn before I'm ready for that) [*]Is there a library already out there that would at least does this duplication only once for all mods that use it? Is there a reason why this would make more sense as a library, as opposed to, say, new event hooks for Forge? Thanks.

Awesome thank you! Didn't click the first time I read "-sources", but right you are, I just wasn't looking deep enough: .gradle/caches/minecraft/net/minecraftforge/forge/1.8-11.14.0.1290-1.8/snapshot_nodoc/20141130/forgeSrc-1.8-11.14.0.1290-1.8-sources.jar

Thanks. But, I had found that before; what I meant was the decompiled, deobfuscated and patched Minecraft code (that's the only code that needs to be deobfuscated, right?). In other words, let's say I want to pull up Block.class from net.minecraft.block, complete with the friendly names like I would see in Eclipse. I've found .gradle/caches/minecraft/net/minecraftforge/fml/<version>, which comes pretty close, but instead of names like "soundTypeStone" I see "field_149769_e".

I'm brand new to all this, and just how Eclipse magically shows me source code that doesn't seem to exist anywhere on my file system is a mystery. I'd love to be able to simply "grep" and explore the code that way I'm used to (I'm also new to Eclipse), but I vaguely (mis)understand since the introduction of gradle everything is tucked away in it's cache, and my only window in on that is through Eclipse. It seems the final code view I see in Eclipse is put together from pieces in that cache only when I ask for it? Is there a way to "export" all the files so I can run other tools against it? I'm sure this must have come up before (sorry) but I can't seem to find the right way to search for it. Thanks in advance.