The electrolyzer already allows water to be turned into oxygen and hydrogen
The whole concept sounds interesting, as well as probably very expensive resource wise. How big is huge for particle accelerators? Like 10 blocks big or 5 chunks big?
The electrolyzer already allows water to be turned into oxygen and hydrogen
The whole concept sounds interesting, as well as probably very expensive resource wise. How big is huge for particle accelerators? Like 10 blocks big or 5 chunks big?
The best mod since GregTech yesterday?
Either way I suppose you can, providing you put a link back here with an explanation how it's not actually your mod.
it went wrong because of a looped call.(when the block tried to join an energy net
Do you have a crash report/log of this? The code itself looks ok, but onLoaded() should probably check if addedToEnergyNet is true before posting an energy load event.
this block also has something wrong when rendering in the world... (although it seems to be my bad)
That's from this line, you'll want to change it to
Definitely looks like the energy sensor kit is nulling a stack's item when making cards.
Is this version stable? I can obviously see that 1.23 is the current release version, so is this 1.24 what would be considered developmental, and prone to have bugs?
I'm just wondering if I should download and use it, instead of 1.23. I like to always have the most up-to-date mods.
1.24 is designed to work with the latest Optifine, so if you've not got that I doubt there's any difference you'd see between them.
这已经成为一个坟贴了?
If there's no news then nothing's going to get posted here.
I attempted to use a energy sensor kit on a GT6 battery box today and it crashed the server http://pastebin.com/ieSFJahM
The only situation I can see that happening is when an itemstack in the player's inventory has a null item, as FTB Utilities checks if the stack itself is null before trying to add it to the NBT tag list, but will add null if the stack's item is too (which causes the vanilla code to crash). How it manges to get into that situation though, I've not looked into. It could be from turning a kit into a sensor card, but that shouldn't set the stack's item null (unless the NC code does do that, in which case the crash is purely bad timing in it saving during that period).
Try using older MCP mappings, Forge has probably changed the one they were using forever to something slightly newer.
Ah yeah, that would make sense. It should probably change to 1.10.x to remove any ambiguity.
"The User can easily fix it by basically MineTweaking the Recipe using the Config File", does not change that the User has to figure out the Config File to fix a broken Default, not to mention that it wont work on Servers, if the Server Owner is a lazy bastard.
A broken default implies there's a fix, the UU values would all have to be rethought (changed) to get a real replacement for obsidian. Otherwise it's just making up another number that's smaller but not really much more right. But hey, maybe they should all be rethough, the world alone isn't the best measuring target.
You can easily fix it because despite being auto-generated, they are still fundamentally loaded from a file. You can add extra values in the config that will overwrite the default IC2 comes with, and the scan command allows more accurate scans for the installed set of mods to be made which can be tweaked once made too.
IC2 doesn't have a version supporting 1.11 yet.
It's a known bug, being worked on.
It'll be those cables, reactor chambers are more complicated than a normal machine in e-net terms, as they act as a bridge to the main reactor block rather than an emitter themselves. Try putting the power into something like a MFE then using the cables on the output of that.
There might have been one for 1.7.10 that was just missed whilst porting to 1.8 (or to 1.9 or 1.10). It's a logical enough feature though so I'll add it when I've got time.
There's a huge array of Quantum Solar Panels powering the replicator itself, which combined with the large replicator energy buffer must have meant it had enough for each operation and could be refilled fast enough to keep the speed going. Overclockers don't scale linearly too, hence it only takes 31 to replicate iridium plates that quickly despite them taking more than 31 mb of UU.
It's very much dependent on what you're trying to make. The amount of UU consumed is normally 1 mb/t, but this can be sped up via overclockers. The replicator itself has a limit on 1 item per tick however (unlike other machines that are limited to a stack/tick), so providing you can power it, that's the fastest it can go. But of course the more UU something needs the more overclockers it takes to produce it at 1/tick.
Yeah, or keep the MFSU and just have 4 separate HV-transformers.
The transformer claims it takes in 2048 EU/t, but that's only once every 4 ticks, so it ends up drawing an average of 512 EU/t from the MFSU. It makes perfect sense that the output is fractions of 512 EU/t if it only outputs a single packet.