[1.7.10] Making redstone output equal redstone input on opposite side

[IceMetalPunk]

As usual, I started out thinking this wouldn't be difficult, and now I'm stuck >_< All I want is for two adjacent sides of my block (which two is determined by block metadata set on placement, like a furnace direction) to output the same redstone signal coming in on the opposite sides. Kind of like if you took two comparators oriented 90-degreed from each other and combined them into one block. Instead...well, the block doesn't give off any redstone signal at all, regardless of what's coming into it from any side.

 

Here's the code; let's play "spot the noob mistake" >_<

 

package com.IceMetalPunk.redplus.blocks;

import net.minecraft.block.Block;
import net.minecraft.block.material.Material;
import net.minecraft.entity.EntityLivingBase;
import net.minecraft.item.ItemStack;
import net.minecraft.util.Direction;
import net.minecraft.util.Facing;
import net.minecraft.util.MathHelper;
import net.minecraft.world.IBlockAccess;
import net.minecraft.world.World;

public class BlockRedstoneBridge extends Block {

protected BlockRedstoneBridge() {
	super(Material.circuits);
}

@Override
public boolean canProvidePower() {
	return true;
}

@Override
public int isProvidingWeakPower(IBlockAccess blockAccess, int x, int y, int z, int side) {
	World world = (World) blockAccess;
	int out1 = (world.getBlockMetadata(x, y, z) & 3);
	int out2 = Direction.rotateLeft[out1];

	int in1 = Direction.rotateOpposite[out1];
	int in2 = Direction.rotateOpposite[out2];

	if (side == out1) {
		return world.getIndirectPowerLevelTo(x + Facing.offsetsXForSide[in1], y, z + Facing.offsetsZForSide[in1], out1);
	}
	else if (side == out2) {
		return world.getIndirectPowerLevelTo(x + Facing.offsetsXForSide[in2], y, z + Facing.offsetsZForSide[in2], out2);
	}
	return 0;

}

@Override
public void onBlockPlacedBy(World p_149689_1_, int p_149689_2_, int p_149689_3_, int p_149689_4_,
		EntityLivingBase p_149689_5_, ItemStack p_149689_6_) {
	int l = MathHelper.floor_double((double) (p_149689_5_.rotationYaw * 4.0F / 360.0F) + 0.5D) & 3;

	if (l == 0) {
		p_149689_1_.setBlockMetadataWithNotify(p_149689_2_, p_149689_3_, p_149689_4_, 2, 2);
	}

	if (l == 1) {
		p_149689_1_.setBlockMetadataWithNotify(p_149689_2_, p_149689_3_, p_149689_4_, 5, 2);
	}

	if (l == 2) {
		p_149689_1_.setBlockMetadataWithNotify(p_149689_2_, p_149689_3_, p_149689_4_, 3, 2);
	}

	if (l == 3) {
		p_149689_1_.setBlockMetadataWithNotify(p_149689_2_, p_149689_3_, p_149689_4_, 4, 2);
	}
}

}

 

(And yes, I just copied the onBlockPlacedBy code straight from BlockFurnace, hence the obfuscated parameter names.)

[jeffryfisher]

1) Why is your only constructor declared as "protected"?

 

2) Can you be sure that you are testing an output side and not an input? Try applying a redstone signal (or assigning your ins and outs) in the opposite direction to see if power goes through.

 

3) Is your method being even being called when expected? Zero is such a trivial result that it could be coming from elsewhere entirely. Plant a print or break in there to convince yourself it is involved.

[IceMetalPunk]

1) Why is your only constructor declared as "protected"?

 

2) Can you be sure that you are testing an output side and not an input? Try applying a redstone signal (or assigning your ins and outs) in the opposite direction to see if power goes through.

 

3) Is your method being even being called when expected? Zero is such a trivial result that it could be coming from elsewhere entirely. Plant a print or break in there to convince yourself it is involved.

1) >_< D'oh, chalk that up to Eclipse auto-complete and my lack of proofreading. Still, I got no access violation errors, and the block added fine, so that's not the problem.

 

2) I can be sure, because I've tested all 4 horizontal sides

 

3) Yup. Whenever there's a block update, like a redstone signal change, to my block, it outputs debug messages just fine saying it's checking side out1 and side out2 for weak power. But still, no output signal is sent. One thing to note is that during testing, I had to change the final parameters of World#getIndirectPowerLevelTo from out1 and out2 to in1 and in2; leaving it as out# ended up causing an infinite loop until a stack overflow crashed the game, with getIndirectPowerLevelTo calling isProvidingWeakPower and vice-versa until crash. Changing it to in1 and in2 fixed that crash, but it still doesn't supply any output signal from any side, despite properly getting into the side conditionals on block update.

