[0.17.79] Gate sensor output does not match actual gate state for trains.

[JasonC]

Issue(s):

• When an automatically controlled train passes through a gate, the gate's sensor output appears to stay on for a fixed amount of time (weird) regardless of the length and speed of the train. This causes two effects: For short trains, the sensor output stays on too long. More problematically, for long trains, the sensor output turns off a significant amount of time before the train passes.
• When a train approaches a gate at a very slow speed, the sensor output of the gate flickers erratically. Note that when the train is under manual control, the flicker does not correspond to key presses (e.g. if you are "pumping the accelerator") -- it just seems to happen at its own independent rate.

However, the above issues do not occur for other vehicle types, regardless of speed. Nor do they occur for a walking player. The issues only occur for trains. Also note that the sensor output appears to function correctly when the train is stopped in the gate under manual control.

The primary description of the issues, however, is this: What I expect to happen is that in all cases, the gate sensor read output matches the green/red light on the gate itself. What actually happens is that, for trains only, it does not.

A save file is attached. It contains three trains of different lengths, a buggy, and a constant combinator that can be turned off to stop all the trains if desired. There might be some mods in the save but none are actually used and this is intended for vanilla.

Additionally, here is a video of the issue. I apologize for its length (higher res):

Related/old bug reports:

• viewtopic.php?f=23&t=72229
• viewtopic.php?f=23&t=31941

These were both labelled "not a bug", but I believe that to be the wrong judgment, because (as mentioned above):

• The issue is unique to trains.
• The fixed length of the output signal for trains is weird (as a programmer I feel like this is a tell-tale sign that somebody hacked some code in somewhere ).
• The sensor output stops too early for long trains even when they are still in the gate.
• Most importantly (and this covers both of the above) the sensor output matches the gate's built-in status light in all cases except for moving trains. I believe this to be the strongest argument that this is a bug; most notably because the argument that "well it's the sensor not the gate" becomes weak when considering that for every other vehicle type, the sensor output matches the status light precisely. It should be consistent for all vehicles.

[Loewchen]

All but the last point of yours are explained by the reasons given in the reports you linked: There is no signal for the state of the gate, there is only a signal for it's opening trigger.
For the last point, what happens to the signal when you drive a car on top of the open gate, exit it and walk away?

[JasonC]

For the last point, what happens to the signal when you drive a car on top of the open gate, exit it and walk away?

When you drive a car on top of an open gate and walk away, the following happens:

• Aside from any gate tiles directly under the vehicle, the gate closes.
• The gate status light turns from green to red.
• The gate sensor read output turns off.

Throughout the entire process, the gate sensor read output matches the gate's green/red status light exactly.

This actually makes a brief appearance in the video towards the end of me controlling the buggy (seek to 1:10).

[Loewchen]

I then don't see a discrepancy between signal behavior along vehicles nor a violation of the signal description to be present when there is a trigger.
A dev can move it to duplicates if the original decision still stands.

[Rseding91]

I then don't see a discrepancy between signal behavior along vehicles nor a violation of the signal description to be present when there is a trigger.
A dev can move it to duplicates if the original decision still stands.

It does.

[JasonC]

I then don't see a discrepancy between signal behavior along vehicles nor a violation of the signal description to be present when there is a trigger.
A dev can move it to duplicates if the original decision still stands.

It does.

Then why is it different for trains, and why is that by design?

[JasonC]

I then don't see a discrepancy between signal behavior along vehicles nor a violation of the signal description to be present when there is a trigger.
A dev can move it to duplicates if the original decision still stands.

I am not entirely sure what you are talking about as it is still 100% different for trains.

The behavior of an abandoned buggy is exactly as expected (red green gate status light matches sensor read output signal) and does not change the fact that the sensor output doesn't match the gate for trains.

There are no contradictions with the original report.

[Olacken]

Ok then try to put a buggy right on the edge next to the wall were the sensor is what do you read?

And now make the gate larger to put the sensor one further apart from the rail for the trains what do you read?

If you do those two test properly you will see that there is no dcrepencie between train and other vehicle

[JasonC]

Ok then try to put a buggy right on the edge next to the wall were the sensor is what do you read?

And now make the gate larger to put the sensor one further apart from the rail for the trains what do you read?

