Combinator Logic

[Sander Buruma]

Hi all,

I've made this tiny combinator circuit here:
http://youtu.be/vLLZLqXDURI

In it you see it functioning but not entirely in the way I expected, ie. it works but I don't understand why. The left hand combinator in a feed back loop keeps on adding 1 onto the "0" signal. When it gets to 1000, the top right hand decider generates a "1" signal with a quantity of 1 (if I could make it generate a quantity of 1000 I would). The multiplying combinator below it multiplies it by 333 and outputs that as signal "2" and the final subtracting combinator subtracts signal "2" from "0".

My intention is that the "0" signal gets to a count of 1000 and then goes back to 0, which it does. What I don't understand is, why does the 1000 - 333 equal to a 0 signal quantity? I thought I'd have to set the subtractor combinator to 1000 and not 333, but somehow it gets subtracted 3 times before the entire circuit resets.

[ratchetfreak]

maybe each combinator has a 1 tick delay before the output updates (so feedback loops are dealt with in a sane manner). So there are 3 ticks until the 1 signal from the decider reaches the subtractor and the 0 signal gets subtracted, after it gets subtracted the first time there are still 2 ticks until the updated signal from the decider reaches the subtracting combinator

Slow down the game with /c game.speed=0.1 so you can see it in action

[Sander Buruma]

That makes sense, it seems that combinators take 1 tick to update upon meeting any circuit condition. Even lights turn on 1 tick after their condition is met.

[lyallp]

You don't need to restart the game to slow it down.
Use the LUA console (` grave) then type

Code: Select all

/c game.speed = 0.1

It looks like the slowest speed we can go to is 0.1, which still pounds away on a smallish map, on my computer, at about 3 increments a second.

It would be nice if we could single step, so I could see what is happening.

So, what you seem to indicate is that a 'logic' device requires one game tick, that the output of that device is consumed by the next device in the next game tick, whose output is consumed by the next device in the next game tick.

So if we have a cascade of 10 devices in a row, it should take 10 ticks for the result to come out the final device?

Going to go and do 10 accumulators in a row and see if I can watch it, in game slow mode...

I watched it in slow mode and I *think* things are happening like the following, the sequencing is because the output of one device is fed as input to another.
I would love to be corrected on this.

Code: Select all

# Assuming each light lights in multiples of 200
#  1 @ [0] > 200
#  2 @ [0] > 400
#  3 @ [0] > 600
#  4 @ [0] > 800
#  5 @ [0] > 1000

# The (>) Combinator generates a single [1] if [0] > 1200

# Starting condition is
#  [0] = 1200, [1] = 0, [2] = 0
#  All lights on

In the example cascade light display, the output is something like this, when [0] hits 1200
Tick 1:
 (+) Increments [0], giving 1201x[0]
 (>) Does nothing yet as it's input has come from the previous tick, where 1200x[0] was set
 (*) Does nothing yet
 (-) Does nothing yet
 Output
  [0] = 1201 	in Green
  [1] = 0    	in Red
  [2] = 0    	in Red
Tick 2:
 (+) Increments [0], giving 1202x[0]
 (>) Generates a [1], because [0] is > 1200 (it's input was [0] = 1201 from Tick 1)
 (*) does nothing yet, because there are 0x[1] in the network
 (-) does nothing yet
 Output
  [0] = 1202	in Green
  [1] = 1	in Red
  [2] = 0	in Red
Tick 3:
 (+) Increments [0], giving 1203x[0]
 (>) Generates a [1], because [0] is > 1200 (it's input was [0] = 1202 from Tick 2)
 (*) multiplies 1x[1] by 333 giving 333x[2] because there was 1x[1] Genenerated from Tick 2
 (-) does nothing yet
 Output
  [0] = 1203	in Green
  [1] = 1	in Red
  [2] = 333	in Red
Tick 4:
 (+) Increments [0], giving 1204x[0]
 (>) Generates a [1], because [0] is > 1200 (it's input was [0] = 1203 from Tick 3)
 (*) multiplies 1x[1] by 333 giving 333x[2] (it's input was [1] = 1 from Tick 3)
 (-) 1203x[0] minus 333x[2] giving 870x[0] output to the Green network
 Output
  [0] = 870	in Green
  [1] = 1	in Red
  [2] = 333	in Red
Tick 5:
 (+) Increments [0], giving 871x[0]
 (>) Does nothing, because [0] has fallen below 1200, generating 0x[1]
 (*) multiplies 1x[1] by 333 giving 333x[2] 
 (-) Subtracts 333x[2] from 870x[0] giving 537x[0] output to the Green network
 Output
  [0] = 537	in Green
  [1] = 0	in Red
  [2] = 333	in Red
Tick 6:
 (+) Increments [0], giving 538x[0]
 (>) Does nothing, because [0] has fallen below 1200, generating 0x[1]
 (*) Does nothing because there are 0x[1] in the Red network, generating 0x[2]
 (-) 537x[0] minus 0x[2] giving 537[0] output to the Green network
 Output
  [0] = 537	in Green
  [1] = 0	in Red
  [2] = 0	in Red
Tick 7:
 (+) Increments [0], giving 539x[0]
 (>) Does nothing, because [0] has fallen below 1200, generating 0x[1]
 (*) Does nothing because there are no [1] in the Red network, generating 0x[2]
 (-) Subtracts 0x[2] from [0], doing nothing
 Output
  [0] = -538	in Green
  [1] = 0	in Red
  [2] = 0	in Red

Rinse and repeat.

[lyallp]

Actually, I think the problem lies in the fact you are using 2 separate red networks.
It appears that calculations are done for an entire network, and the results output.
If the outputs go to a new network, that network is calculated next game tick, using results of the previous ticks output, as input.
Your green network is all one network, connected by the power pole.
I am unsure if putting another power pole to act as a central point for the two red networks, combining them into a single red network, makes any difference.

[provet]

https://youtu.be/EI9h54ZTdNo Playing around with combinators