[jeffryfisher]

I had to change the final parameters of World#getIndirectPowerLevelTo from out1 and out2 to in1 and in2

I suspect that your problem here is not quite solved the right way. How does the vanilla diode avoid a circular call?

 

Minecraft has some non-intuitive labeling in places. However, my redstone modding was done in 1.8, so my experience doesn't align exactly. Go back to the diode (repeater) and imitate its naming/passing scheme as applicable, changing only the strengths to suit your goal.

[Draco18s]

Don't rotate opposite.

The getPower methods checks the block west and sends "west" as the side parameter. Your code thinks that "east" is where its input is when passed "west," so it asks the block east of it if it is powered, but that block asked your block, and so on.

 

That is: the side parameter passed is not the side of YOUR block the request is coming from, but the side the REQUESTOR is checking.

[IceMetalPunk]

I had to change the final parameters of World#getIndirectPowerLevelTo from out1 and out2 to in1 and in2

I suspect that your problem here is not quite solved the right way. How does the vanilla diode avoid a circular call?

 

Minecraft has some non-intuitive labeling in places. However, my redstone modding was done in 1.8, so my experience doesn't align exactly. Go back to the diode (repeater) and imitate its naming/passing scheme as applicable, changing only the strengths to suit your goal.

 

I've tried looking into BlockRedstoneDiode/BlockRedstoneRepeater, and it's a mess of obfuscated callbacks. The best I can tell, it's just using the isRepeaterPowered member to determine whether it's on or off, but I can't find anywhere that member is actually set to true or false. I'll keep looking, but for now I don't know where the check for power is coming from in the default classes.

 

*EDIT* Scratch that. Two seconds after posting, I found it. The default diodes actually use two different block IDs each, one for powered and one for unpowered. That works fine if there's only one input and one output, but...here I have two of each. If I were to use the same method, I'd need 4 different blocks to handle every combination of on and off between them. There *must* be a more efficient way to do this, right?

 

Don't rotate opposite.

The getPower methods checks the block west and sends "west" as the side parameter. Your code thinks that "east" is where its input is when passed "west," so it asks the block east of it if it is powered, but that block asked your block, and so on.

 

That is: the side parameter passed is not the side of YOUR block the request is coming from, but the side the REQUESTOR is checking.

As mentioned, I fixed that problem by changing the final parameters to getIndirectPowerLevelTo() from out1,2 to in1,2. That prevented the infinite callbacks (since in1,2 are the opposite sides of out1,2 and out1,2 caused the infinite loops). It's still not outputting anything, though.

[Draco18s]

As mentioned, I fixed that problem by changing the final parameters to getIndirectPowerLevelTo() from out1,2 to in1,2. That prevented the infinite callbacks (since in1,2 are the opposite sides of out1,2 and out1,2 caused the infinite loops). It's still not outputting anything, though.

 

Mm. Wasn't sure if that's what that was or not.  I was just falling asleep and remembered that weird little fact about how getPower works.

[IceMetalPunk]

Yeah... I'm still having trouble. I suppose if I don't get it working by 2016 (heh, Friday, that is), I can just go the excessive route and make 4 different blocks, one for each state, and replace the blocks in the world according to inputs. I'm just not yet convinced there isn't a more elegant solution to this...

[Draco18s]

I'm sure I could code it, but you'd have to wait a few days. I'm kind of tied up.

[jeffryfisher]

How does redstone dust behave when it has wire/devices on all four sides? Could you imitate that case, but without the power-drop?

[Draco18s]

How does redstone dust behave when it has wire/devices on all four sides? Could you imitate that case, but without the power-drop?

 

Redstone dust is super complicated to follow.  It was hellish trying to disect the code enough to make redstone fences.

 

Alright, starting to look at this block's problems.

 

#1! The metadata used is 2,3,4,5 consistent with 0 and 1 being down and up. But! The isProvidingPower method uses bitwise &3 so the values don't arrayoutofbounds on Direction[], this is why you use ForgeDirection!

 

#2! A bridge has one primary direction specified by metadata (that's fine) however, the crosswise direction can go either left to right or right to left.  There's room in the metadata to handle this, but this means the blocks needs a way to know whether it is right handed or left handed (mirror images, not rotations).

 

#3! Something is going on with figuring out that a neighboring block is providing power.  I even duplicated all of the functionality in the repeater and still don't get the output I want (at best, it takes input directly from a redstone wire--and only wire--which I suppose would be fine).  Correction, it takes direct power only, none of that "through a solid block" stuff (e.g. comparators and repeaters work too).

 

