With only just the Redstone, the dimensions are 17x17x8
I feel like I can make it thinner xD
I had to go and look up a 1 minute timer system, ended up using this Silent Hopper Timer, but I set it to go off every 2 minutes, making this clock accurate to the 20 minute day night cycle. Or if you're wanting AM/PM set it to 1 minute and it works as expected.
Although you have to use a Command Block to set time to 0 when it hits morning as to sync it with the world.
The "gear" system was the most irritating part of this.
A Piston based solution was out of the question as this needs something vertical, and we all know how Pistons have issues with a Powered Input being aboce it. xD
A Dropper based solution was needed, with the power updates going in the opposite order so the item can be pushed 1 hopper at a time and control the clock arm position.
I love building with this block, I can't wait to release it to see what everyone builds, but I never did any server-side stuff, so I have to do that soon. x'D
#Edit: Did the server stuff, but my custom keybind isn't working so hot, need to do something with network packets? I have no clue, I have to figure out how Shift & Jump do it, but no luck so far.
Haha, I already have the keybinding down, it's just that the GameSettings class is not in the servers, so I have to find a way to send some sort of packet to the server to tell the server the reverse key is being pressed, and that the block should be placed in the opposite orientation.
#Edit
I think handleEntityAction in the class NetServerHandler could be a viable option. I am not sure how it works yet.
You can look through the thread to try to get what you're looking for, basically all the work has been done, or else you can wait until I release the mod and the source code.
UPDATE: Nothing I try seems to really work, and at some point I was getting false positives.
The following blocks have been tested with my custom Redstone bloxk, and are not getting updated correctly by my mod: Trap Door, Fence Gate, Wooden Door, and the Iron Door.
Certain situations: Dispenser and the Dropper
After testing various update codes from Redstone related blocks like Levers, Pistons, Droppers, Doors, and so on... I am fairly certain that there is an update failure between my custom block and the blocks listed above.
Once the custom block is powering one of the blocks listed above, that block then is stuck in an active state, and requires something like a Redstone Dust, Redstone Torch, Button, Lever, Redstone Block, or something else to give it an update.
I have not tested all blocks with this, but simply powering on a piston right next to the block having an update issue doesn't even give it an update. Nor does breaking my block, placing a new one, powered or not.
EXAMPLE: Once the door is activated by my custom block which is below the block that the Iron Door is on, then the block becomes stuck in a powered state. However, adding a Redstone Torch to the block that the Iron Door is place on, allows for the Iron Door to update when the Redstone Torch updates.
As it seems, all the blocks listed to have issues contain code for Metadata. My block doesn't use Metadata because I simply do not currently know how to use Metadata. Could this simply be the issue, or is it something in my update methods listed below?
//Block Placement & Updating//
/**
* Called when the block is placed in the world.
*/
public void onBlockPlacedBy(World par1World, int par2, int par3, int par4, EntityLivingBase par5EntityLivingBase, ItemStack par6ItemStack)
{
int var6 = determineOrientation(par1World, par2, par3, par4, par5EntityLivingBase);
int var7 = par1World.getBlockMetadata(par2, par3, par4);
int var8 = getOrientation(var7);
boolean var9 = this.isGettingInput(par1World, par2, par3, par4, var7);
if (!var9)
{
par1World.setBlock(par2, par3, par4, Block.redstoneDirectionalIdle.blockID, var6, 2);
updateNeighbors(par1World, par2, par3, par4);
}
if (var9)
{
par1World.setBlock(par2, par3, par4, Block.redstoneDirectionalActive.blockID, var6, 2);
updateNeighbors(par1World, par2, par3, par4);
}
}
/**
* Ticks the block if it's been scheduled
*/
public void updateTick(World par1World, int par2, int par3, int par4, Random par5Random)
{
int var6 = par1World.getBlockMetadata(par2, par3, par4);
int var7 = getOrientation(var6);
boolean var8 = this.isGettingInput(par1World, par2, par3, par4, var7);
if (!var8)
{
par1World.setBlock(par2, par3, par4, Block.redstoneDirectionalIdle.blockID, var7, 2);
updateNeighbors(par1World, par2, par3, par4);
}
if (var8)
{
par1World.setBlock(par2, par3, par4, Block.redstoneDirectionalActive.blockID, var7, 2);
updateNeighbors(par1World, par2, par3, par4);
}
}
/**
* Lets the block know when one of its neighbor changes. Doesn't know which neighbor changed (coordinates passed are
* their own) Args: x, y, z, neighbor blockID
*/
public void onNeighborBlockChange(World par1World, int par2, int par3, int par4, int par5)
{
int var5 = par1World.getBlockMetadata(par2, par3, par4);
int var6 = getOrientation(var5);
boolean var7 = this.isGettingInput(par1World, par2, par3, par4, var6);
if (var7 || !var7)
{
par1World.scheduleBlockUpdate(par2, par3, par4, this.blockID, 1);
}
}
/**
* This will update the determined sides
*/
public void updateNeighbors(World par1World, int par2, int par3, int par4)
{
par1World.notifyBlocksOfNeighborChange(par2, par3, par4, this.blockID);
par1World.notifyBlocksOfNeighborChange(par2 - 1, par3, par4, this.blockID);
par1World.notifyBlocksOfNeighborChange(par2 + 1, par3, par4, this.blockID);
par1World.notifyBlocksOfNeighborChange(par2, par3, par4 - 1, this.blockID);
par1World.notifyBlocksOfNeighborChange(par2, par3, par4 + 1, this.blockID);
par1World.notifyBlocksOfNeighborChange(par2, par3 - 1, par4, this.blockID);
par1World.notifyBlocksOfNeighborChange(par2, par3 + 1, par4, this.blockID);
}
//End Block Placement & Updating//
Feel free to shorten my code, credit will be given so long as I use your edit.
I don't know (I was going to guess that you've got something static in your class though I doubt it), but is there a reason you - and so many others, actually - use machine-generated variable names? It takes us twice as long to understand the code, and it surely doesn't make your own work any easier.
Well for me this is basically just how I started, and it seems better for me to have the variables named like that to make it all look more organize and static I guess.
It seems like when I read other people's code, especially in the larger blocks of code, all the customized names just make it feel like sentence or paragraph, and it's a lot easier for me to lose track of each variable due to how different a lot of the variable names are.
I do use custom names for whatever these codes are. (haven't had much sleep so i don't exactly remember right off the bat)
/** Tells whether the repeater is powered or not */
protected boolean isPowered;
Since it's going be used in various situations I can keep track of it through several blocks of code as it's name is going to stand out from all the statically named var# or par#.
And when I am looking at code to see what variable or parameter does something, I'm just looking for a difference in small numbers, instead of variable names where each name is different.
I dunno how "par3" is easier to understand than "posX". The feeling-like-a-sentence is sort of the point, it's a language and it's easier to comprehend - we're reading, not machines parsing data It's mainly confusing because par3 in one method is often completely different to par3 in the next method, we have to actually read code - sometimes more than once - instead of scanning over it, and it's easier to miss something. par1World at least says "world", but anyway... I digress. Suit yourself, if using non-descriptive variable names is easier for you then stick to whatever works
Back to the issue, really not sure - but it sounds like your blocks are not acting properly when clustered, i.e. neighbor change/awareness logic. Do you have these issues when you have only one of your blocks, not adjacent to another?
Coding is like drawing or painting. There is no one way to do it, the only thing that really maters is that the way you choose to do it works for you, so to each their own.
I set up a new world, just 1 of these and a door, everything behaved the same.
Instead of using something like isGettingInput, they used something called onPoweredBlockChange
So then if I put it back in, then the original issue of this post is going to happen again, LOL.
EDIT:
It seems in BlockRedstoneWire, the method isPowerProvider is what I need to insert an override for my block class so that Redstone simply doesn't try to connect to my block. I've been trying some things mentioned before, but no luck.
/**
* Returns true if redstone wire can connect to the specified block. Params: World, X, Y, Z, side (not a normal
* notch-side, this can be 0, 1, 2, 3 or -1)
*/
public static boolean isPowerProviderOrWire(IBlockAccess par0IBlockAccess, int par1, int par2, int par3, int par4)
{
int var5 = par0IBlockAccess.getBlockId(par1, par2, par3);
if (var5 == Block.redstoneWire.blockID)
{
return true;
}
else if (var5 == 0)
{
return false;
}
else if (!Block.redstoneRepeaterIdle.func_94487_f(var5))
{
return Block.blocksList[var5].canProvidePower() && par4 != -1;
}
else
{
int var6 = par0IBlockAccess.getBlockMetadata(par1, par2, par3);
return par4 == (var6 & 3) || par4 == Direction.rotateOpposite[var6 & 3];
}
}
EDIT2: Nope, never mind I got it. Seems like my code being next to last was also some sort of an issue... ._.
Works just right. Now for more, and more, and more testing... Wonder if anymore bugs will come up. xD
With the shell the dimensions are 21x21x10
With only just the Redstone, the dimensions are 17x17x8
I feel like I can make it thinner xD
I had to go and look up a 1 minute timer system, ended up using this Silent Hopper Timer, but I set it to go off every 2 minutes, making this clock accurate to the 20 minute day night cycle. Or if you're wanting AM/PM set it to 1 minute and it works as expected.
Although you have to use a Command Block to set time to 0 when it hits morning as to sync it with the world.
The "gear" system was the most irritating part of this.
A Piston based solution was out of the question as this needs something vertical, and we all know how Pistons have issues with a Powered Input being aboce it. xD
A Dropper based solution was needed, with the power updates going in the opposite order so the item can be pushed 1 hopper at a time and control the clock arm position.
I love building with this block, I can't wait to release it to see what everyone builds, but I never did any server-side stuff, so I have to do that soon. x'D
#Edit: Did the server stuff, but my custom keybind isn't working so hot, need to do something with network packets? I have no clue, I have to figure out how Shift & Jump do it, but no luck so far.
#Edit
I think handleEntityAction in the class NetServerHandler could be a viable option. I am not sure how it works yet.
I'm messing with 3D in Photoshop, so I made a new one which will be my new avatar after this comment.
The following blocks suffer from update issues with my block: Dispenser, Dropper, Trapdoor, Fence Gate, Wood Door, and Iron Door.
The following blocks have been tested with my custom Redstone bloxk, and are not getting updated correctly by my mod: Trap Door, Fence Gate, Wooden Door, and the Iron Door.
Certain situations: Dispenser and the Dropper
After testing various update codes from Redstone related blocks like Levers, Pistons, Droppers, Doors, and so on... I am fairly certain that there is an update failure between my custom block and the blocks listed above.
Once the custom block is powering one of the blocks listed above, that block then is stuck in an active state, and requires something like a Redstone Dust, Redstone Torch, Button, Lever, Redstone Block, or something else to give it an update.
I have not tested all blocks with this, but simply powering on a piston right next to the block having an update issue doesn't even give it an update. Nor does breaking my block, placing a new one, powered or not.
EXAMPLE: Once the door is activated by my custom block which is below the block that the Iron Door is on, then the block becomes stuck in a powered state. However, adding a Redstone Torch to the block that the Iron Door is place on, allows for the Iron Door to update when the Redstone Torch updates.
As it seems, all the blocks listed to have issues contain code for Metadata. My block doesn't use Metadata because I simply do not currently know how to use Metadata. Could this simply be the issue, or is it something in my update methods listed below?
Feel free to shorten my code, credit will be given so long as I use your edit.
It seems like when I read other people's code, especially in the larger blocks of code, all the customized names just make it feel like sentence or paragraph, and it's a lot easier for me to lose track of each variable due to how different a lot of the variable names are.
I do use custom names for whatever these codes are. (haven't had much sleep so i don't exactly remember right off the bat)
/** Tells whether the repeater is powered or not */
protected boolean isPowered;
Since it's going be used in various situations I can keep track of it through several blocks of code as it's name is going to stand out from all the statically named var# or par#.
And when I am looking at code to see what variable or parameter does something, I'm just looking for a difference in small numbers, instead of variable names where each name is different.
Back to the issue, really not sure - but it sounds like your blocks are not acting properly when clustered, i.e. neighbor change/awareness logic. Do you have these issues when you have only one of your blocks, not adjacent to another?
I set up a new world, just 1 of these and a door, everything behaved the same.
Remember previously how canProvidePower was causing me problems? Turns out not having it, or setting it as false also causes problems. XD
Without canProvidePower it seems like the following blocks have update issues: Trap Door, Fence Gate, Wooden Door, and the Iron Door.
Certain situations: Dispenser and the Dropper
In the BlockDoor class I found this in the onNeighborBlockChange method:
if ((var8 || par5 > 0 && Block.blocksList[par5].canProvidePower()) && par5 != this.blockID)
{
this.onPoweredBlockChange(par1World, par2, par3, par4, var8);
}
Instead of using something like isGettingInput, they used something called onPoweredBlockChange
So then if I put it back in, then the original issue of this post is going to happen again, LOL.
EDIT:
It seems in BlockRedstoneWire, the method isPowerProvider is what I need to insert an override for my block class so that Redstone simply doesn't try to connect to my block. I've been trying some things mentioned before, but no luck.
EDIT2: Nope, never mind I got it. Seems like my code being next to last was also some sort of an issue... ._.
Works just right. Now for more, and more, and more testing... Wonder if anymore bugs will come up. xD