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.

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?

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?

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.