Search results

Item IDs in the 1.7 Forge are automatically handled. No conflicts until you have more blocks than fit in the available space (which, to my knowledge, is currently impossible).

Right, extractor -> destination pipe -> ME interface -> ME interface -> provider -> final destination. Ooh, I had forgotten about that one. Yes, this should be quite good for the task, letting you skip putting things into and out of ME altogether. So, EnderIO conduits are teleporters? Good to...

No, look closer: at logisticspipes.proxy.cc.CCProxy.getTaget(CCProxy.java:109) [...] at logisticspipes.recipes.LPShapedOreRecipe.func_77571_b(LPShapedOreRecipe.java:47) at thaumcraft.common.lib.ThaumcraftCraftingManager.generateTagsFromCraftingRecipes(ThaumcraftCraftingManager.java:753) [...]...

Yeah, the issue seems to be that Forge is somewhat unstable, and mods built against different versions thereof won't work together at the same time. Give it a couple more weeks and we'll probably have Forge for 1.7.whatever-the-current-one-is, and mods for it.

There's also the option of AE-mediated Logistics Pipes. AE can power LP, and unlike buses, interfaces are super-fast at importing and exporting items. So, extractor pipe -> ME interface -> other ME interface -> provider pipe -> final destination is an option, and should help keep down the number...

The problem is that this error is perfectly generic -- unless someone notices a mod known for causing this error, they won't be able to help. However: the error is a concurrent modification (someone modified a hashmap at the same time someone else was iterating it) this generally happens when...

You could be at the per-player chunk loader limit, or the server may be configured to ignore the chunk loader you're using. If you have Opis (and, potentially, sufficient privileges), you could check if the chunks are actually being force loaded. Likewise, if you have access, it might be worth...

Okay, I don't know why I'm chiming in here, but here I go. Let me give you the perspective of the, um... hundredth? Two hundredth? Anyway, after very many worlds over the course of nearly four years (my Minecraft payment receipt email is dated 2010-09-09), and having done just about everything...

Buildcraft has a block called Flood Gate, which is a kind of anti-pump -- it places fluid blocks into the world. Using that with water should work, but it'll almost certainly flood any connected caves, and I'm not sure if it stops at its own y-level, either.

Good point. For that matter, I could see this being configurable on a per-item basis, as well, in case the per-mod granularity isn't sufficient.

I actually had in mind differences in actual code -- which is what I term 'behaviour' (your example was of differences in recipes). Let's take another (contrived) example: a mod comes along adding a Uranium ore, and specifies that when the ore or its ingots are in your inventory, they slowly...

Well, they do warm you up. That can be helpful, in some circumstances. Otherwise, fully agreed.

That's actually something @immibis pull-requested into Forge once (it was not accepted). I can see only one problem with this, and that's when you unify two items with different behaviours, for instance: if two mods register the same unobtainium dust ore block, but one of them has it drop 2-4...

Come now, The Offspring's "Pretty Fly (For A White Guy)" wasn't that long ago, surely. 1998 was just yesterday, right? Right? Man, I've had a whole bunch of years, haven't I? Here's to many more!

What I want to know is how they do on a smeltery. Fluiducts are already pretty good, but this seems an even better fit for auto-casting.

I think @Bevo's Tech Pack may qualify.

Yeah, I'm not too bothered, just somewhat disappointed.

Guh. Can't believe my first post on here was a reply to an ancient thread that someone felt the need to bump. Thanks, @Not_Steve, that was really nice. /s

Does MF2 have ExtraCells? 'Cause fluid storage drives are stupidly efficient.