In this video, I will show you how to build a functional Life or Score counter in Pixel Worlds using Wiring! I hope you enjoy the video!
In the video I also came across a bug, so I hope @Dev will see this, as I don’t think I should just repost this in the Bug Report section.
love how you make new stuff with wiring!
i need this btw for my new world i will made in few months
That’s great to hear!
When the world is done, make sure to post it and tag me 
I’ll try to explain the problem, please bear with me and my stupid drawings. I have reproduced the bug here:
The first image shows the order of the connections as they are in the first toggle gate. So you’re right, the order of the connections does matter here. Here I’ve connected the first (bottom) toggle gate in the order AND, OR, TOGGLE (upper).
Now, the way wiring works is it evaluates the trigger first, which is the pressure pad here. The pressure pad realizes it was toggled, and the signal will start to traverse all the connections, trying to “reach” the end items. First it will check that OK, there’s this toggle gate (bottom) that needs to be checked. It will toggle the gate, because that’s how they work. The gate will pass the signal on, since its state has now changed. If it wouldn’t have been toggled (like if there was an AND gate with only this input here here instead), the traversing would have stopped here.
Since the AND gate happened to be connected first, it will be evaluated first (second image). The AND gate realizes: “OK, I’ve got an ON signal from a toggle, what’s the status of my other input?” It has to traverse backwards to check the other input, which is the upper toggle gate here. It will check its status from the input, and pass on the correct state to the AND gate.
The system will check the OR next (third image). Nothing special here, both toggles will be ON at this point.
An interesting thing to note here is that all gates have been evaluated at this point at least once, but the other toggle gate (upper) has still not been checked properly. This means that the middle light hasn’t been touched. The system also saves the states of the evaluated gates so that it doesn’t have to traverse everything again. Doing so might cause endless loops that could be fatal. However, that’s not the thing causing the problem here. Just a heads up: This is why some of the complex or “impossible” loops seem to fail.
Here’s the bug: Now it’s time to traverse the final gate, which is the connection from the bottom toggle to the upper toggle. This will determine the final fate of the middle light. Here’s the catch: There’s an optimization that prevents unnecessary toggling of items for some gates. If the state did not change, there’s no reason to do anything. Since the AND gate traversed backwards and checked the upper toggle, its state was already changed, but this didn’t affect the light, because it was only evaluating the outputs of the AND gate. I’m not entirely sure why the client shows the correct connection here, it’s probably because it updates the visuals immediately when the state of a gate changes, it doesn’t have to care about which items are connected to it.
So now the gate checks the state relative to the first toggle and… nothing happened from this perspective! It just checks that “oh, the state is what it used to be, no need to traverse the output” (fourth image). So the light remains how it was, no matter how many times the pressure pad is used.
The fix is simple: There’s a list of gates whose outputs need to be re-evaluated every time no matter what, such as the Randomizer gate (toggling it means randomizing the output again). I’ll add the toggle gate to this list. I tested it, and it will fix this system.
The order in which you connect the gates may make a difference. You can take advantage of this by making some complex latches that just happen to work using a specific order, but mostly the result is just some kind of unexpected behavior due to a faulty system or a bug in the game (like in this case).
A tip for re-ordering the gates in this scenario: You don’t have to destroy the gates, just disconnecting them will do the trick. A lot of the gate data will also be cleared if you disconnect the “power source”. If you would have a ton of timers going haywire in this system, you could just disconnect the pressure pad and it should clear all the “memory” and whatever data the timers have stored so far.
Thank you a lot for explaining this in such depth!
It’s really interesting to know how the Wiring sort of works under the hood. I think it could help me a lot, if I stumble across similar issues again. I now also get (or at least I think I do), why a “loop detected” yellow message could not be easily implemented, or only at the cost of performance.
I hope that this doesn’t cause noticeably worse performance, since from how I understand it it would do more “calculations”, but what do I know 
.
Disconnection Gate
(please 
)
I don’t think the performance will be a lot worse. I guess you might run into issues if you make a system with hundreds of toggles or something. I’m more worried about existing system that only work because of this bug. There may also be other unknown issues that will only become visible with this change. The variety of things you can build is almost infinite and this simple system tries to work with every possible implementation.
The disconnect gate is basically a trigger that has an input. We left inputs out of levers and such because of several issues (which I can’t recall) and due to some design reasons. One issue were the problems they introduced in looped systems. I can understand the problems that you might encounter with timers. In hindsight it might have been better if they had a more realistic approach and the timer functionality would have been created by triggers or something, but it is what it is.
I think the biggest problem with timers is their “memory”, which can basically overflow and will cause some weird behavior. (You can add more input signals to a timer than it has the time to dispatch.)
