Posts by immibis

    Well, a big difference between RF and EU is that EU can overload machines since it comes in packets. You can see these as the voltage of the cable.
    For example, you can have packets of 512eu/t or 32eu/t. You can also transport RF at xxxRF/t, but these packages have no influence on the machine they are connected to.
    An important thing to keep in mind is: without upgrades/transformers, you can blow up your machines, smelt your cables, etc.
    RF on the other hand is a pretty consistent flow that doesn't have any impact on the machines.
    In short: EU challenges the player to set up a proper electricity net, where he/she has to think about things like losses (higher voltage = lower losses), right voltages for the right machines, the correct energy buffers, etc. RF is just creation > storage > usage and for each (including the transportation) you can use pretty much whatever you want and connect it to whatever machine you want. This requires no real thinking.

    This is false and has been false for at least two years now. You've described how EU used to work, but not how it works now. The way it works now is pretty much identical to RF, except not interoperable with RF.

    Question : I tried ARS with IC2 classic Speiger version, and it seems that ARS blocks doesn't require power, is this due to ARS not detecting IC2 classic and going "vanilla" mode ? Also, IIRC there was a RF/EU/kJ power option but I don't see it in config...

    Look for a preferredEnergySystem setting in immibis.cfg, and try setting it to ic2.

    Is the Programmable Filter meant to only connect to Industrial Tesla Coils under it? That's the only face that the data beam comes out from. And it is always there too, I presume it's only meant to be shown when connected to something?

    It should face away from you when you place it. It should always be there - it shows you where to place the connected block.

    how would i set a force field to allow a specific player to pass through the force field but not others?

    this way i can setup so that it protects me and i can just run through it?

    You can't. Intentionally.

    edit 2: i found out that galacticafts glass fibre block allows EU to flow through it with the field on.. i have not tested buildcraft or anything.. but it would be nice to have some way of getting things into the field without turning it off!

    Couldn't you just put a batbox/CESU/MFE/MFSU in the same place as you put the glass fibre block?

    but i still can't figure a way to have it allow a person it but not others or require a key to get into !

    You can't. Forcefields are forcefields, they wouldn't be very good forcefields if you could walk through them.

    1. why not have the emitters directly powered and turned on by redstone?

    2. why have it remote.. it does not feel right to have all this "wireless" since you still have to give a redstone signal to turn it on.... ( remote control would be awesome for this if it was kept wireless)


    Good day.
    So, does crash with forcefields upgrades pointing in unloaded chunk was fixed?
    Thank you for reading and again - good day.

    I don't remember ever hearing about such a bug. Can you elaborate?

    I started to use this mod just recently - and it is only one forcefield mod working with ic2 and newest version of ic / railcraft/buildcraft and etc. so - question is is it maintaned anymore? i can;t find any entrance module like mffs had.

    What is an entrance module?

    You can "poke a hole" in a forcefield if you have a tube projector pointing through another forcefield. They have to both be linked to the same forcefield core.

    Have an update!

    • Renamed many API methods to avoid conflicts. (If you have any of the exactly 0 mods that use the IC2 Classic API, then you'll need to update those)
    • Fixed the extra garbage text in seed bag tooltips.
    • Fixed rubber tree leaves evaporating.
    • Fixed two secret recipes that should have used the ore dictionary, but didn't.
    • Fixed drills and chainsaws being unusually slow on some blocks. (Blame Notch)
    • Fixed diamond drill recipe not working.
    • Made sure Nuclear Control, GraviSuite, and Advanced Solar Panels work with the compatibility module.
    • Fixed electric tools being enchantable. (Armour still is, since it seems less weird - in particular, most of the armour enchantments just add more protection)

    Also, what's everyone's favourite version of GregTech before GT5? (GT5 was the rewrite where every machine was tiered and GT had its own energy system)

    Hello. Why gregtech 5.07.07 run 3 minutes, while other mods (IC2exp 658build+BC6.2.6+Forestry 3.3, TiC 1.8, TE+MFR, TC 4.2.3+TT, Mo'Creatures 6.3) much faster? And when many mods Greg slow start is not for 3 minutes, and all 7. As a result, the start time 13 minutes. It slowly.
    Whether it is possible to optimize it?

    The majority of that time is spent looking for recipes to delete. True story.

    But no, I don't think it can optimized in a sane way.

    My Problem is that there is only one thing where Block-MetaData matters, and that is the Harvest Level of the Block. And the Block ID matters only for the Material it is made of and the Sounds a Block makes. But I will indeed use Groups for such TileEntities in order to sort things out, in order to get axe/wrench/pickaxe/etc for them to work.

    All electric machines have the same harvest levels, right? So they could use one metadata value. Same for each material of pipe (I'm not sure if tungstensteel pipes are harder to break than bronze; if not, then all pipes except wood). And then for steam machines.

    Still much easier than having a dummy tile entity that replaces itself.

    My newer Solution is a TileEntity that only stores one Short of Data and then does a setTileEntity call on its position to replace the TileEntity, once it is loaded. With that Method I don't need to implement every fucking Interface in the World in one Delegator TileEntity.

    Speaking as someone who's tried something similar in the past:


    Just have one tile entity class per block/meta combination, like a normal person.

    If you want to save on block IDs, combine similar machines and delegate only the necessary parts. For example, all the bronze steam machines are pretty much the same (they only differ in icons, steam usage stats, number of input slots, and how they decide what the output), so you could have one TileEntitySteamProcessingMachine with a field (either an enum, or a delegate object, or a plain old int) that tells it whether it's an extractor, a compressor, a macerator, a furnace, a forge hammer or an alloy smelter.

    Same for the electric machines, although they have slightly more variation. Some of them have fluid inputs, so either every electric machine implements IFluidHandler, or you have two different tile entity classes and therefore two different metadata values. My preferred solution if I was making GregTech would either be one metadata value per machine type (with voltage in NBT), or one metadata value for all electric machines (with voltage and type in NBT).

    Pick groups that you're not likely to change later. It's possible that you might add a fluid input to an electric machine, so "electric machines with fluid input" vs "electric machines without fluid input" isn't ideal (but still works; you'd just have to add migrations), but a bronze machine will never ever ever be made to consume electricity, so separating bronze machines from electric ones works.

    Another group would be item pipes - they vary by texture, visual size, capacity, and whether they're restrictive. Same for fluid pipes (plus whether they can hold gasses). Cables vary by texture, max current, and max voltage.

    For items, put them in logical groups however is most convenient. Probably all crafting ingredients can go in one item, or one per shape if you want to be future proof (easier to expand with more materials and shapes, or add special abilities/interfaces to specific shapes). Don't be afraid of NBT; several mods use NBT to differentiate items instead of damage value, and it works fine. (You could have a "material" and "shape" tag for crafting ingredients)

    Yep, you're right. But a time someone will actually access my addon in his mod i will celebrate. Anyway, this is easy to fix, thank you for showing me this.

    Would you mind fixing it? I'm trying some experimental stuff (not in any of my mods, btw) and this breaks it. IHL is the only mod I'm testing with that does this.

    This seems to work with both Immibis Core and Nuclear Control.

    Energy counters and average counters from Nuclear Control don't work currently. Thermal monitors, remote thermal monitors and reactor sensor cards do work. Energy sensor cards do work. Nuclear Control uses some IC2's networking features that were previously removed (because vanilla already had those features); they have been re-implemented in the compatibility mod.

    Also, did the buttons in the thermal monitor GUI work previously? I can't see how they possibly worked with real IC2, but just in case, I fixed that bug with some more ASM.

    If the (GregTech) tool hits the block but doesn't appear to damage it, the tool's correct but the mining level is too low. The Universal Spade is a Shovel-Saw-Crowbar, so it can be used for a lot of things.

    The highest level material I currently have access to is level 3 (using diamond or thaumium). A diamond universal spade is still unable to break a Railcraft metal post.

    I then tested with creative mode. A neutronium universal spade (mining level EIGHT) is still unable to break a Railcraft metal post.

    Okay then, I'll try fixing it a different way. (JAR attached to this post)

    IC2 Classic does not (or is not supposed to, anyway) rely on Immibis Core. Neither does the compatibility mod - it's just set to load after it if it's installed (Unless Forge broke something again and it's treating that as a requirement?). This is necessary since Immibis Core does something slightly weird that otherwise causes it to not work with the compatibility mod. There could be other mods that do similar things.

    IMetaDelegate is not implemented currently. Not implementing it won't break anything inside IC2 Classic, only other mods that use the IC2 Experimental API (which it's from).

    The new version attached to this post should fix the ClassCircularityError (not sure why I didn't get that crash in Eclipse though) and the dependency cycle with Immibis Core.

    Also a thing. Immibis added ASm to the IC2 Classic thing. Which is really not required... He makes that to make FakeMod that says i am IC2.... which is not really a need.

    Sure it is. Otherwise, what happens when a mod says it requires IC2, and IC2 isn't installed? (Answer: Forge gives you an error messages and refuses to load the game).

    Also note that it's not in IC2 Classic proper, but in the API compatibility mod.

    And, because of the previously mentioned API changes, some amount of compatibility with IC2 Experimental is now possible!

    Install the latest version of IC2 Classic, as well as the mod attached to this post (which you should regard as being experimental and unstable), and some IC2 addons.

    It seems to work with at least my Advanced Machines and Advanced Repulsion Systems. Please report any mods that don't work, and any crashes you get.

    Updated (release 1.7.10-7).

    New changes:

    • Internal API changes, to bring things more in line with IC2 experimental where possible.

    • Ore-dictionary saplingRubber can be extracted.

    • Sticky resin is registered in the ore dictionary as itemRawRubber.
      It should now be compatible with MFR raw rubber.
      This should work both ways - MFR raw rubber can be tripled by extracting it.

    • As a side effect of battery item API changes, full batteries won't fit into charging slots
      and empty batteries won't fit into discharging slots. Since the whole "items not fitting in slots"
      thing is annoying to start with, expect all of these to be abolished in a later version
      if there are no objections.

    About the Railcraft Issue: Even though it happens to my MetaItems, the far more important thing is, that it happens to both, Empty Fluid Containers and full Fluid Containers, instead of only full Fluid Containers. Such a check for a Container to be full/empty is needed for this purpose. And then all of a sudden my MetaItems would work again, as a Side Effect of this full/empty check..

    I submitted a PR to Railcraft, because apparently CovertJaguar wants to give me "one more chance", even though I'm not sure what I supposedly did the first time.