That said, I have a working block!

 

 

public class BlockRedstoneBridge extends Block {

public BlockRedstoneBridge() {
	super(Material.circuits);
	this.setCreativeTab(CreativeTabs.tabRedstone);
}

@Override
public boolean canProvidePower() {
	return true;
}

@Override
public int isProvidingWeakPower(IBlockAccess access, int x, int y, int z, int side) {
	World world = (World)access;
	int out1 = (world.getBlockMetadata(x, y, z));

	int out2 = ForgeDirection.VALID_DIRECTIONS[out1].getRotation(ForgeDirection.UP).ordinal(); 

	if (side == out1) {
		System.out.println("Power: " + getInputStrength(world, x, y, z, out1));
		return getInputStrength(world, x, y, z, out1)-1;
	}
	if (side == out2) {
		System.out.println("Power: " + getInputStrength(world, x, y, z, out2));
		return getInputStrength(world, x, y, z, out2)-1;
	}
	return 0;
}

@Override
public void onBlockPlacedBy(World p_149689_1_, int p_149689_2_, int p_149689_3_, int p_149689_4_,
		EntityLivingBase p_149689_5_, ItemStack p_149689_6_) {
	int l = MathHelper.floor_double((double) (p_149689_5_.rotationYaw * 4.0F / 360.0F) + 0.5D) & 3;

	if (l == 0) {
		p_149689_1_.setBlockMetadataWithNotify(p_149689_2_, p_149689_3_, p_149689_4_, 2, 2);
	}

	if (l == 1) {
		p_149689_1_.setBlockMetadataWithNotify(p_149689_2_, p_149689_3_, p_149689_4_, 5, 2);
	}

	if (l == 2) {
		p_149689_1_.setBlockMetadataWithNotify(p_149689_2_, p_149689_3_, p_149689_4_, 3, 2);
	}

	if (l == 3) {
		p_149689_1_.setBlockMetadataWithNotify(p_149689_2_, p_149689_3_, p_149689_4_, 4, 2);
	}
}

    protected int getInputStrength(World world, int x, int y, int z, int side)
    {
    	ForgeDirection i1 = ForgeDirection.VALID_DIRECTIONS[side];
        int j1 = x + i1.offsetX;
        int k1 = z + i1.offsetZ;
        int l1 = world.getIndirectPowerLevelTo(j1, y, k1, i1.ordinal());
        return l1 >= 15 ? l1 : Math.max(l1, world.getBlock(j1, y, k1) == Blocks.redstone_wire ? world.getBlockMetadata(j1, y, k1) : 0);
    }
}

 

[IceMetalPunk]

O_O So, I don't *quite* understand ForgeDirection#getRotation() works, as it sounds like this code would rotate the direction upwards, but that's not at all what's happening...but it works! Well...mostly... It seems that if the input is coming from a comparator, and that comparator is broken, it doesn't give the output line a block update, so it stays on. It's very strange, because that doesn't happen with wire or repeaters, and it doesn't happen when the comparator's signal changes; it only refuses to update when the comparator is broken. I don't see anything special in the class which would change the way it propagates block updates, so..any idea what would cause this and/or how to fix it? O_O

 

*EDIT* Never mind about how to fix it; I've fixed it myself by forcing a block update with this:

 

	@Override
public void onNeighborBlockChange(World world, int x, int y, int z, Block block) {
	world.notifyBlocksOfNeighborChange(x, y, z, this);
}

 

I was a little worried it might cause an infinite loop of notifications and a stack overflow, but it seems to work just fine. I'm still curious as to why every other update propagates just fine, but comparator destruction doesn't Anyway, thanks again for your help; you'll be in the mod credits when it's released. Which should be soon, as all that's left now for it is to texture this one block

[Draco18s]

Because the input to the getRotation method is the rotation axis, that is, the bit that doesn't move.

[IceMetalPunk]

Ohhhh, so it's basically the ForgeDirection version of the right-hand rule, then? Good to know that little skill from uni will come in handy after all

 

So now it turns out that texturing this block is...not going quite as smoothly as I expected. For the sake of ease of rendering, I changed the class to extend BlockRedstoneDiode. All is well, and it renders perfectly fine...except there doesn't seem to be a way to consistently texture this thing. I have two crossing arrows pointing in the direction of the output, and that's the top texture. But it seems that if I get the arrows pointing in the right direction for one placement, they're pointing the wrong direction for certain other placements. And then of course, if I rotate the texture to fix it for that placement, it ends up pointing the wrong way for the original metadata. I feel like the solution has something to do with changing which metadata checks which sides for input and output, but since that's the part that's been confusing me all along, I don't quite know what calculations need to be applied.

 

