[V1.23] nPower plugins - IC Efficiency 0.7, BetterMiner 0.1, qSuitCtrlPatch 0.2 - BUKKIT support!

java.lang.NoSuchMethodError: buildcraft.core.PersistentWorld.getWorld(Lte;)Lbuildcraft/core/PersistentWorld;
at buildcraft.transport.TileGenericPipe.bindPipe(TileGenericPipe.java:125)
at buildcraft.transport.TileGenericPipe.n(TileGenericPipe.java:81)
at jf.a(Chunk.java:612)
at jf.a(Chunk.java:590)
at pi.a(SourceFile:188)
at ix.a(SourceFile:42)
at ja.e(ChunkProviderServer.java:105)
at ja.c(ChunkProviderServer.java:56)
at ae.<init>(PlayerInstance.java:28)
at so.a(SourceFile:184)
at so.a(SourceFile:250)
at gm.c(SourceFile:95)
at fi.b(NetLoginHandler.java:121)
at fi.a(NetLoginHandler.java:41)
at dr.a(SourceFile:94)
at net.minecraft.server.MinecraftServer.h(MinecraftServer.java:369)
at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:287)
at ce.run(SourceFile:417)

That's what happens with the duping fix in SMP. You really should have taken the 30 seconds to test it...your fix is useless in SSP (someone duping there is just cheating themselves)

Quote from nallar

Not strictly IC2 related...

Fix for BC item duping and tileentitiy issues!

http://www.mediafire.com/?step3vo293dh61u

It should work for SSP/SMP, same file, might need to recompile against server and rerelease though. Post if it doesn't work with server.

Display More

Doesnt work on bukkit.

If you do get permission to use adf.ly/adcraft.co, use adf.ly. If you have both, I'm fine, but anybody running adblock can't use adcraft.co. It's really annoying.

I'm not sure if this is a bug or what happened, but I made a solar farm with a 40 long tin cable and put solar panels on all 3 sides. The output was 1/3 of what I would expect. This mod was the only ic mod I had installed. After I removed the mod, my readings went back up to normal. My mass fab also started going MUCH faster so it was defiantly not just a visual thing.

I investigated this further. Whatever you did to tin, it now has cable losses. The farther away the solars are from the receiver (batbox/mfe/etc), the more energy is lost. I did take a look at the decompiled code to see what you did but it's kind of a nightmare of functions...would take a long time to figure out how it works.

For short distances of cable and then a batbox, it works fine.

Would this be what's causing the losses with glass cable as well?

I made a test with an MFS Unit and two wings of 16 panels using; 32 solars, 10 glass fiber, 1 MFSU.

Daytime run, expected energy value: 417600, total value attained: 374920.

There are two possibilities I see.
1) Not sending partial packets at the start/end of the day.
2) Some odd cable length loss calculation.

I don't think it's #1, as the worst case losses for that would make the final value 384832 or greater.

Edit:

Tested with 3 solar panels at one end and a batbox at the other end, of 36 TIN wire.

1 full day's collection of energy: 3952

That is approximately 1/10th of what it should be. It seems as if you are calculating cable losses in floats instead of applying a more accurate formula.

You should calculate bursts as: Normal packet if traversing the cable type * number of packets; all of which can be determined via integer operations. There should be no floating point at any point in that chain of calculation.

BurstFreq = floor( min(cable_type, storage_type) / normal_packet ) << 'integer' operations result in the floor already
ResultForStorage = (BurstFreq * (normal_packet - (int)cable_length/(int)one_loss_cable_length))

I tried the efficiency fix but it didn't address the generator lag - for me, it's likely a sound-related issue.

BUT, I have to say I LOVE the QSuit fix! So this is how Alblaka meant the suits to work before Notch's sprint change messed up the bind? I can run and jump so much more effectively now. Thank you.

I just tried the latest version. It's still off by at least half.