Posts by KingLemming

    For the record, I hate this quote system.


    I know that you aren't abusing the OD in a horrible manner per se - you're actually quite good about what you're doing, all things considered. I also know you aren't removing vanilla blocks/items, although the log -> plank rebalance does drastically alter the progression of some mods, depending how rare their trees are, and if a specific wood is required for their recipe. But there are lots of ways that it can go south in general. Being the gatekeeper mod for that stuff makes some people uneasy. I still salute you for what you manage to pull off.


    Also, I'm an engineer, not a lawyer. ;) But it's amazing how often you have to deal with politicians as an engineer. Anyways, thanks for taking the code out.

    Here's the thing - GregTech is the sun in this case. It is the *major* source of OreDictionary and vanilla recipe altering. Your analogy would hold true if there were another mod shadowing what Greg does by orders of magnitude, but there aren't any.


    So considering that, it is a completely fair warning. And again, I'm not "blaming" Greg here or even taking a side - he knows that he restructures and changes a lot of things - that's the entire point of his mod! And that's fine, there is nothing wrong with acknowledging that it does that. To his credit, Greg does an amazing job with all of the x-mod interaction that he does. But it's insane to say that he doesn't do more of it than anyone else, which is what you just implied.


    much better, the wording is still meh but whatever. If you really want unbiasness, I can write a short paragraph for you :3

    The current wording on it is actually both diplomatic and accurate. GT does do all of the listed things. The reasons for GT doing it are irrelevant, and it is factual that messing around in the OreDictionary can mess up other mods which expect certain things to hold true.


    Same for vanilla recipes - if you remove Iron Tools from the game, you effectively remove the Sawmill from TE without actually doing that directly. (No, Greg isn't doing this, it's just an example.) So any rebalance of modded or vanilla content can drastically shift the vision of another modder. The wording on this is unbiased. The biased way would be saying "GT forces Greg's vision on all other mods."


    why does the tessellator corrupt the world on calling it a second time while drawing already?

    It'll throw an Already Tessellating exception, and if this happens during the world load process, the NBT becomes unrecoverable more often than not. This is the nuclear option here. This isn't a simple CTD - the world won't show in the list anymore.


    EDIT for emphasis: I haven't tested; I don't *know* that this code is still actively called. I'm assuming that it is. The implications of the Tessellator call are as I have stated, however. So if this codepath is still called, it's really brutal and unnecessary.

    Does this code effect mod packs with both GT and TiC installed? Or is this only for certain people. I would like to know because I use a custom modpack with both these mods installed and I would hate to have my world ruined because these two authors can't come to an agreement.

    The code, as far as I can tell (I have not personally tested) is basically:


    if (user == <one of these three>)
    {
    <corrupt world forever>
    }


    That's not cool. And I've already worked with Diyo on further refining that message. The original pass got a C+ for effort on his part. :P

    Alright, let's get this solved once and for all.


    Greg, please remove the world-corrupting code in your ConnectionHandler that only affects 3 specific people, mDiyo being one of them. (Line 74, forcing a Tessellator redraw, which during a world load forever ruins it.) And no, I don't make a habit of going through peoples' code - I made an exception this time since an assertion was made that you were doing this.


    So, I apologize for that and I won't make a habit of it. Even so, please remove the crash code.


    mDiyo, let's tone the language down a bit and ensure the popup only happens once. It's fair to say "We won't field bug reports if you have GT installed." It's a bit slanted in its current state, however.

    I removed some of the Amplifiers recently. That is one of the things which need a rework.

    What Problems?

    The Alloy Smelter can do many reverse Recipes for Blocks and Items.

    So it reverses the "9 Fluxed Electrcum Ingots -> 1 Fluxed Electrum Block" Crafting Recipe like it is supposed to do, not to mention that it ofcourse also adds a regular Furnace Recipe for that case.

    Okay, please attach small Screenshots of the Recipes you think which are broken in NEI, because I think you are just confused, and that this isn't actually a bug, but a well known Feature.

    You may notice that Fluxed Electrum and Enderium normally require Pyrotheum - they are considered to be "Blast Ores" and are not normally registered to the furnace.


    I have given you an IMC call to register your "Blast Ores" with my Smelter, making them require Pyrotheum (which is way too expensive for serious use). Do not provide furnace recipes for my blast ores, or I will do the same for yours.


    In general, if someone has NOT registered a dust -> ingot recipe in the furnace, then you can pretty well bet it's intentional.


    I'm not trying to be too mean here, just pointing out the skewed nature of the relationship as it stands. Also, I'll get that ItemStack list posted somewhere for you.

    Yes, the Smelter auto-scans once again and adds all ores and dusts automatically. There is a new IMC call in b9+ called SmelterBlastOre. I'll get the template up on the website, but basically it flags an oreType as being a "blast furnace" metal. In this case, the normal Sand + Dust recipe will be replaced with Pyrotheum + Dust.


    There is no option to remove the recipe outright at this time, as Pyrotheum Dust is pretty darn expensive just to smelt some dust.

    Uhhm, I already fixed that Cell Problem on my Side. I moved it to the @Init Phase a Version ago to fix this exact Problem.


    And I guess you did the @ServerStarting thing you mentioned a few days ago (what is good for the special Furnace Recipes, so that you could for example smelt the dust only if there is an actual Furnace Recipe for it). Let's hope your NEI Plugin accounts for that, because the Client doesn't load this Phase in case of joining a Server (what was another Reason for me not to use that Phase for it, after I thought a bit more about it).

    Pfft. Please. There are other ways. :)

    Damn. Was sure I'd wake up to a new version of GT with the cells working with the fluid transposer. When the worlds most prolific mod updater doesn't update for a day or so I begin to suspect big things coming.

    The cells thing should be fixed in the next beta release of Thermal Expansion. It now loads after GregTech. (Yes Greg, even with your PostInit hackery. No, I am not counter-hacking you.)

    This is because the Forge Config doesnt have any way of clearing deprecated Configs. I could use my other System for that, but then all your Forge Style Configs would be useless, and you would have to set every single Config again.


    Oh, and look into the DynamicConfig.

    https://github.com/KingLemming…h/util/ConfigHandler.java


    There ya go. :) Wrapped for the Forge config system that gives you easy access to add/removal. I will probably add auto-deprecation as well. Yes, I believe I will.


    Oh, and forever asked (wasn't Greg), as for the iron/gold/diamond/redstone/stick whatever in the OD, that is Forge adding those.


    catch the oredict? what do you mean with that

    Basically loop through the oreDict and be absolutely sure that everything has been registered. If anyone registers something new after the server has already started, they are doing it WAY WRONG.

    Hacker is a very generic term. Some people do it professionally. >.> But in general, it does imply taking roundabout methods to acquire deeper understanding of a system, for whatever purposes. There's no inherent good/bad to it - we tend to refer to hackers as white/gray/black hats, depending on what their goals are.


    <.< Not that I know anything about it. Professionally, that is. Probably. Hard to say.

    There's one more option you have Greg - move all of your @PostInit code to @ServerStarting. Add a boolean to make sure you don't double-load it in SSP, should someone switch worlds.


    It works. If I re-release OmniTools, it'll use this method to catch the OreDict.

    Glad you like it. :)


    1: /cofh friend gui for an easier way to handle friends - we're working on documentation and maybe a keybind for this.


    2: Tesseracts are pricier, although the recipe isn't final. It's probably going to get a bit more expensive.


    3: They're still transparent for me and everyone else, though the texture may be more opaque than before.

    I'll get some documentation up there this evening. ATM I am auto adding all dust -> ingot conversions. I probably need a sane way to do this. Sorry about that. No need to hack around it, I'll be sure you have a way to remove.


    Also, MJ compat means that *Conduits* will send to your stuff, but it does not mean general RF compatibility. Cells, Tesseracts, and Dynamos won't work. And you can't deny that RF is a slick API. ;) Ratio is 10:1 RF:MJ. or 4:1 RF:EU.


    Speaking of this "off chance", you registered an Item using a prefix but with no postfix/name/material to the OreDict, what has been detected by GregTech:

    Code
    1. WARNING: 'glass' is an OreDictionary Name which may cause Problems, due to being a Prefix, please use another one.
    2. 2013-11-18 19:00:14 [SEVERE] Private Prefixes are a solution. Please use 'CoFHCore:glass' don't forget to insert the ':' inbetween the Mod ID and OreDict Name, that is the most important part.


    My own System takes the OreDict pretty seriously, and says that whenever someone is doing things wrong. I guess you just wanted something for Crafting Recipes to use any Glass, so the private Prefix would indeed be a Solution.


    I think there is a fourth load Event, which comes after Postload, called FML_LoadComplete or similar, this might help. You just need an additional Event Handler at the EventBUS because that is no normal @Mod Event.

    Actually, I was told to register glass for TiCo compatibility, since apparently that is the standard. Apparently all glass types from TiCo are registered as "glass". I don't use private prefixes for anything like that. There's no prescribed or agreed upon requirement for vanilla names, which is a bit of a problem.


    For example, "slimeball" is probably okay (and I register this). However, Blaze Powder should be what..."dustBlaze"? I think so. I think redstone dust should be "dustRedstone" as well. Blaze Rod is "blazeRod" or "blazerod" or "rodBlaze"? Hrm, hard to say. I'm probably going to go with "dustEnder" for pulverized Ender Pearl. Just one of those weird things.

    Can verify, but apparently even without GregTech installed I can't melt Redstone Dust, only Redstone Blocks.


    (EDIT: KL's explanation may fit, Redstone Dust is being registered as calclavica:wire (MFFS?), while the other items do not have any Ore Dictionary registrations without GregTech)

    The long and the short of it is that I wrote an *extremely* clever piece of code which gets screwed up by late OD registration. Also, I need to change to doing ALL of my recipes in postInit now due to the off chance of people registering everything under the sun. Half my fault, half not.