It doesn't work when the output is clogged - the train won't unload even though there's plenty of space.
It also continues counting needlessly when the train isn't unloading.
It also doesn't have the "wait for train to arrive" part, unless I'm missing something.
Re: Combinator Contraptions
Posted: Tue Oct 20, 2015 5:38 pm
by Lupoviridae
The Lone Wolfling wrote:
It doesn't work when the output is clogged - the train won't unload even though there's plenty of space.
If by "the output is clogged" you mean the detector (smart chest) has something in it, this is intentional. It allows the storage chest to fill up (the iron chests in this case). The smart chests are not intended to fill up, they just convey the signal that "something has just been unloaded".
The Lone Wolfling wrote:
Actually, ideally what I want is a signal that changes as soon as possible after either the chest is full or the number of items isn't increasing, while remaining steady while items are being added by a fast inserter. The other edge isn't as critical.
Pretty sure this is exactly what you asked for. No signal if the storage chest is full, aka "the output is clogged".
The Lone Wolfling wrote:
It also continues counting needlessly when the train isn't unloading.
I'm guessing you mean the unidirectional clock elements. Again, intentional. Them counting up doesn't affect the final signal you are trying to produce. They reset when the train arrives once more. Basically these count the time since the last item was unloaded from the train into storage. When the train is away, yes, this number gets pretty high. Unidirectional clocks are essential if you want to create a combinator setup that uses tick-level timing.
The Lone Wolfling wrote:
In other words, a circuit that will output only when a certain configurable amount of time has passed since the last time the input was triggered.
How do you expect to trigger "when a certain configurable amount of time has passed", unless you are counting how much time has passed?
The Lone Wolfling wrote:
It also doesn't have the "wait for train to arrive" part, unless I'm missing something.
The light turns on almost immediately when the train arrives. This setup produces a constant signal only if a train is present and being actively unloaded. What else were you looking for? As far as I can tell this does what you asked for with the minimum possible delay (.492 seconds on the rising edge, .5 seconds on the falling edge).
Edit: To get your constant signal, you will need to replace the light with a combinator set to produce a signal when Blue < 30 (like the light is currently set). Sorry if this wasn't clear.
Re: Combinator Contraptions
Posted: Mon Nov 23, 2015 2:05 am
by goku90504
what version is this from? I recently bought the game (in the last week or two) and I've got a free play game where I've done all the research but I don't have access to a few items mentioned in the wiki such as the combinator's or the personal roboport
Re: Combinator Contraptions
Posted: Mon Nov 23, 2015 1:04 pm
by Xeteth
goku90504 wrote:what version is this from? I recently bought the game (in the last week or two) and I've got a free play game where I've done all the research but I don't have access to a few items mentioned in the wiki such as the combinator's or the personal roboport
I am guessing you are running on version 0.11.x - you need to update to the 'experimental' branch (that is pretty much what everyone uses and is currently more or less the stable 0.12 release), this can be done under settings; something like "Enable experimental updates".
XKnight wrote:Today I rewatched my previous memory cell, and I found that it is also complex and not optimal.
Update:
if ["0" signal = 1] it remembers input value
if ["0" signal > 1] it clears the stored value
So, you can use it only with ["0" signal = 0 or 1] as a memory cell.
=1 vs >1 is not the same as
=1 or =0
1/0 seems to work; 1/2 does not.
1/0 causes the internal trigger signal value to count up, and cause an integer overflow, if you store the value too long.
The factorio Lua API describes the signal count to be an uint (usually 0--4.294.967.295, that would make about 2,2 years in real time), but since factorio allows negative values, I suspect the actual lifetime of your memory to be half of that.
Re: Combinator Contraptions
Posted: Mon Aug 22, 2016 10:43 pm
by XKnight
phi1010 wrote:
1/0 causes the internal trigger signal value to count up, and cause an integer overflow, if you store the value too long.
The factorio Lua API describes the signal count to be an uint (usually 0--4.294.967.295, that would make about 2,2 years in real time), but since factorio allows negative values, I suspect the actual lifetime of your memory to be half of that.
I am 100% sure that you've made some mistake, take a look more attentively.
Triger signal will never count up (It is even visible on the movie - combinators blink only when input signal is updated)
XKnight wrote:(It is even visible on the movie - combinators blink only when input signal is updated)
We might be talking about different designs.
The movie shows ">" and "<" combinators; the image in the linked post (viewtopic.php?p=94729#p94729) shows "=" and "<", doesn't seem to be the same.
EDIT / PS: The Blueprint shows me "=" and "<" too... that neither seems to go together with the gif.
Re: Combinator Contraptions
Posted: Tue Aug 23, 2016 1:36 am
by XKnight
phi1010 wrote:
XKnight wrote:(It is even visible on the movie - combinators blink only when input signal is updated)
We might be talking about different designs.
The movie shows ">" and "<" combinators; the image in the linked post (viewtopic.php?p=94729#p94729) shows "=" and "<", doesn't seem to be the same.
EDIT / PS: The Blueprint shows me "=" and "<" too... that neither seems to go together with the gif.
Yeah, perhaps I recorded video with "> 0", but lately decided to switch it back to "= 1" (why? I don't know ).
But results are the same in both cases
Re: Combinator Contraptions
Posted: Wed Aug 24, 2016 1:31 am
by phi1010
XKnight wrote:
phi1010 wrote:
XKnight wrote:(It is even visible on the movie - combinators blink only when input signal is updated)
We might be talking about different designs.
The movie shows ">" and "<" combinators; the image in the linked post (viewtopic.php?p=94729#p94729) shows "=" and "<", doesn't seem to be the same.
EDIT / PS: The Blueprint shows me "=" and "<" too... that neither seems to go together with the gif.
Yeah, perhaps I recorded video with "> 0", but lately decided to switch it back to "= 1" (why? I don't know ).
But results are the same in both cases
Eh... i know i'm evil... the movie and blueprint still have another (probably insignificant) difference to the image from the earlier post: movie and blueprint connect the input data ("1" and "0") to both combinators, not just the trigger signal... the image did not...
I might have caught your circuit (the one from the still image) on the wrong foot, providing quick input while still building it and making a mistake somewhere, and causing it to start counting that way... I don't see how I got it to count up, but my excel sheet tells me that the correct version is unstable anyways until the output has reached the value 1 for the trigger signal type. This happen's as soon you trigger the signal for two ticks in a row. If you don't reset the circuit before using it, it shouldn't be able to remember anything for more than one tick -- as almost every combinator does... well, maybe not the y=x*0-combinator
Tell me if I'm wrong... please don't, i've checked twice. =D
For anyone who'd like to know what actually happens:
Numbers
The good working part: (Imaginary numbers for the "red" trigger signal, real numbers for the data signal. We don't need more that one for testing, one can't mix that much up, when only using "each" and "red" as signal types.)
2016-08-24 02_55_11-factoriocirc.xlsx - Excel.png (47.37 KiB) Viewed 7680 times
The moment it failed:
2016-08-24 03_02_16-factoriocirc.xlsx - Excel.png (56.84 KiB) Viewed 7680 times
Localized Formuals
Two rows from my excel sheet, probably virus-free.
Is swearing allowed in this forum? I hate *** localized programming languages. It might be COMPLEX(KOMPLEXE), IMSUM(IMSUMME) and IMPART(IMAGINÄRTEIL) and IF(WENN) in English.
phi1010 wrote:
I might have caught your circuit (the one from the still image) on the wrong foot, providing quick input while still building it and making a mistake somewhere, and causing it to start counting that way... I don't see how I got it to count up, but my excel sheet tells me that the correct version is unstable anyways until the output has reached the value 1 for the trigger signal type. This happen's as soon you trigger the signal for two ticks in a row. If you don't reset the circuit before using it, it shouldn't be able to remember anything for more than one tick -- as almost every combinator does... well, maybe not the y=x*0-combinator
Tell me if I'm wrong... please don't, i've checked twice. =D
Yes, you are right, but I would like to call this an "initialization phase", where you should manually check if this memory cell is ok or not.
So, at first you shuild build this cuircuit, then you should manually send trigger signal for 2 ticks and intilization phase will be finished.
After that memory cell will be able to record any signals with 1 tick duration.
Re: Combinator Contraptions
Posted: Fri Aug 26, 2016 8:14 pm
by siggboy
XKnight wrote:Yes, you are right, but I would like to call this an "initialization phase", where you should manually check if this memory cell is ok or not.
So, at first you shuild build this cuircuit, then you should manually send trigger signal for 2 ticks and intilization phase will be finished.
After that memory cell will be able to record any signals with 1 tick duration.
How many devices do you have in your household that have you go through a manual initialization like this one?
It's something from the computer stone age, when stuff was actually input in proper machine language.
In my opinion, if you can't blueprint a circuit and it just works, then that's really a showstopper. (Having a constant combinator that can be removed after powering up the circuit is kind of OK, but going into the contraption and MANUALLY initializing registers, that's kind of tedious, don't you think?)
I actually did use the 2-combinator register for a short while, but then stopped after realizing that this limitation exists.
Re: Combinator Contraptions
Posted: Fri Aug 26, 2016 8:23 pm
by XKnight
siggboy wrote:
XKnight wrote:Yes, you are right, but I would like to call this an "initialization phase", where you should manually check if this memory cell is ok or not.
So, at first you shuild build this cuircuit, then you should manually send trigger signal for 2 ticks and intilization phase will be finished.
After that memory cell will be able to record any signals with 1 tick duration.
How many devices do you have in your household that have you go through a manual initialization like this one?
It's something from the computer stone age, when stuff was actually input in proper machine language.
In my opinion, if you can't blueprint a circuit and it just works, then that's really a showstopper. (Having a constant combinator that can be removed after powering up the circuit is kind of OK, but going into the contraption and MANUALLY initializing registers, that's kind of tedious, don't you think?)
I actually did use the 2-combinator register for a short while, but then stopped after realizing that this limitation exists.
In this case you should modify your blueprint and add this constant combinator nothing else
Re: Combinator Contraptions
Posted: Fri Aug 26, 2016 8:51 pm
by siggboy
XKnight wrote:In this case you should modify your blueprint and add this constant combinator nothing else
Yeah, well I'll use a register that doesn't require any shenanigans . The circuit needs to be done when it's blueprinted, anything else is low-tech and flawed.
(It is even visible on the movie - combinators blink only when input signal is updated)
).