Why are delays as they are?

[Arcaner]

I mean, c'mon, why are delays not configurable? I really need to use long timers a LOT. Is there some reason this isn't possible? Performance? Memory? Stubborn Schema? (That was a joke). Rails are not exact enough. They don't even have a we'll rounded off speed! (But that is another problem altogether)

The question: Why are delays as they are? Why has one extra line of code (I have no idea tbh :P) not been written to ease the life of poor Dave?

 

[Dire Venom]

I concur, for decent logic chains you end up with hundreds of delay blocks connected in series :/
A logic quality of life update would be phenominal!!

Obviously the devs have their hands full atm, but we can dream for the future :3

 

[AndyP]

Did you consider building a clock and feeding it into chained flip-flops?
It halves frequency with every added flip-flop in line.

Scales up to long times pretty fast.

- Andy

 

[YamiHikari]

Did you consider building a clock and feeding it into chained flip-flops?
It halves frequency with every added flip-flop in line.

Scales up to long times pretty fast.

- Andy

Really? I didn't know that. Is there a way to decrease the delay, too?

EDIT: And can you briefly explain what you mean by chained flip-flops? Do you mean in succession or in some kind of pattern?

 

[Tunk]

Flip flop signalling is a bit funky, and can give false true signals depending on the application (discovered this while developing the spamhibitor years ago).
Then again, most of the times I've used flip flops are for high speed counting, high speed speed signaling and signal multiplication purposes so may not be applicable for long period counter/timer purposes.
Just something to keep in mind when dealing with flip flops.

Anyway regarding chaining flip flops, you need to connect flip flops linearly, your delay at the start and connect it to a flip flop, which is connected to the next one and so on.
This will cause them to flip each other in sequence as a binary counter, since flip flops only change state on a true signal each flip flop in the chain will double the time it takes the last flip flop to change state.

 

[AndyP]

Chained means you feed one output into the next one.
Screenshot showing all connections. (Yellow marking is near "output" so consider them "arrows" marking the direction)



Binary clocks are not really 100% compatible with building real clocks,
but for most use cases it is enough to go for 64 seconds.

 

[kulbolen]

Chained means you feed one output into the next one.

i read chained memes and was confused. flip flops kick ass though.

 

[Arcaner]

Yes, AndyP I know about the flip flop chain but if I wanted to use that in a circuit, I would need to reset it automatically too, something that isn't really easy.

edit- whoops, of course it is, my bad!

 

[Benevolent27]

Chained means you feed one output into the next one.
Screenshot showing all connections. (Yellow marking is near "output" so consider them "arrows" marking the direction)

View attachment 47885

Binary clocks are not really 100% compatible with building real clocks,
but for most use cases it is enough to go for 64 seconds.

Good post AndyP !

Disclaimer: Keep in mind that any logic clock will be delayed by lag and such, so don't rely on it like you would an atomic clock.

Just to add to this, you can also add 2 clocks together. So for example, maybe you want a 20 second timer. So you can build a 16 second flip-flop clock and set it to turn itself off when finished, but also have it turn on a 4 second flipflop clock. When that clock finishes, it turns itself off and turns the 16 second clock back on. You can then produce a logic signal every 20 seconds. This can be used to create any EVEN number. You can then add a 1 second delay to achieve any desired number.

Note: To anyone building such a system, don't use buttons to turn off chained timers, because the timing will get thrown off. In my example above, for instance, use a NOT-block connected to the activation block of the 4-second timer to turn off the 16-second timer. Use the same setup on the output signal for the 4-second timer to turn itself off.

 

[AndyP]

It is not too complicated to reset the counter.



This can be impractical for some setups if they are too long.
But in most cases, it is not needed to cover every single flip-flop.

The only thing you need to consider:
They cross-influence each other when turning on, so the "reset" state works only when turning them OFF altogether.
Trying to turn them ON will trigger the next of them to also change state,
so it can be very tricky to start them in a specific "all on" state.
"All off" is way easier to achieve.

So for a timer counting to 20, you would only have to cover the bits that represent 16 and 4.
Both being "off" (timer starts at "All on") is the first occurrence of that combination in the binary counter line.

Needs some practice, but you can even create several sub-signals from a single counter that counts up to a specific state.

 

[Benevolent27]

It is not too complicated to reset the counter.

View attachment 47886

Hmm.. *scratches head*

You know..

Hmm.. So yes this would reset it, and I understand that you could have an AND gate hooked up to the 16 and 4 spots to get the 20 second timer (either to the flipflops themselves or the NOT block connected, depending on what the default state of the flip-flops are, either all off or all on), but then wouldn't the reset condition fire off when the clock was at 8 seconds if the default state for all flip-flops was OFF?

