As it stands now, a logical gate on its own may have a maximum of three inputs. I suggest that if more than one ore of the same kind are put next to one another, either horizontally or vertically, they should all merge into one and the same gate.

This way one could have an arbitrarily large amount of inputs in a elegant looking row or column of ores, as opposed to the awkward amalgamations of gates and wires that are required to create such a thing now.

Requires: Implement Modifiers

Grandfather Clocks should change their behavour when used with modifiers as the following:
1 - The clock will send its signals a bit sooner than usually, so that lights will be already turned on when the sun is about to go down.
2 - The clock will only send signals when a bloodmoon night starts / ends.

If a Switch / Lever is turned by signal it should forward that signal to its own non-input Ports. Though, the default behaviour should be that a signal is only being forward if the component got actually switched by the signal. (A Switch in off-state should not forward an off signal it just received)

Though, Switches and Levers with one modifier should forward any signal - careless of their state.

Improve the "/ac hit|toggle|switch" command with the following features:
"-p" will enable persistent mode for this command, it will stay persistent until "a /ac hit|toggle|switch" command is entered again.
"-s 0|1" will not toggle the respective Component to its opposite state, but clearly set its 0 or 1 state instead.
The command should be able to be used with Logical Gates and their Input Ports. If the command is used directly on a Logical Gate, it will switch ALL of its Input Ports to the respective state (and thus initialize it). If used on an Input Port, it will only switch that Input Port to the respective state.

Usually the signal sent by Block Activators looses its "magic" if it happens to cross another Port Defining Component, Crossover Brdiges should make an exception here.

A simple thing that I've been missing with normal terraria wiring is a dart trap that can fire upwards and downwards. Would it be possible to configure if the darts are fired along a vertical or horizontal line? Since there are 2 settings of a dart trap, facing right but being set to vertical could fire the arrow upwards and downwards for a dart trap facing left.

As all 4 block types of the blocks that are affected by gravity does not work with the block activator gate i think that they it should either be a modifier to the activator to make them work or have their separate gate that works on them.

Being able to spawn large chunks of sand block types instantaneously is a huge advantage in trap and interactive environments in both specific survival and adventure maps.

Having a 2D game, hiding falling blocks is a huge hassle and right now it involves either stacking torches below sand or having it placed on cobweb which is removed by a dart trap. Sand cannot fall through inactive stone which is a huge disadvantage to the vanilla circuit as a whole.
But now with the ability to inactivate almost every block type, it's easy to set up the traps. However, there's a huge flaw that still remains, the traps are easily detectable and are almost impossible to hide without massive wiring mechanics.

So my suggestion stands quite clear, having the ability to create sand falls and Insane traps that are completely undetectable without a wiring tool would be a great addition in my opinion.

Requires: Complex Components

Add the following Tasks:
Label.SetIf(Label, Signal = On)
Signal.Send(Signal = On)
Signal.SendIf(Label, Signal = On)
Circuit.StartNew(Signal = On)
Circuit.Cancel()
Circuit.CancelIf(Label)

Requires: Full Integration.

Support Explosives configuration with 5 different configuration profiles (default + 4 modifiers).

Config options:
ExplosionWidth (in tiles)
ExplosionHeight (in tiles)
ExplosionShape (circle, rectangle)
BlockDestroyMethod (destroy all blocks, destroy non bomb-proof blocks, destroy no blocks)
DropDestroyedBlocks (1/0)
DropDestroyedWires (1/0)
DestroyWalls (1/0)
DestroyWires (1/0)
RemoveLiquid (1/0)
PlayerDamage
NpcDamage
MobDamage
WirePermission
TriggerPermission

If the sensor is in its "off" state, sends 1 and switches to its "on" state if an adjacent tile contains any liquid over more than one seconds.
If the sensor is in its "on" state, sends 0 if all adjacent tiles around it contain no more liquid.

Suggested Modifiers:
1 - Works for water only.
2 - Works for lava only.

No idea what block type / spirte to take for this component though.

As mentioned in the server tutorial, every input needs to have a signal sent to it to work.
This is rather time demanding for massive wiring mechanics that use hundreds of gates.