Here's the new class code (basically the same, just extending BlockRedstoneDiode and implementing the required methods for that):

 

package com.IceMetalPunk.redplus.blocks;

import net.minecraft.block.Block;
import net.minecraft.block.BlockRedstoneDiode;
import net.minecraft.entity.EntityLivingBase;
import net.minecraft.init.Blocks;
import net.minecraft.item.ItemStack;
import net.minecraft.util.MathHelper;
import net.minecraft.world.IBlockAccess;
import net.minecraft.world.World;
import net.minecraftforge.common.util.ForgeDirection;

public class BlockRedstoneBridge extends BlockRedstoneDiode {

public BlockRedstoneBridge() {
	super(false);
}

@Override
public void onNeighborBlockChange(World world, int x, int y, int z, Block block) {
	world.notifyBlocksOfNeighborChange(x, y, z, this);
}

@Override
public boolean canProvidePower() {
	return true;
}

@Override
public int isProvidingWeakPower(IBlockAccess access, int x, int y, int z, int side) {
	World world = (World) access;
	int out1 = (world.getBlockMetadata(x, y, z));

	int out2 = ForgeDirection.VALID_DIRECTIONS[out1].getRotation(ForgeDirection.UP).ordinal();

	if (side == out1) {
		return getInputStrength(world, x, y, z, out1) - 1;
	}
	if (side == out2) {
		return getInputStrength(world, x, y, z, out2) - 1;
	}
	return 0;
}

@Override
public void onBlockPlacedBy(World p_149689_1_, int p_149689_2_, int p_149689_3_, int p_149689_4_,
		EntityLivingBase p_149689_5_, ItemStack p_149689_6_) {
	int l = MathHelper.floor_double((double) (p_149689_5_.rotationYaw * 4.0F / 360.0F) + 0.5D) & 3;

	if (l == 0) {
		p_149689_1_.setBlockMetadataWithNotify(p_149689_2_, p_149689_3_, p_149689_4_, 2, 2);
	}

	if (l == 1) {
		p_149689_1_.setBlockMetadataWithNotify(p_149689_2_, p_149689_3_, p_149689_4_, 5, 2);
	}

	if (l == 2) {
		p_149689_1_.setBlockMetadataWithNotify(p_149689_2_, p_149689_3_, p_149689_4_, 3, 2);
	}

	if (l == 3) {
		p_149689_1_.setBlockMetadataWithNotify(p_149689_2_, p_149689_3_, p_149689_4_, 4, 2);
	}
}

@Override
public int getLightOpacity() {
	return 0;
}

protected int getInputStrength(World world, int x, int y, int z, int side) {
	ForgeDirection i1 = ForgeDirection.VALID_DIRECTIONS[side];
	int j1 = x + i1.offsetX;
	int k1 = z + i1.offsetZ;

	int l1 = world.getIndirectPowerLevelTo(j1, y, k1, i1.ordinal());
	return l1 >= 15	? l1
					: Math.max(l1, world.getBlock(j1, y, k1) == Blocks.redstone_wire	? world.getBlockMetadata(j1, y, k1)
																						: 0);
}

@Override
protected int func_149901_b(int p_149901_1_) {
	// TODO Auto-generated method stub
	return 0;
}

@Override
protected BlockRedstoneDiode getBlockPowered() {
	// TODO Auto-generated method stub
	return this;
}

@Override
protected BlockRedstoneDiode getBlockUnpowered() {
	// TODO Auto-generated method stub
	return this;
}
}

 

And this is the texture I'm currently using, which works for some orientations of the block, but is pointing in the wrong direction for others:

 

https://dl.dropboxusercontent.com/u/11662651/Graphics/Minecraft/redstone_bridge.png[/img]

 

Can this be fixed with a modification of the texture alone, or is there some metadata calculation that needs to be done for case-by-case handling? And if that's so...does this mean I'll need to implement a custom block renderer instead of using the default BlockRedstoneDiode renderer?

 

*EDIT* A little more testing and I think I can be more specific with the problem. Every direction works fine except one. If I place it down while facing towards negative X, both arrows are backwards from the way the inputs and outputs behave. Every other placement direction has them pointing properly.

[Draco18s]

I do not know.

You may have to write your own ISimpleBlockRenderingHandler.  Its pretty straight forward.

[jeffryfisher]

int l = MathHelper.floor_double((double) (p_149689_5_.rotationYaw * 4.0F / 360.0F) + 0.5D) & 3;

 

Put some test values (esp edge cases) through this formula. Does it always yield the L-value you want?