Posts by MauveCloud

    This is not just a question of free time. In case you hadn't noticed on the CurseForge page for GT5u, the license is "all rights reserved". This means I can't just pass around new builds like that. Afaik, only Blood Asp is authorized to put up such builds. Making one's own custom builds for personal use is generally accepted when source code is readily available (though perhaps not explicitly allowed by the license) as long as they're not distributed.

    Also, I think what you're asking goes against the spirit of GregTech - if you cancel out the reduced efficiency from overclocking machines, what then is the point of using a Processing Array?

    It took me a few minutes to find it, but what you want is the calculateOverclockedness method in GT_MetaTileEntity_BasicMachine:…

    Multiblock machines handle overclocking individually (e.g. the EBF also considers the coil type when determining speed and energy consumption, and the Cleanroom is not subject to overclocking), the code for them is in this folder:…leentities/machines/multi

    Yeah, I see the problem there. Since it takes a fluid stack, which as I understand it can include a quantity and not just the type of fluid, I thought maybe that could somehow control the duration/total output, but the documentation doesn't help much with that, and looking through the CraftTweaker code for MC 1.12 on GitHub, I have been unsuccessful at finding this function to confirm or deny. The old MineTweaker3 documentation supports this, but is still a bit vague: http://minetweaker3.powerofbyt…pport#Semifluid_generator

    It looks like your fluid ejectors are not configured, which means they eject to the "first valid" side - it doesn't specify the search order, but looking into decompiled source, it apparently goes west, east, down, up, north, south. It might work better if you configure them to output to the specific sides you want. Just in case you don't know how to configure the fluid ejector upgrades, see the instructions at https://wiki.industrial-craft.…e=Upgrade#Ejector_Upgrade

    I just downloaded the zip for Tekkit Legends, and it uses IC2 Classic (by Speiger), rather than IC2 Experimental. That mod has an option to use steel in the recipes instead, but as far as I can tell from decompiled source, that wouldn't add refined iron to the "steel" oredicts, making it useless.

    If you want refined iron to be separate from steel with IC2 Experimental, you'd need MineTweaker/CraftTweaker scripts.

    I'm not sure it's a question of whose "fault" it is so much as a question of what buildcraft means by "inventory empty". If it is calling getSizeInventory (specified by IInventory) to check how many slots the machine has total, counting the upgrade item is fair game. However, if it is calling getSlotsForFace (specified by ISidedInventory, called getAccessibleSlotsFromSide in some older Minecraft versions), that is checking for slots that can be input or output via automation, and the upgrade slots should be excluded.

    It's not easy to track down which one Buildcraft uses, but I think it uses some wrapper classes to access inventories via ISidedInventory methods if available (see… - not sure whether the old BC from that 2012 thread used an analogous method), so IC2 should be able to exclude the upgrade slots from the return value of getSlotsForFace. However, I've gotten the impression that the IC2 devs are busy behind the scenes updating the mod to a newer version of Minecraft, so we'll probably have to wait for that first.

    I can't tell from the image, but maybe your energy storage is full? That will cause the stirling generators to stop production, the heat exchangers to stop exchanging, and the hot coolant to build up in the reactor. When the reactor's hot coolant tank is full, it will stop outputting HU and start building up core heat. If this is what happened to you, the simplest answer might be to connect some empty energy storage so the stirling generators (and heat exchangers etc.) can start outputting again.

    In the Pull Request, , some players objected to no longer being able to pull from input hatches or push into output hatches. This made no sense to me when I assumed they were talking about doing it with automation (e.g. pump covers on the input hatches). However, further comments clarified that they are apparently instead using the hatches as a workaround for the lack of a manual, non-powered way to empty fluid containers into single-block machines' input tanks and fill them from single-block machines' output tanks.

    If I'm understanding Leagris's most recent comment correctly, both draknyte1's PR and my "improved" version are apparently pointless, but let me try again to respond to the summary points:

    1. "Fix single-block machines and GUI to allow free input output of fluids" - I looked a bit more into this, and there isn't really room for leaving fluid containers next to the input/output tanks. I haven't found where they're actually handled, so idk whether I could add in-gui "click to fill/empty" functionality, but I might be able to add a way to fill the input tank with a held fluid container or fill an empty held fluid container from the output tank. Edit: I've added the in-gui "click to fill/empty" functionality (in a fork, Pull Request not started yet), though I haven't added a tooltip or anything to make it clear that you can do that. I haven't entirely decided whether to still add the in-world interaction, but I can deal with that after I've had some sleep. Edit 2: probably not worthwhile.

    2. "Fix machines to only have to deal with a single copy of a recipe using fluids regardless of contained or raw fluid." - nice idea, but tricky to implement, especially when you think about outputting empty cells afterward.

    3. "Fix remove the now useless plunger." - The plunger is kind of useless now, given that you can wrench the machine to completely clear the input tank (as opposed to what, 1000L at a time with the plunger?), but might not remain useless - see below.

    4. "Fix remove the now useless fluid canner." - There are a few special and non-reversible recipes in the fluid canner - batteries (fluid redstone, sulfuric acid, or mercury) and coolant (for use in nuclear reactors), plus inserting/removing the cells or other fluid containers can be automated. (Edit 3: that is less unique to the fluid canner than I thought; input/output hatches allow this, though with restrictions on which sides allow automated input/output, plus there's quantum tanks, and the cheaper tanks from GT++) I have to vote against removing it completely.

    5. "Fix machines to keep their inventories, power, state on harvest." - nice idea, but could make the plunger less useless, and machines that have such state would no longer easily stack in a processing array.

    Rename the Steam Turbine (blades) to Turbine blades, as it seems illogical to put a Steam Turbine (item) in a Steam Turbine (block). This was suggested by Su5eD, but due to a small mishap with threads merging, I write it down here instead.

    Isn't there already a "steam turbine blade" item? That you use three of to get the "steam turbine" (item)? Renaming it to "turbine blades" would re-target the confusion instead of eliminating it. I think Su5eD also mentioned "turbine rotor" as a possibility, which would better alleviate the confusion, or perhaps the block could be renamed instead.

    That must have been it, forgot what Su5ed suggested before I edited his post here. Fixed it now.

    I bred some oil berries, but the cropnalyzer shows they only go up to size 3, though in GT5 they went up to size 4, and there are textures for 4 growth stages in the latest ic2 build (#220).

    Okay, I've come up with a somewhat different strategy for crop breeding that makes the seed scanning machine less urgent, but now I'm realizing the configurable custom crops from your "Useful Crops" addon would be attractive (so I can add some crops for resources used by other mods). Any chance of an update for that, or do you plan to add a similar feature to core IC2?

    I'm guessing that right now they have "busy porting the mod to a newer version of Minecraft" as a decent excuse to postpone considering this. I realize we have no way to force them, but I'd be happy if they did open-source the mod after that, or at least post an official explanation of why they refuse (I've been unsuccessful at finding such an explanation previously posted).

    Fair enough, but I made myself a small utility program to check random weights for crop breeding, and apparently the ender blossom crop is currently unreachable.