My suggestion is creating a "start up" scan that scans the whole map for gates and by that activating them.

Another way to do this might be to add a 3rd signal type that does not follow wires and does not execute any gate mechanics. So a signal that works over an area and identifies every input. So instead of sending a 0 or a 1, you send an X signal or perhaps a 2.

Requires: Complex Components

Add the following Tasks:
Sign.GetText()
Sign.ListContainsItem(String, Label = None)
Sign.ListAppendPlayerName(AppendIfExist = No)
Sign.ListAppendItem(String, AppendIfExist = No)
Sign.ListAppendSignText(AppendIfExist = No)
Sign.ListRemovePlayerName()
Sign.ListRemoveItem(String)
Sign.ListRemoveSignText()
Sign.ContainsText(String, Exact = No, Label = None)
Sign.AppendText(String)
Sign.AppendSignText()
Sign.Clear()

Timer circuits should be processed by a new thread, instead by terraria's update thread.

A command like
/ac hit|toggle|switch

should be implemented to just signal the next component being hit so that a component can easily be switched to a different state without the need of an extra circuit.
Check region and tile permissions of the player though.

Modifiers, another special block tile should be added. Modifiers can be placed at the diagonal edges of components, thus four modifiers are possible for a component.

Suggested Tile: Cobalt Ore

Add some more permissions and track the triggering player for Timers and the placing player for Grandfather Clocks.

Permissions:
Dart Traps: WirePermission, TriggerPermission
Statues: TriggerPermission
Boulders: WirePermission

Also add configuration options to set whether any Permissions for the components above should be checked at all - so the server owner wont have to add a ton of permissions to all player groups.

Probably the metadata check for active timers failed or is missing in this release.

System.ArgumentException: The tile at location {X=2791,Y=599} can not be measured because its not active
at Terraria.Plugins.CoderCow.Terraria.MeasureSprite(Point anyTileLocation)
at Terraria.Plugins.CoderCow.AdvancedCircuits.CircuitProcessor..ctor(Configuration config, WorldMetadata worldMetadata)
at Terraria.Plugins.CoderCow.AdvancedCircuits.AdvancedCircuitsPlugin.Game_PostInitialize()
at System.Action.Invoke()
at Hooks.GameHooks.OnInitialize(Boolean pre)
at Terraria.Main.DedServ()
at Terraria.ProgramServer.Main(String[] args)

Some wire constructs (depending on positioning and alignment) are not processed due to a bug of the branch processor.

If a sign is powered, the text written on it should be displayed to the player triggering the circuit.
Maybe add a special pattern to set up the color for each line.

Note: The sign should not display a text if the circuit was executed by a Timer or Grandfather Clock.

The special port behaviour of timers has not proven to be useful at all, timers should also take input signals on input ports only, not on any port.

Requires: #11

Two modifiers should be added to pressure plates:
1 - Triggers for players only.
2 - Triggers for mobs only.

Not completely sure about the design and name yet, but it will probably be a sign with a special kind of block all around it.
The text on the sign then defines, using a special pattern, what Port site of the Complex Component should perform what Task and the parameters those Tasks should be executed with. So, a Complex Component can have one Task assigned to each Port site - resulting in 4 Tasks at most.

This is how a simple sign definition for a Complex Component could look like:

[ComplexComponent(Bottom)]

[Left: ChestTakeItems(1, Wood)]

[Right: ChestPutItems(1, Wood)]

As defined, the bottom Port of the Complex Component (CC) is the signal Port. The CC will start processing when the bottom Port receives a 1 signal.
So the first task is to take an item from a chest, so the CC will send a 1 signal out of its left Port and the first chest that receives a 1 signal through this circuit will be taken as source chest. If the chest or the given item was not found in the chest, the CC will stop processing any further tasks, if it was found though, it will now send a 1 signal out of its right Port and the first chest that receives the 1 signal through this wire will be taken as the destination chest. If the CC found this chest too and its not full, everything will be set for the actual execution, so finally the CC will actually take the item from the source chest and put it into the destination chest.
The CC is smart enough to know that if the user defined that an item should be taken, it also has to be put somewhere after that, it will not just remove the item. So if there is a "ChestTakeItems" task but no "ChestPutItems" or something equivalent like "DropItem" the CC will simply not execute and throw an error to the one who executed the circuit. But since we have both tasks it will be alright.
Of course, the CC is also smart enough to not just duplicate the item if there is another "ChestPutItems" Task for the same or a different chest, the second "ChestPutItems" would just be invalid as there would be no item left to put.

