Posts by Player

    If you want to ship the IC2 api, extract the api zip to src/main/java (next to your own files), otherwise extract it to src/api/java.


    You could also use the deobf jar and reference it as a dependency, see http://www.gradle.org/docs/cur…tml#sub:file_dependencies
    example:

    Code
    dependencies {
        compile files('some/path/industrialcraft-2-dev-deobf_2.1.445-experimental.jar')
    }


    Do NOT put it in buildscript { dependencies {} }, but in the root of build.gradle.


    In eclipse just add the deobf jar as a library to your build path.

    Btw. Creeperhost doesn't explicitly state that the cpu cores you rent are actually physical, they may be logical cores (hyper threading) and thus subjected to performance influence by other instances. I also don't see anything about which CPUs are being offered, could be some slow AMD manycore CPUs...


    Advertising 3 TB/month as "Data Transfer Unlimited" sounds quite fishy to me, that's well below what various other isps offer as limited packages, even in this price range.

    Opis doesn't catch everything, even /forge tps won't. It's only easily possible to locate time spent directly in the regular TileEntity and Entity update methods, but some processing happens globally.


    FC 1 is running with 6 GB, 2 GB may barely do it, 4 GB should suffice. The extra is important to symptomatically work around memory leaks and to keep enough memory for lazy garbage collection (memory freeing/management).


    The player count isn't really something influencing memory requirements a lot in a heavily modded server, a player is just a large chunkloader there. If those overlap a lot, overhead by player count is small.
    Every loaded chunk is about 200 kB, a player can load up to 441 chunks at default view distance, thus about 87 MB worth of chunks when there's no overlapping. You'd need dozens of players at the same time to have more impact than general mod leakage ;)

    What you want is just a hoster which offers you at least 2 dedicated physical cpu cores or even a complete machine. The cpu should be Intel, ideally last gen and high frequency, like the xeon processors targetting workstation use or desktop core-i7. Single thread performance is key for minecraft servers.


    The hoster can't do much about performance anyway besides providing decent hardware and not overcommitting on mc server instance per cpu core count.


    You as an admin can use tools like OPIS from ProfMobius to locate where slow setups are on the world, educate your players about what's causing issues and tune your mod+config selections to avoid issues. The worst are entities, avoid mob spawners, keep the number of smart mobs down (golems etc.), transporting entities (including dropped items) with water or even through portals. Use personal anchors instead of normal always-on chunkloaders or better none at all. Don't have excessive redundant machinery. Avoid fast travelling (like MPS flight) while you are not alone on the server.


    If this doesn't suffice I have a mod in development which can generate more sophisticated data about performance issues, but it isn't really user friendly yet.


    Before someone mentions thermal expansion as a "solution", TE is only insignificantly more efficient, but it has continuously had severe bugs in its conduit code since the beginning, causing memory leaks and sporadically performance bugs bringing servers to a halt.

    - I'd use only 1 item, not 2 unless there's special requirements e.g. for stacking -> getChargedItem and getEmptyItem are the same.
    - getTransferLimit returning 0 makes it useless, you can't charge it then. It's the max amount of eu to charge per tick.
    - setMaxDamage(2) is a bit low, that won't allow displaying the charge level well using the damage bar, ic2 uses 27
    - for the creative page, you'll have to add your item manually, once discharged and once fully charged. You have to charge it yourself while doing so. To implement this override getSubItems and add 2 stacks of this item after passing each through ElectricItem.manager.charge with charge = 0 and Integer.MAX_VALUE (or maxCharge, same effect) respectively. Set ignoreTrasnferLimit to true in those charge calls.
    - Don't instantiate your items like that. It's recommend to do so in preInit, not while declaring them, which would create them way too early.


    Extending ElectricItem isn't required/recommended, it just needs to implement IElectricItem properly

    Chunk resets caused by the usual bugs are being logged reliably, afaik when loading the chunk fails. If there's nothing in the log it's most likely something else, e.g. running out of disk space, os/hw level faults, unlucky crash timings or hard jvm crashes. MCPC/Bukkit may do things differently though.

    While energy crystals are now 4 times as expensive, most of the recipes which used to contain them require less crystals than before or even just a lead battery - which doesn't cost any diamonds. The MFSU costs 4 times as much, but its comparable to 4 old MFSUs capacity or power wise or even 16 to have both the same capacity and power (4 parallel lines of 4 in series).


    Diamonds aren't really that hard to come buy, branch mining around y=12 yields plenty, esp. if you start using the mining laser in horizontal mode, a fortune enchanted pick for mining the diamonds and/or nv goggles. A max size quarry run yields about 50-60.


    Adjustable difficulty levels are planned, but I think the current setting is a good baseline for someone who doesn't rush through the tech tree just to get bored quickly and start over.

    The code you are referring is decompiled code, it isn't necessarily identical with the original source.


    The compiler replaces variable argument lists somefunction(type...) with an array somefunction(type[]) and calls to such a method somefunction(arg1, arg2, arg3) with somefunction(new type[] { arg1, arg2, arg3}).
    Once compiled both are identical, but the variable list one doesn't require building the argument array manually.


    You probably want to do something like Recipes.macerator.addRecipe(new RecipeInputItemStack(inputStack), null, outputStack).
    If your input is registered in the ore dictionary, you can also do Recipes.macerator.addRecipe(new RecipeInputOreDict("oreDictName"), null, outputStack).