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.

Show comment
Hide comment
@CovertJaguar

CovertJaguar 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.

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.

Show comment
Hide comment
@MyNameIsKodos

MyNameIsKodos Oct 19, 2013

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

MyNameIsKodos replied Oct 19, 2013

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

@xaviorm

This comment has been minimized.

Show comment
Hide comment
@xaviorm

xaviorm 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..

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.

Show comment
Hide comment
@Viper-7

Viper-7 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.

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.

Show comment
Hide comment
@CovertJaguar

CovertJaguar 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.

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.

Show comment
Hide comment
@skyboy

skyboy Oct 20, 2013

Owner

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.

Owner

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.