if you still want to know, think of a logic activation block connected to an or-gate, when you activate the logic activation block, the or-gate activates immediately, doesn't it? well no, the instant pulse you observed wasn't quite that instant, there is a tiny mini delay of like 0.01 second or something, you can abuse this is ways i have not found limits with. for more information go to here:
http://starmadedock.net/threads/instant-pulses-and-some-starmades-logic-details.8117/
That's not completely correct, what I was talking about in this topic is a side-effect of how starmade computes logic (or at least, how I think it does since I don't have the code, but it's consistent with my observations) which can lead to surprising results at first.
I'll try to summarize what I wanted to explain in this topic:
The idea is that starmade tries to stabilize the whole circuit each time a state changes. In other words, the propagation of logic states is (supposed to be) instantaneous. There are three problems with that approach though:
1 - some gates must flip states multiple times when Starmade stabilizes the logic states
2 - it makes it harder to see races conditions
3 - some circuits are kind of degenerated and don't have any stable state
The first one is what gives birth to what I called "instant pulses". They actually really are "instantaneous" (I mean, if we consider "in game time") as Starmade tries to stabilize the circuit in one go, but they exist nonetheless.
For instance this circuit (omitting the top flip-flop which is only here to "detect the instant pulse"):
http://starmadedock.net/attachments/starmade-screenshot-0022-png.12867
has two stable states:
- if the button is off, the activation module is off and the flip-flop is off
- if the button is on, the activation module is on and the flip-flop is also off (that flip-flop is always off in the stable states)
However, when you push the button, the flip-flop turns on (because of the button) then turns off (because of the activation module) during the stabilization step. That's what I call an "instant signal" and why the top flip-flop flips its state when you push the button.
The second one is basically saying that when you push the button in the aforementioned circuit you don't see the bottom flip-flop turning on at all: Starmade treats that as instantaneous, it only updates the image once the circuit has reached a stable state, even if your computer was awfully slow it would just freeze while Starmade computes the stable state of the circuit (and it wouldn't display the bottom flip-flop turning on)
However, when Starmade computes the stable state it actually "thinks": "Oh the button turned on! hence both the activation module and the flip-flop(bottom) turns on! Wait, if the activation module turned on, the flip-flop must flip its state, so it's actually off now! Oh I have nothing else to do, this is a stable state, I'm finished, yay". Theoretically there's some kind of "chronological order of signals" in each of those stabilization steps and sometimes you have to take it into account to understand why a circuit works the way it does, but it's hidden.
The third one is certainly the most bothersome (and actually, it involves the part I haven't written yet):
Starmade tries to compute something which might not even exist! Think of a Not gate connected to itself for instance, such a circuit can't reach a stable state. However you can build such circuits in Starmade and of course the game isn't allowed to freeze forever thinking "the not gate is on, so it's off, so it's on, so it's off...".
That's why Starmade chose a quite radical solution to cope with those troublesome circuits: don't take into account any retroaction loop in a single stabilization step.
...of course, delay blocks doesn't count as they trigger another stabilization step 0.5s later (and it's exactly why sometimes there's no way around delays if you want something small).
The main reason why I talked about this is because sometimes a circuit shows strange results and you can't figure out why. Most of the time, it's due to these things (for instance a signal is slightly "late", which was the case in my first "xor" example).
It turns out that understanding why and when these problems happen can help you reducing the number of delay blocks in your circuits to make them faster ("in game time" I mean) and/or designing them differently (it can also be used as a more potent "input protection" as when a circuit stabilizes, the game is basically frozen, nobody can push another button).
However, instant pulses can't be used to time things: their duration is either 0s ("in game time") or something uncontrollable depending of your computer and Starmade's load ("real time").