Any other Port site beside the signal Port will never have any effect if they receive a signal. Though, even as the bottom Port is the signal port, it might still have a Task assigned to it too.
Each Task should come with a configurable permission, so if a user writes down a Task on a Complex Component sign but doesn't have the permission for it, the change will not be applied.

The configuration option MaxChangeableBlocks for Block Activators has no effect.

Make Doors signaled by a circuit not removing blocking blocks.

How about a few tiles that transmit the signals they receive to receiver tiles? They could work as pairs, perhaps connected via command, so that they don't get mixed up. Their pair could probably be saved in the world metadata..

The sender and receiver tiles should be port defining components, the sender tile could have specific tiles on its input ports, such as the tiles the logic gates use (or any tiles at all). These input ports would be 'channels' for the wireless transmission. The receiver tile would allocate the signals it receives from each channel and output signals to the tiles that match the channels in its own ports.

Example, because I suck at describing things:
Key: W = Wireless Sender, R = Wireless Receiver, (1-4) = Any Tile that are different from all others.

  2
1 W 4
  3

  2
1 R 4
  3

So let's say I send a 1 signal into the 1 port in the sender. The receiver would receive the signal and output a 1 on its own 1 port.

So on, if I sent a 0 signal on the sender's 4 port, the receiver would get that and output 0 on its own 4 port.

If the sender has a channel (input tile) that the receiver does not have, then that port will be inactive, or just send 0 always.

Edit: Wrestled with the formatting a bit, but managed to get the examples to be readable.

Requires: Implement Modifiers

AND, OR and XOR Gates should change their behaviour when being used with one modifier:
The Gate requires to be fully re-initialized with each circuit execution. This will cause a Gate not to preserve its state and it will only send a signal when all of the Input Ports have been signaled by the same circuit.

Read each configuration entry by hand, and warn about invalid or missing values in the console. Also warn if the config file doesn't exit at all.

Requires: Full Integration

Implement several new configuration options for Pumps:
-The amount of transferable Water
-The amount of transferable Lava
-A cooldown

Also, a "loss value" causing to actually remove a configurable amount of liquid per transfer can be considered. First, it would "fix" the "less in, more out" liquid bug Pumps in vanilla Terraria have, second it will cause endless Pump cycles to eventually run dry so the liquid wont lag the server over a long time.

Requires: Implement Modifiers

Timers should change their behavour when used with modifiers as the following:
1 - The Timers time is doubled.
2 - The Timers time is quadrupled.
3 - The Timers time is halfed.
4 - The Timers time is a quarter.

If a player, npc, mob comes into range, the component sends 1, if there are no more players closeby it sends 0.
I think the Crystal Ball would be a good sprite to represent this component.

Suggested Modifiers:
1 - The component will only react on players comming closeby.
2 - The component will only react on NPCs comming closeby.
3 - The component will only react on mobs comming closeby.

The range of the sensor should be configurable. Also, since this component can take up quite some performance for the checking, a limit per player should be configuable.

Though, I'm not sure on how useful this component will be in the end. Especially because this is quite a lot of work to implement.

I'd love to see a simple gate which only lets a pulse through it once and then stops working. I'm not sure if this is possible but I've been using this for pretty much everything in the vanilla wiring and i'd really like to see a simple and easy to use which isn't as environment dependent as the 'Boulder+water/lave+Pressure plate' contraption is.

I'm quite sure you understand what i'm referring to but i'll add a picture of it just in case.

