Posts by KingLemming

    I have my own "Sub-OreDictionary-Thingy" in GT (ItemStack -> Data). I use getOres almost only to register Recipes with the good old OreDict Crafting Recipes in order to be NEI and CraftGuide compatible without effort or additional Handlers. I know ID+Meta -> Data doesn't allow multiple Entries per Stack, but if I only allow Material based Registrations to have Data, it is enough to work efficiently and to be able to recycle almost every Item without exploits or recursive Recipe scanning algorithms. If the OreDict needs something, then it is a "ItemStack->List of Strings"-Map for faster checks.

    Yup, that's exactly what we do in our mirror of it:…

    As far as the OreDict thing goes, take a look at the newer Forges, 1381+ or so. I added a method where you can prevent things from being auto-registered on a getOres() query. It's a separate function, but you can probably make really good use of it.

    Team CoFH is bringing out a similiar mod: , however, using both doesn't seem to work: .

    Maybe the FastCraft author could collaborate or fork CoFHTweaks and incorporate his/her changes into it? That would be awesome!

    Our license does not allow forking.

    Not sure what you mean by "pulled a huge one" as no code was copied. Fastcraft is more encrypted than NSA records. It's reasonably common knowledge where some of the inefficiencies in the MC codebase are.

    If I had to guess, Fastcraft does things that we don't do (but we have no way of knowing what since it's super-top-uber-secret) and we do some things that Fastcraft does not. At some point, we happen to have a common optimization and they don't work together.

    If two Mods attempt to change the same Base Files it will always end up breaking. I don't think combining those Tweaks with Fastcraft on the same MC instance is a good Idea.

    And CoFHTweaks just looks like an attempt to bring the content of Fastcraft to Curse.

    Actually, it's not an attempt at all. We have no idea what Fastcraft does and have no desire to copy it feature for feature. It's simply some optimizations that we know work and that Fastcraft doesn't seem to provide. However, there are a lot of people who have indeed asked for a Curse-capable optimization mod, yes.

    Sorry I was raging a bit, because I needed to waste a ton of time fixing Issues caused by the Fluid System (even though that was last year), what was the first thing coming to my mind when you said the Pyrotheum thing wasn't a design flaw, with surprisingly unlogical reasoning behind not using OreDicted Recipes. It was a real surprise for me, that you said something like that, considering I knew you as a very logical person.

    And sorry again in case what I just said was kinda offending. Sometimes I am just way too open about my reasoning.

    And before I forget, I said "IDs only for Sync", but I forgot to mention that IDs are ofcourse also for saving Stuff in World (but saving Fluids as Strings is good too).

    I'll stand by the OreDict thing, The oversight was oredicting Pyro in the first place. It risks throwing the balance off, and in the events where something is the only thing in the OreDictionary, it actually slows the crafting process down, simply because of the matching process. It really didn't make sense for Pyro at the time.

    As far as the Fluid thing, I don't necessarily disagree with you. I wrote that in 1.6, when certain things were *guaranteed* - namely that client/server mods matched up, period end of story. I wanted to change it up for 1.7 but didn't get the chance due to RL obligations. It was on a big TO-DO note for Lex to implement in my stead, and well, he didn't do it. He hasn't done it for 1.8 either and can't be entirely blamed - he's a great coder but he's not a modder. He doesn't actually use a lot of the systems he has to support.

    So, given that a lot of mods are staying on 1.7, cpw and I are going to keep developing Forge 1.7.10, and a Fluid overhaul will happen. Probably enchanting and potions as well. Possibly biomes if we're feeling froggy.

    There's no fundamental "bad design" at work here
    Sure, this isn't the Fluid Class still using an ID System, or the Fluid Class using unstable ID based HashCodes fucking up every Recipe System in existence (I think that is maybe even some kind of Java violation), or the FluidStack referencing Fluids by ID->Array instead of a direct Fluid Variable breaking all Clientside Fluid Stacks in the process of synching the IDs from the Server. IDs are only for synchronising things to the Client in a efficient manner, and nothing else. Sync-ID based HashCodes are just terrible and require the constant tearing apart and putting back together of HashMaps. Fluids should have gotten an additional final variable called "hashcode" which is getting assigned with the help of the static variable "hashcodeindex++" what should be called in every invocation of the Fluid Constructor.

    I'll remove what I said before for the sake of not being rude. I have way too much going on IRL and there's no need for it to spill over. Suffice it to say it's not quite as bad as you're implying. However, I'm willing to look into a rewrite of it, but god knows when that's happening as none of the decent mods are going to 1.8. Can we throw it into 1.7 without upsetting the order of things? Let me check.

    Also, how the hell is TE so poorly designed that it registers oredict entries but does not use them?! And how is that not all automatic by design?!

    Well you see, I have an item class -…h/core/item/

    And it's a very trivial matter to register something as an OreDictionary item, so I do it out of habit.

    However, there are these things in Minecraft called recipes. They're registered with the recipe manager. You can give them Itemstacks, or OreDict names, if you use the Forge thing. It's not automatic, you have to code the recipes in.

    It's not a design issue, don't be stupid. You are better than that OM, or at least you're supposed to be. There's no fundamental "bad design" at work here, it's simply not using the OreDict recipe handler on things where it only adds to the overhead and lag to use them - i.e., there's only 1 Pyrotheum Dust, there's no point to not directly reference the version in Thermal Foundation.

    If anything, the oversight was doing a registration in the first place, as there is no reason whatsoever for Greg to add Pyrotheum. Seriously man, if you like the mats, just have some crossmod compat.

    Well, we *do* put the dust in the Ore Dictionary basically because it's automatic. I probably should stop that. However, our recipes don't support it, simply because nobody should be adding another Pyrotheum Dust. There is literally no reason for it.

    Greg - seriously, must you copy every resource from TE? It gets old.

    TE's charge API as a ripoff's of IC2? Oh come now Greg, I expected better from you. That's like calling Gregtech a Minecraft ripoff because it has cubes.

    Aside from that jab, damn I agree with your post. <3

    People need to drop this and move on, it's a freaking game. No rights were violated, nobody died, no legacies were defaced, and anyone who has their panties in a bunch over this has done it to themselves willingly.

    And no, I'm not back in the community. Shit like this is a large part of why.

    You said that pryotheum dust is hard to make, as balance for letting them smelt blast furnace stuff... but... erm...
    its super cheap, from what i can see. 1 sulfur, 1 redstone, 1 coal dust and 1 blazepowder? cheap as fuck lol

    Per ore. That is not a one time cost. Given that the alternative is in fact the Blast Furnace which does not have a recurring cost, and will likely be powered with some easily renewable source, then yes - that is extremely expensive. :P

    How about adding a way for modders to specify how much Pyrotheum is used for catalyst? So maybe higher tier metals could require 8 Pyrotheum Dust + Metal Dust instead of 1 Pyrotheum Dust + Metal Dust.

    This can already be done via the normal recipe handling IMC. :) I've changed Blast Ores to be an opt-in for the next release. By default, the Smelter will now only grab recipes for which there is a vanilla or Redstone furnace equivalent, or recipes I have explicitly defined.

    Greg is trying to test whether his itemduct auto-output works.

    @Greg: How about using a workaround; the conveyor module checks which is the itemduct RS setting. If it is set to Low/Disabled, does nothing; otherwise, emits an RS signal towards towards the itemduct. Kind of similar to the way TubeStuff buffers and RedPower filters used to work.

    Ah, didn't realize that was what was going on here. ATM, the simulate functionality does not work on the ducts (unimplemented), so it is possible that the machines are simply attempting to simulate before sending and then never getting the go-ahead.

    Ok, here's the issue I'm facing right now: Latest GT, IC2, TE...

    GT registers blast furnace items with TE. TE then adds them to it's Induction Smelter with Pyrotherum dust as the catalyst. There's currently no way to disable this except to disable TE's induction smelter completely. I submitted a ticket to TE to ask for a config to adjust what happens with registered blast furnace items, but KL is refusing to make the change. See

    So, my question is: Is this intentional? I don't like it because Pyrotherum dust (coal dust + blaze powder + redstone + sulfur) doesn't really even come close to the same difficulty in getting a blast furnace up to full heat. (I like the tiered heat approach on the blast furnace, and how you have to work your way up to the harder items.) I could see it working for some of the lower tiered items (steel, aluminum, etc.), but Kanthal, Chrome, Tungsten also?

    The problem is that this becomes a 1-way street. I don't make those deals anymore. I will not allow TE's functionality to be crippled by other mods which are also able to then turn around and create the special TE recipes, such as Enderium.

    And actually, that isn't even leveled at Greg. He's been great about it. There are other mods and modders who would not extend the same courtesy. I'll consider a blacklist, but one of the key issues here is that Kanthal, Chrome, and Tungsten are out in the open OreDictionary. If the goal is to not allow other mods to make use of them, then private OreDict names are the answer, as Greg well knows.

    EDIT: There's a compromise here, we'll find it. :P

    EDIT2: The reason I basically shot it down was because you simply came in and said "I looked at the TE source, you are doing x and y" and you didn't understand the underlying IMC. You assumed that looking at the recipe handler is enough. I have to add new IMC for a Blacklist, and then I'll have to come up with some sort of strange validation procedure to ensure that a mod is not screwing with TE just out of malice. It is more than a 4-5 line code change.

    I can change the recipe back, sure, although won't that mess with some of the IC2 balance in making the memory cards? I'm honestly fine with it either way; the 1->4 gives a bit more flexibility overall. You could just alter crushed -> 3x dust or so to balance it out.

    Whichever solution works for me here.

    My opinions :
    IC² should change its obsidian dust to 1 -> 1 as KL suggested (By the way GT does not properly overwrite it, to output crushed obsidian when RC is installed).
    My bet is that IC² added that recipe not long ago, due the memory crystals, without having in mind the other mods.
    Making obsidian dust more difficult to obtain is not gonna affect IC² much, not at all, i think.

    IC² should change its bronze recipe to 3 +1 = 4, make use of Dense Bronze Plates in some recipes and/or add thick bronze plates, made with 2 bronze plates (4 with hammer).

    As far as the Obsidian goes, it's not necessary - I already adjusted my recipes. Now I'd just be more annoyed at having to change them back. ;)

    Point is, it was a small change either way. Given that Glowstone -> Glowstone Dust x4, I'm willing to accept it as logical, without question. Let's just see similar logic applied to Bronze - the only alloy not obeying conservation of matter.

    Wasn't it better to talk it out w Player and Greg would then follow IC2 standart change?
    And creating alloys in crafting grid is bad idea. 3+1 is ok, but it should use so sort of smelter or dusts for it, not just ingots.

    It probably would have been better, but that wasn't a courtesy I was afforded. In retrospect, the Obsidian change was a minor inconvenience. I sucked it up and moved on. This should be no different, but given the over-reaction of the initial Forestry nerf/rebalance, I felt I had to mention it.

    BTW, it's still just dusts! 3 Copper + 1 Tin Dust = 4 Bronze Dust, which can be smelted as per normal. I have no plan on smashing ingots together to form a new one. That'd be Superman style stuff.

    Well that was a kick in the balls :pinch:

    Sorry if you feel that way. It's not the intention, and truth be told, this should not be a major issue in any way. That's kind of why I wanted to come here and post it, to at least make people aware that I'm not out to get Greg or anything here. However, I do believe in 3 + 1 = 4. I'm an engineer, after all. For a long time, Bronze has been all over the place, but 3 + 1 is the most common standard in Minecraft. I'm treating RP's take on bronze/brass as the same idea here; 3 + 1 = 4, since the lines DO blur a bit. "Bronze vs brass" is a real Google autocomplete.

    Technically, it'd be like 8 + 1 = 9 in reality, but that precludes Bronze being made in a player crafting grid and underuses tin in the recipe. It's not good for gameplay. This is about the optimal for allowing players to still craft it in the default 2x2 grid while maintaining resource diversity.

    If this causes some major upheaval in the balance of gameplay, then there's a pretty deep issue here that needs to be re-examined. The amount of copper and tin generated would be a good place to start. Bear in mind that TE's gen is by default about half that of IC2's.


    I wanted to warn you about this one, since I know it'll come up and I didn't want anyone to get the impression I'm out to upset the balance here.

    TE added Bronze in the last patch. It's 3 Copper and 1 Tin for 4 Bronze. I do not wish to negotiate on this.

    Here's why: I had 1 Obsidian -> 1 Obsidian Dust in the Pulverizer. IC2-exp comes along and makes it 1 Obsidian -> 4 Obsidian Dust in the Macerator. Didn't mention it to me, didn't care, just did it. Same OreDict and everything. I realize you had *nothing* to do with that change.

    But here's the point. IC2 set the standard for Bronze long ago at the 4:2 ratio. I adjusted my Pulverizer and Hardened Glass recipe to make up for what they did to Obsidian. I didn't complain or throw a fit.

    So, I'm rearranging the terms for Bronze unilaterally, as IC2 did with my Obsidian. And they do not get to complain. Sorry if this causes a problem, but I am drawing the line here and I apologize if you end up conflicted with how to resolve this one. I suggest that you get IC2 to alter their Bronze recipe and enforce conservation of matter.

    This will also end one of the-long standing issues in the community. As with Redstone Flux, other Bronze-producing mods have agreed to support my standard already. It'd be great if you'd do the same.


    Yeah, it is not compatible with Mac for some reason, what I hate when being forced to use a Mac. Not to mention 50% of the time the Quotes are not getting displayed inside the Editor, so that one has to refresh until it appears.

    I get an Iron Saw within the first 5-10 Minutes of Gameplay (the third Metal Tool I craft), and you not only get a good Woodchopping and Leafcutting Tool, but you get also the same amount of Planks when crafting it together with a Log as if it wouldn't be nerfed (so that it stays exactly the same balance wise, but needs just a slight bit of more crafting Effort). That Saw was the only reason I nerfed it in the first place, because otherwise no one would have used it, and I like the concept of using Tools in crafting.

    Thank you for helping and for however you got mDiyo to calm down.

    I sympathize with you on the Mac issue. I have one of those for work. Yikes.

    Anyways, why not have the saw give +1 log (5 vs the normal 4), and then the Sawmill is +2 logs? Or 1.5x, whichever it is. That way you still have incentive to use the saw (and a useful tool for chopping trees), and you also establish the pattern that tools are better than hands.

    As far as the mDiyo thing, you're welcome. And I apologize if I came across wrong at any point today - it's been a long semester and I'm ready to go home.