Skip to content
Permalink
Browse files

Enforce custom MFR PerditionCalculator results

  • Loading branch information
skyboy committed Oct 6, 2013
1 parent fbdd86a commit 58aa8fd739f43880651c89983363e1d4326b9993
Showing with 55 additions and 0 deletions.
  1. +55 −0 src/powercrystals/core/asm/PCCASMTransformer.java
@@ -12,9 +12,14 @@
import org.objectweb.asm.MethodVisitor;
import org.objectweb.asm.Opcodes;
import org.objectweb.asm.Type;
import org.objectweb.asm.tree.AbstractInsnNode;
import org.objectweb.asm.tree.AnnotationNode;
import org.objectweb.asm.tree.ClassNode;
import org.objectweb.asm.tree.FieldInsnNode;
import org.objectweb.asm.tree.InsnList;
import org.objectweb.asm.tree.MethodInsnNode;
import org.objectweb.asm.tree.MethodNode;
import org.objectweb.asm.tree.VarInsnNode;

import powercrystals.core.CoreLoader;
import powercrystals.core.asm.relauncher.Implementable;
@@ -57,6 +62,10 @@ else if ("net.minecraft.world.World".equals(transformedName))
{
bytes = writeWorld(name, transformedName, bytes, cr);
}
else if ("buildcraft.api.power.PowerHandler".equals(transformedName))
{
bytes = writePowerHandler(name, transformedName, bytes, cr);
}

return bytes;
}
@@ -205,6 +214,52 @@ else if ("net.minecraft.world.World".equals(transformedName))
return cw.toByteArray();
}

private byte[] writePowerHandler(String name, String transformedName, byte[] bytes, ClassReader cr)
{
ClassNode cn = new ClassNode(Opcodes.ASM4);
cr.accept(cn, ClassReader.EXPAND_FRAMES);
MethodNode method = null;

for(MethodNode m : cn.methods)
{
if("applyPerdition".equals(m.name) && "()V".equals(m.desc))
{
method = m;
break;
}
}

if (method != null)
{
InsnList list = method.instructions;
for (int i = 0, n = list.size(); i < n; ++i)
{
AbstractInsnNode node = list.get(i);
if (node.getType() == AbstractInsnNode.FIELD_INSN)
{
if ("DEFAULT_PERDITION".equals(((FieldInsnNode)node).name) &&
"Lbuildcraft/api/power/PowerHandler$PerditionCalculator;".
equals(((FieldInsnNode)node).desc))
{
list.insertBefore(node, new VarInsnNode(Opcodes.ALOAD, 0));
list.insertBefore(node, new MethodInsnNode(Opcodes.INVOKEVIRTUAL,
"buildcraft/api/power/PowerHandler",
"getPerdition",
"()Lbuildcraft/api/power/PowerHandler$PerditionCalculator;"));
list.remove(node);
ClassWriter cw = new ClassWriter(ClassWriter.COMPUTE_FRAMES | ClassWriter.COMPUTE_MAXS);
cn.accept(cw);
cw.visitEnd();
bytes = cw.toByteArray();
break;
}
}
}
}

return bytes;
}

private boolean implement(ClassNode cn)
{
if (cn.visibleAnnotations == null)

6 comments on commit 58aa8fd

@CovertJaguar

This comment has been minimized.

Copy link

@CovertJaguar CovertJaguar replied Oct 19, 2013

FYI, this breaks the balance of all mods using the BC power framework, as such if this is not removed in a timely manner, we will be forced to ask FTB does not ship BC alongside PowerCrystalsCore.

@MyNameIsKodos

This comment has been minimized.

Copy link

@MyNameIsKodos MyNameIsKodos replied Oct 19, 2013

So basically, this is turning into the Greg vs mDiyo thing?

@xaviorm

This comment has been minimized.

Copy link

@xaviorm xaviorm replied Oct 19, 2013

That's pretty much it. MC drama has gotten old...Since when hasn't MFR broken balance of other mods. That's kinda what it does..

@Viper-7

This comment has been minimized.

Copy link

@Viper-7 Viper-7 replied Oct 19, 2013

From what I can see... all this commit does is fix broken BC behaviour, making the PowerHandler's applyPerdition method actually use the locally provided getPerdition accessor, rather than directly referencing the DEFAULT_PERDITION static property.

If it is not kosher for a mod to mess with perdition calculations, why does the BC API provide a documented & public setPerdition method? Are these methods to be removed from the BC API without warning? Or does the BC team now have an additional set of conditions by which this method must be used?

The only odd thing going on here is that PCC is fixing a BC bug directly rather than letting the BC team resolve it themselves. On the plus side, when/if a fix is pushed by the BC team, this code will be inert and do absolutely nothing.

@CovertJaguar

This comment has been minimized.

Copy link

@CovertJaguar CovertJaguar replied Oct 20, 2013

There is no bug here. Perdition Calculators are officially supported. And the perdition calculations work as intended.

What this does is modify those calculations so that they no longer work as intended.

@skyboy

This comment has been minimized.

Copy link
Owner Author

@skyboy skyboy replied Oct 20, 2013

What this does is modify the calculations that are only applied when the result of the supplied (non-BC supplied; the BC supplied PerditionCalculator cannot ever reach this code path) PerditionCalculator is considered not good enough. Essentially, when the PerditionCalculator returns the input power as the output power, the line changed by this commit no longer references the default 1 MJ/t calculator.

However, mistaqur found an alternate way to accomplish the same goal (no idle power draw) so this has been removed as of commit 22638dd.

Please sign in to comment.
You can’t perform that action at this time.