Open zaqen opened 11 years ago
Had that in consideration too, but reverse processing a circuit always felt like too much work to implement considering the rather low benefit of having Logical Gates initialize themselfes.
Edit: Not to forget that, as for many circuits, the automatic initialization would fail anyway because the incoming signal can not always be assumed (imagine two switches in different states connected to one wire that is then connected to one Input Port of a Logical Gate for example).
Well that is if the signal was sent by the wires. My thought was that you could have something that scans a large tile area and initialize all of the wiring within that area. So sort of like a dynamite that doesn't destroy the tiles but registers them instead =)
Unfortunately its not that easy. It appears that you don't really understand why Logical Gates have to be initialized at all. This is actually a feature, it is not to annoy the user, if I could initialize a Gate as easy as you are describing, I would of course never have implemented it that way.
The problem about Gates is that they have to preserve the states of their Input Ports, they need to know whether their Ports are 0 or 1 in order to operate because they couldn't produce a resulting signal otherwise. As for new (unregistered) Logical Gates I could, of course, just define that they treat all of their Input Ports in a 0 state instead of being "not initialized", but this might cause a Gate to produce unexpected output as it received its first input signal. This is why I actually implemented Gate initialization at all, because as all Input Ports of a Gate have received a signal, the Gate can start producing reasonable output, since it now knows all of its input data, making it actually less troublesome for the players to work with as they will never get "wrong" but just no output from it.
Thus, to proper automatically initialize a Logical Gate, there would be no way around reverse processing all the wires of a Gate's Input Ports to "guess" what state that Input Port might currently be in.
Though, I might improve the "/ac switch" command to directly set the Input Port states of a Gate to offer a quick way of initializing it, just as Ijwu hoped / suggested already.
Ah, I'm sorry but i thought that the initialization was about locating the gates after them being placed. I thought this was the cause since the database doesn't show a gate unless it has been initialized or added manually. I might be rather dense or just stupid but i can't see the issue with having a default state of input ports which isn't 0 or 1. So having a "2" state as default, with no utility for the input makes it a lot easier to work through TEdit.
The Ports kind of have a "2" state as default which is actually a null-state. Logical Gates are not registered in the metadata right away because I've never seen a point in that, they are registered as soon as they receive their first signal through one of the Input Ports though.
So if you have an AND-Gate with two Input Ports and you power it with "1" on one of these, the Gate will be registered with the Port states "1" and "null", and as long as one of these states remains "null" the Gate is not properly initialized and thus wont forward signals.
So it appears like what you want to have is that, as the metadata of a world are initialized, all placed Logical Gates get registered right away, having a null-state for all of their Input Ports? This would still not initialize them, they would just be registered in the metadata, so how would you benefit from that?
Sorry for becoming inactive, I'll post a picture of a setup that would greatly benefit from it. (After work)
EDIT: If you have a chain of timers that is set to work once, not to be repeated. (Like a mini-game) Then the timers will have to fire twice to have a single effect.
Having them initialized instantly without activating them would mean that you could manually alter all gates and by that much easier change the settings around for mini-games.
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.