Basically after it resets, then all flipflops are off. The timer then counts to 8, so only the flipflop on 8 is on, so the reset triggers again.

Edit: Ooh, since it's 4 seconds into a 16 second clock, it would take an additional 12 seconds to complete the first cycle and then 8 seconds longer to reset itself, so that is 20 seconds. So you'd need to set up an OR block with both the reset trigger and to the set of AND (which are connected to the 4 and 16 second flip-flops and to the NOT blocks of the other two) to then produce a pulse every 20 seconds. I have to say Andy, I'm decent with logic, but you're better.

[doublepost=1519551518,1519549867][/doublepost]

If there is one thing I have learned in StarMade, it is to simply try to test things. Here were the results of my test. Each column of delays in the bottom right is 5 seconds (in logic-time).


So, in any event, I was wrong about it requiring the complicated condition setup, BUT we can see here that it is pulsing every 24 seconds, not 20!

So what is going on here.. where are these 4 extra seconds coming from.. hmm.. I'm guessing it's running 1 extra 4 second cycle to trigger the reset.

 

[AndyP]

Oh, my bad, I was not showing a 20-second timer.
The 20 second was only an example to not have to check every single flip-flop in most cases.

My setup pulses every 24 seconds, yes.

I will write up the exact states it goes through in detail.

Initial position: All OFF
1s clock
leading to a flipflop change every other second on the least significant bit on the counter.

0000 (0s) <- Initial position
1111 (2s) <- First clock cycle happened
0111 (4s)
1011 (6s)
0011 (8s)
1101 (10s)
0101 (12s)
1001 (14s)
0001 (16s)
1110 (18s)
0110 (20s)
1010 (22s)
0010 (24s) <- AND gets triggered

The AND will unset the third bit, and reset the counter to the initial position.
The next clock cycle will then hit the initial position again,
so this setup pulses every 24 seconds.

So for a 20s timer, it would need to have

NOT
OR
OR
NOT

on the output coupling side leading to the AND.

 

[Benevolent27]

Oh, my bad, I was not showing a 20-second timer.
The 20 second was only an example to not have to check every single flip-flop in most cases.

My setup pulses every 24 seconds, yes.

I will write up the exact states it goes through in detail.

Initial position: All OFF
1s clock
leading to a flipflop change every other second on the least significant bit on the counter.

0000 (0s) <- Initial position
1111 (2s) <- First clock cycle happened
0111 (4s)
1011 (6s)
0011 (8s)
1101 (10s)
0101 (12s)
1001 (14s)
0001 (16s)
1110 (18s)
0110 (20s)
1010 (22s)
0010 (24s) <- AND gets triggered

The AND will unset the third bit, and reset the counter to the initial position.
The next clock cycle will then hit the initial position again,
so this setup pulses every 24 seconds.

So for a 20s timer, it would need to have

NOT
OR
OR
NOT

on the output coupling side leading to the AND.

Ah, it sure helps to think of it is a bit counter! Yeah, and then I route the reset to turn off any flip-flops that are currently on to reset the system back to all off state. Thanks Andy!

 

[Temeter]

I agree, there should be more options; but rather from the exact opposite side! For the stuff I did, I wanted a tiny delay, <100ms, and the delays were far too long^^

It's cool to see how people work around a lot of those short-comings, but I really don't think that's too valuable in the long run.

 

[AndyP]

Shorter than 0.5 seconds is not possible with the delays.

The only way is a rail rotator together with a speed controller.
It should be possible to get a quite reliable 4 pulses per second out of it. (Not time corrected, as the delays are!)
But anything faster is more an exploit than a reliable signal source.

 

[Temeter]

Shorter than 0.5 seconds is not possible with the delays.

The only way is a rail rotator together with a speed controller.
It should be possible to get a quite reliable 4 pulses per second out of it. (Not time corrected, as the delays are!)
But anything faster is more an exploit than a reliable signal source.

Thanks, I see. Wondered if that delay was hardcoded.

 

[MacThule]

Yeah... I love the binary logic, but that's a lot. And takes up a fair chunk of space in the game for something we fit onto a microprocessor IRL. For a timer which, if input-configurable, could take up 1 cubic meter and be player intuitive.

I gotta agree with the OP. Configuring delays would be super nice.

Should we also mention that when you start wiring too many logic blocks into multiple mechanical systems that will all be operating at once, you risk inadvertently sending a bunch of "logic bomb" warnings to admins in multiplayer? That's a hassle for everyone involved.