[Fixed in 13.9] Intended, or an oversight? (belt sensors)

[Tinyboss]

Make a belt, connect a single tile to a power pole, and set it to both enable/disable, and read contents (hold). Make sure it's disabled, and put an item at the beginning of the belt. It'll get stopped by the disabled section, but if you mouse over the power pole you see that it's sensing that item. I think it makes more sense to have it not sense the item until it is able to pass into the tile that's sensing.

The current behavior seems weird to me, and it's frustrating my attempt at making a no-power SR latch.

Edit: Please read my post below on belt logic to see what kinds of cool things are almost, but not quite, possible with the current behavior.

[EvanT]

Actually I prefer it that way!

With the functionality as it is you can build a power regulator with only two circuited belts. (Which is an RS-Latch, set on one condition, reset on another)

Build a belt ring. Connect an accumulator to one belt. Set this belt to count hold and activate if the power level is below 40%. Connect the accumulator to a second belt and set this one to activate if the power level is higher than 80%. Put one Item on the belt so it rests before the first belt and is counted. Connect the first belt to the power switch (connecting eg. the steam power plants) and set it to activate if the Item count is less then 1.
This way the switch will engage if the power level got below 40% and will only disengage when the power level rises above 80% again.

[Tinyboss]

Yeah, that's more or less what I've been making. But your regulator doesn't activate right away--once the input (power < 40%) changes, the item has to travel all the way across the belt tile before the output changes. If it worked the way I described in the OP, it could be immediate.

[Pavgran]

But you can make two belts facing each other. That way item transfers almost immediately.

[Tinyboss]

But you can make two belts facing each other. That way item transfers almost immediately.

Have you built this? I tried and the item doesn't seem to move regardless of how I activate or deactivate the two opposing belts.

[Pavgran]

But you can make two belts facing each other. That way item transfers almost immediately.

Have you built this? I tried and the item doesn't seem to move regardless of how I activate or deactivate the two opposing belts.

I tested it mentally, and then tried to build. Yep, it doesn't work that way, sadly.

[ssilk]

I think the way why this works like so is, because the item needs to be on the same belt to be stopped.

It's the same as with a ball-boy, which is not allowed to catch the ball, until it is not rolling into out. He cannot catch the ball in the field, only outside; but then the ball is not longer in the field.

(The outside here is the connected belt, the inside is the previous.)

[Tinyboss]

It's the same as with a ball-boy, which is not allowed to catch the ball, until it is not rolling into out. He cannot catch the ball in the field, only outside; but then the ball is not longer in the field.

(The outside here is the connected belt, the inside is the previous.)

There is no doubt that your description correctly matches what happens in the game. I don't believe it's an intuitive way to do it, though.

Suppose a belt tile is moving and set to read contents (hold). If the next tile is empty ground, then an object will not fall off the end, and continues to be detected. But if instead of empty ground the next tile is a disabled belt, then the object does pass through the sensor tile and stops being detected.

What is different about a stopped belt versus regular ground? I argue that intuitively they should behave the same--each is a non-moving surface.

Edit: I have also been finding the current behavior extremely inconvenient when I try to build "belt logic" programs. I hope I'll be able to explain the trouble clearly...

I want to use an object (say an alien artifact) on the belt as a kind of instruction pointer, and the belt loop will be my program loop. The belt can have sensor tiles (turn something on/off if the artifact is present) and stopper tiles (hold up the artifact or pass it along depending on a condition). Delays are easy to build in with empty belt sections. If statements can be done with inserters. I think there's a lot of potential for this kind of automation.

Now suppose I have a sensor tile followed by a stopper tile which is currently stopped. The expected behavior is that the artifact remains in the sensor tile until the stopper tile starts running again. But what actually happens is the artifact leaves the sensor and passes to the stopper tile no matter what. It either stops immediately or continues on, but either way, it's gone from the sensor tile.

So my only option is to combine the sensor and stopper into one tile, but that has at least two annoying consequences. First, it creates latency between the stopper becoming active and any change in the sensed position of the artifact--it has to cross an entire belt tile before any signal change can be produced. Second, the presence (or absence) of the artifact at the stopper tile makes it hard to use any/every signals properly.