If you're using 1.10 or above it would be
IRecipeInput input = Recipes.inputFactory.forStack(new ItemStack(Items.EMERALD));Otherwise (ie using 1.9 or below) it would be
IRecipeInput input = new RecipeInputItemStack(new ItemStack(Items.EMERALD));It's not that no one cares, just there isn't anywhere for it to strictly go. Apparently there was never a release thread made for 1.5.2, just a temporary testing one that has gone now.
It's been broken since 2014, apparently the 1.5.2 beta testing thread where that used to link to is gone now. The first page at the very least was archived from that though.
You'll need to implement IEnergySink if you want it to accept power too, but otherwise yes. If your block is like an MFE in that it stores the power it can accept and send, implementing IEnergyStorage is probably a reasonable idea. If you want a BasicSource equivalent it'd be worth looking at BasicSinkSource.
Just the normal version. You shouldn't ever need the dev or api versions unless you're making an addon or otherwise testing development code.
Once you've got a normal Forge server setup all you need to do is put the IC2 jar in the mods folder, very similarly to how you install it on a client.
You'll need to implement IEnergySource on your generator tile entity, post an EnergyTileLoadEvent when your tile is loaded and an EnergyTileUnloadEvent when it is unloaded. You can take a look at BasicSource if you'd like something that can handle (nearly) everything for you, or just as an example of what you might need to do.
The API jar comes with all the source files for it, so there is documentation and general comments there. If there is anything in particular you're unsure about then feel free to ask here too.
The first is certainly closer to what you want then, it has an actual PvP focused server alongside another which is less focused on it but still has areas for it from what I remember.
Some servers do have dedicated launchers, so I don't think it is necessarily a requirement. Narrows the options down greatly otherwise though.
The easiest method will be do add the IC2 maven within your build.gradle and declare the API as a dependency:
repositories {
maven {
name "IC2"
url "http://maven.ic2.player.to/"
}
}
dependencies {
compile 'net.industrial-craft:industrialcraft-2:2.8.101-ex112:api'
}Refreshing your project if you've imported the gradle file or running gradlew eclipse/idea if you're using the command line will then compile with the IC2 API too.
There is no interface to mark an item as being a wrench, just blocks that support wrenching implement IWrenchable. So if you were making your own wrench you'd want to react to right clicking an IWrenchable block.
It always used to be that Buildcraft was a good pairing as it provided the transportation that IC2 lacked without adding much more around it like EnderIO for example would. Thermal Dynamics would probably also work for pipes if you'd rather have a slightly easier experience, albeit less thematically with IC2.
Storage is more of a personal preference, Iron Chests is the classic solution but there's so many options depending on whether you want denser storage (from something like AE2 or Refined Storage) or more expansive storage (such as Iron Chests or Storage Drawers).
Other things you might want also depend on the kind of play style you want. IC2 lacks any wood farming, so Forestry can be useful for that. But if you're not building much to use the wood you probably wouldn't need it. Longer distance transport could be covered by something like Railcraft or Ender Chests as IC2 only offers teleporting players about with teleporters. JEI for crafting and machine recipes is a sensible choice, but that's normally a given for modded worlds.
Otherwise you don't really need much else (as after all you can play just IC2 without anything else), you can always add more mods as you go along if you feel something is missing (or offer a suggestion for IC2 
)
I also noticed that the heat exchanger code for transfer() looks extremely buggy. Your notes say that you adapted the code from IC2 code, so then I went and checked it, and wow, it matches. I find that to be a bit, um, unsettling. Is there a way that we can file bugs against the IC2 code?
Likewise, your code for adjustCurrentHeat() returns a negative value in cases where the component overflows and in cases where it underflows. I checked IC2 decompiled code and saw the same thing. Since you are trying to mimic what we see in the game, you did the right thing, but wow, that is really interesting. I'm wondering if it is possible to abuse these bugs and make a reactor that performs far better than it should.
Bug reports can go on Mantis if there's something awry, if you don't especially want to create an account there you can just post in here) . I doubt there is any normal scenario where overflowing could happen, at least to any kind of advantage, but a lot of the reactor logic is quite old so imperfections are possible.
Hmm so they did. The bots are learning...
You can at least put cactus directly onto crop sticks, so if you manage to find a desert and get some natural cactus the eating plant isn't too much of an issue to get. If you can't find cactus then you are certainly right about it being more of a pain to breed for.
The later versions do also have a command to allow giving you a cropcard of any crop with any stats you want, but that was never backported to 1.7 from the looks of things
The eating plant is effectively a cactus crop, so long as you're using a new enough IC2 version that adds it.
A screenshot of the scenario you've got could be quite useful, it might allow more certain suggestions than just general things. Like Gus said light level is an obvious one to get caught out with, theoretically crop fertilisation or air quality could be a problem too if you've built around the crops since you last used them. If breaking the dirt the crops are on and replacing it still doesn't allow you to place anything it will definitely be a condition that's changed rather than a problem with the crop at least.