If you do those two test properly you will see that there is no dcrepencie between train and other vehicle

Yes there is. You can see it in the video and I've said it a dozen different ways now. The gate sensor output turns off for trains while the little red/green light on top of the gate is still green, and that doesn't happen with any other vehicle, no matter where you place the vehicle or what you're doing with it or if you're in it or out of it or it's on fire or whatever.

You can construct any test you want, as simple or complicated as you want, and what I just will always be the case. Period. It's no more complicated than that.

[JasonC]

I then don't see a discrepancy between signal behavior along vehicles nor a violation of the signal description to be present when there is a trigger.
A dev can move it to duplicates if the original decision still stands.

It does.

The other thing is; and correct me if I'm wrong, but the biggest use case for gate sensors at all is vehicle crossings. They aren't much useful for anything else, really... except maybe turning the lights on in your factory when you walk through the door... Maybe cool looking biter air-locks for flavor, I guess.

And since they literally behave differently for trains than for anything else, the current behavior makes that use case impossible. If they can't respond usefully to passing trains, you might as well not have the sensor outputs at all, unless there's some other awesome use for gate sensors that I'm not thinking about.

[Squelch]

I have been following this topic for a while, and find I must offer my understanding on the subject, and why I think it is incorrectly thought of as a bug.

Speaking only of gate sensors first:
Gate sensors have a detection range of 3. I'm assuming that is cells for player and non train vehicles. It would appear that the detection occurs as the velocity vector or braking distance of whatever entity is moving towards the gate is detected when it enters (or collides) with the cells in range.

For trains, it appears to be slightly different, so instead of 3 cells, it is 3 rail segments. Using the debug options, it it possible to see both the rail collision boxes, and train braking vector, and this does correlate and support my observations. Rail collision boxes have small gaps between them, so slow moving trains can cause the sensor to flicker as witnessed. It seems that the detection only occurs when a train's braking point is moving towards the gate within a collision box, and is cancelled as it slowly traverses the boundary to the next.

Gates:
Gate operation is triggered by the sensor, and opens for a default of 5 (seconds?) The gate remains open as long as another entity is moving towards it as above, or while an entity is over the gate's threshold. A fast moving train will leave the gate open for a while as witnessed, or wait until a longer train has passed. Players and vehicles cause the same behaviour, but with a finer grain than trains. (see "performance" below)

The sensor "on" time does not dictate the gate's opening time. It is merely a trigger for opening the gate. The sensor reading - and corresponding lamps - only signal the trigger, and not the gate's actual state.

Performance:
I believe that the performance issue comes down to the potential number of entities operating gates. Players and vehicles are likely to be much sparser than trains. They also move slower than trains.
Which is likely to be the more performance sapping scenario - 60 trains at high velocity operating gates, or 1-5 players at low velocity all operating gates at the same time?

Try this little contraption:
Using the save provided above. Place 3 rail signals before the gate at 1 rail segment intervals (use the slow train circuit for best effect) Place 3 lamps next to each signal and wire them so that they follow the amber output of the rail signals. Start the train and watch as the train approaches the gate. Each lamp in turn will light in turn and then the gate signal will fire. Turning on the braking point in debug settings will highlight this even more clearly.
Sorry I don't have a save or BP for you at the moment.

Gates work reasonably well out of the box. They open and close with reasonable timing that any casual player probably uses without issue. For more complex setups, combinators can be used for fine control. ie take the sensor signal and latch it until a safe reset signal is received. While gates do provide a sensor output, I do not believe it was ever intended that they be used as train detectors, or as reliable methods of fine control. For trains, rail signals are far more reliable, both with timing, and persistence of the signal.

[ptx0]

in .18.x i've made a rail grid world using johnnynof's gated city block blueprint and the performance is superb thanks to boskid's improvements to the rail pathfinder and abandoning A*.

however, the gates themselves, specifically relating to trains, have some remaining CPU issues that mean I have to get rid of them if I want to expand the base's production without dropping UPS. it's a ton of calls to request to recursively open gates. but really, I have a serious number of gates on the map and they were all circuit controlled.

you should probably check it out, it might help your design. the rail signal directly in front of the gate is forcibly closed red when a player is nearby.