(This is the mechanic that i'd really like to see as a gate or an easy way to remake the same feature in AC using less space)

Requires: #11

A Door that is opened should send a signal - thus a Door should become a Port Defining Component.

Modifiers:
1 - Only send a signal if the Door is used by a player.
2 - Only send a signal if the Door is used by a npc.
3 - Only send a signal if a mob broke through the Door.

As the title says, the activator cannot handle more than 1 tile high masses of silt. It's possible to use multiple activators that take one layer each but i feel that it shouldn't be necessary.

In the lower example only 1x8 tiles are removed by the activator and the 2nd layer is ignored and falls down.

EDIT: It was late and i forgot that it only worked for silt and not the other 3 sand types. I also updated the picture to show AC wiring and the use of silt blocks.

If a sign is signaled, it will state its content to the triggering player where the content text is prefixed with "Sign: " - this prefix should be configurable.

Requires: Implement Modifiers

It should be possible to define multiple configurations for Dart Traps and use them ingame using modifiers.

What I mean by that is, allow one to write "/somecommand {0}" on a sign (where {0} is replaced with the name of the player executing that circuit) and have that command executed as the sign is signaled.

I'm still unsure of how useful this will really be in the end because it could cause a lot of trouble. It would be hard to actually make this secure enought.

I will probably not even try to implement this, except there are a lots of requests from the community.

If a Statue is placed on a wired tile, but the user has no permission to wire up the given Statue, the Statue will be lost. Implement that the Statue item is dropped instead of being lost instead.

Requires: A pull request of me to the Infinite Signs repro to be accepted first. (MarioE/InfiniteSigns#4)

Currently, if the Infinite Signs plugin is installed, a sign that receives a "1" signal will send "Sign: " to the triggering player.

Requires: Complex Components

Add the following Tasks:
Chest.ContainsItems(ItemType = Any, Amount = 1, Exact = No, Label = None)
Chest.ContainsMoney(AmountInChopper, Exact = No, Label = None)
Chest.TakeItems(ItemType = Any, Amount = 1)
Chest.TakeItemStack(ItemType = Any)
Chest.TakeMoney(AmountInChopper = -1)
Chest.PutItems(ItemType = Any, Amount = -1)

Boulders should start rolling to the direction of the sending component when signaled.

Modifiers:
1 - The Boulder rolls to the opposite direction.

Let statues not perform one but multiple actions, where the action list can also be executed in two different ways:
-Execute one random action of the list
-Execute all actions at once
when triggered.

I would like to implement something to allow any block to become active / inactive when powered just like Active / Inactive Stone, by using the original tile type for active, and just Inactive Stone for the inactive state (so no walls at all) but use metadata to preserve the original tile type. So if that inactive stone is then powered, the original tile will appear again - instead of regular Active Stone.

I have no good idea on how these should be wired though.. maybe any blocks that is placed horizontally or vertically between two special blocks should be considered as this special kind of Active / Inactive Stone? But this would suck because the point of having any tile "switchable" is that you can hide secret passages with any tile type, they wouldn't be that secret though if one knows that tiles between two special blocks are considered like Active / Inactive Stone.
Maybe using special walls to indicate that the tiles over them should be threatened this way would do.. but I don't really like this approach either.

We already have OR, AND and XOR, which is great. However, at times, one'd need the inverses of those; NOR, NAND and XNOR. As it stands now, you'd have to do something along the lines of the left illustration below:

What I suggest is that the NOT should be able to join directly onto the output of another gate (as shown in the right illustration), thus eliminating the need for that extra piece of wire and glass block.

Requires: A pull request of me to the TerrariaAPI-Server repro to be accepted first. (cheahjs/TerrariaAPI-Server#12)

Fully integrate AC into Terraria Server by hooking into Door and full Pressure Plate usage of NPCs, mobs and projectiles.

If Block Activators have one Modifier and receive "1", they should not keep already existing blocks but replace them.

Requires: Complex Components

A very simple component that is just made out of 4 special tile types (maybe adamantite ore) in a horizontal row. Together with some Complex Component Tasks it might be used to warp players from one Plate to another or place items from a Chest on top of them.
Plates shall also send signals as blocks are placed onto or removed from them.

Modifiers:
1 - Send signal on block placement only.
2 - Send signal on block destruction only.

It should be possible for wires and components to be signaled more than one time per circuit execution.