Posts by Chocohead

    You'll definitely want to implement IReactorComponent, for a simple fuel rod I guess you would just follow the same logic that ItemReactorUranium does to implement all the methods. Some of the IReactorComponent methods aren't typically needed for a fuel rod so looking in Uranium's super class shows you what the defaults should be to avoid unintentionally interfering with the reactor (which leaving Eclipse's auto-generated returns could do). The logic won't transpose perfectly as Item (which you'll want to be extending too) doesn't have all the methods Uranium needs in terms of damage storage especially, but fundamentally you're just storing the value in the ItemStack's NBT and don't need all the extra logic IC2 has for flexibility so the amount of implementing for that you need to do is reasonably limited.

    Doing a completely custom fuel rod implementation is all about doing the heat producing logic in processChamber and doing power production either in acceptUraniumPulse or also in processChamber, depending on how you want your fuel rod to work. A reactor only ticks once a second (rather than the normal game's 20 times), so things at slowed down more comparatively to make live debugging a little easier without needing break points.

    Thanks for updating this. Just a simple bug report the drill not sure if there was more then one caused 100% desync in SP for me. Sort like when you mine too fast but this was 100% of the blocks it broke (tried grass/dirt)

    I've not had any desyncing problems in particular with the drill, I'd have expected the Vajra would be more likely to cause it breaking blocks instantly. Was it with one mode of the drill or just in general?

    Whilst it is certainly possible to add new crops into the game using the API, I don't think there is anything for adding them via scripty type files. I guess technically speaking it would be quite simple to add crops that had basic requirements defined in XML or JSON. Something I (or someone else of course ;) ) could look into if you have a use for it.

    That was part of the changelog in 107, the full 109 changelog on Curse covers every change from the last release (72) to 109. Full Drop just needs anything newer than 106, it isn't fixing a bug per say just tweaking the balance of the mining laser.

    BuildCraft hasn't worked out their own balancing numbers fully yet, support will be added once it enters beta. No idea when that'll be (don't think the BC team knows either), but there is no guarantees any value for the other fluids we add now would be consistent in the future.

    The Blast Furnace needs three things to run, iron ingots to make the steel with, heat and air.

    • Iron ingots are the simplest, that's just your normal vanilla iron. If you forget it then it might look like the blast furnace isn't working as it will stop needing heat. Iron goes in the slot to the left of the arrow in the middle of the GUI.
    • Heat is produced from heat generators, such as the Solid or Liquid Fuel Fireboxes or the Electric Heater. You have to make the heat producer's red square touch the Blast Furnace's red square. The wrench is your friend here to rotate the square if you placed it down the wrong way. The amount of heat purely determines how long it takes for the Blast Furnace to warm up: an Electric Heater can go up to 100 HU (heat units) but that won't make it go any faster than 10 HU to actually make the steel once it's warmed up. It can't run without any heat at all though (and will cool down over time if not given any).
    • Air is made by putting (empty) Universal Fluid Cells in a compressor. They go in the slot in the bottom left of the GUI (below the tank), and will be returned empty once the air is removed from them (so they can be reused).

    Energy is sent in packets, the size of the packet determines the tier (and thus whether a machine can accept it or a cable can transfer it). A solar panel produces ~1EU so you'll have 1 EU sized packets sent down the cable. With floored loss turned on (which is the default), every time the packet has travelled so many blocks of cable, it will lose 1 EU. Thus with your solar panel, it's going most of the way down the long cable then completely disappearing due to loss in the cable (as 1 - 1 = 0).

    A transformer allows you to increase the size of the packet, so that when it loses 1 EU you'll still have some left. For a single solar panel, feeding it into an LV-Transformer will mean after thirty-two 1 EU packets the transformer will send one 32 EU packet (which is LV tier) which would then be able to go 32x further than a 1 EU packet could. Thus if you used an MV-Transformer (which outputs in 128 EU packets) you could go 128x the distance before all the power is lost.

    Normally you use transformers for stepping down power tier, as a higher output generator such as a nuclear reactor will output above tier 1 which any tier 1 machine would explode if it received. Thus a transformer can be used to break up those bigger packets into multiple smaller ones. Transformers can be reversed to increase the tier however for the purpose you want, to allow it to go further with less loss. With this your LV-Transformer can do 128 EU packets and your MV-Transformer 512 EU. You can set this setting in a transformer's GUI, or giving it a redstone signal.

    The point of a high and low value is what the transformer can accept up to from it's input faces and what it will output. In the normal step down mode the triple dot face will accept up to the high value, and output packets exactly the size of the low value from the other 5 single dot faces. In step up mode the single dot faces take up to the low value, and the triple dot face will output packets exactly the size of the high value.

    If you're not sure still I recommend trying things out in creative so you don't have to remake anything if it goes wrong ;)

    All cables have to be loaded in order for power to be able to flow down them, it produces problems to try and simulate unloaded things. Using transformers in up transforming mode to increase the power tier is the best way to avoid cable loss as the larger less frequent packets lose less as a proportion than smaller more frequent ones. Remember to down transform back again before plugging into your machines though ;)

    The normal recipe override location in config/ic2 applies over the top of whatever profile is selected. So if you want custom recipes that are different between profiles then you'll have to create your own profiles that extend the profile you want them to work with. Taking a simple example of adding more shapeless recipes to classic and replacing the shaped ones all together:

    That profile.xml file can go in a folder or a zip within an ic2_profiles folder in the root of your minecraft instance (ie the same place where mods, config, logs, etc. is in). The file paths can go in the same structure with as much nesting as you want, the sample above would have them in the same level as the profile.xml itself.

    Additional profiles are selected within the main IC2 config by their name, which is case insensitive. Duplicate profile names will log a warning and continue to use the first profile registered with the name. If the profile in the config can't be found it will log a warning with all the profiles it has managed to load and will continue using the default (Experimental).

    This still needs some more formal documentation for defining all the possible options for what you can do, but the classic profile within the IC2 jar has a wide range of them as a pre-existing example.

    The crash is from the game running out of memory, there's only 1GB assigned to it looking at the crash. It'll most likely be happier running with -Xmx2G as a JVM argument rather than -Xmx1G.

    Came back to have a second look at this and Mauve is indeed right. Cooked up a quick addon that will do 100% drops from all but explosive mining since that seems a little less reasonable for nothing to get fried. Theoretically could be added if you wanted though.

    Needs at least IC2 2.8.107 for some tweaking of the laser events.

    The ID is ic2:mining_laser, but the metadata can vary as its charge does. Thus crafting with an empty energy crystal will produce an item with meta 26 but using a fully charged crystal will produce an item with meta 0. Perhaps you'd want something like <ic2:mining_laser:*>, but I don't know if it supports marking wildcards like that (or whether it will also look for NBT differences which differently charged mining lasers will also have).