Signal on circuit network when train passes waypoint

[damerell]

You can give a train an order with no wait conditions, causing the train to pass through the station without stopping - a "waypoint".

I suggest that when the train does so, the station should, for one pulse, send a signal on the circuit network if it has the option which is now called "Read Stopped Train" set. It would obviously be desirable that this option be renamed since a train passing a waypoint is not "stopped". I suggest "Read Train Serial Number".

This would improve the utility of waypoints, allowing additional circuit network tricks in vanilla.

[boskid]

Because bug report 75143 was rejected, it is most likely that trains only path to waypoint until brake distance reaches waypoint. After this, train no longer keeps pointer to waypoint it was going through (only part being updated is path extending). In that sense, i would not expect this idea to be ever implemented.

You can use regular rail signals immediately before and after train station. If rail signal on entrance turns red then you know train passes here (not counting if it was pathing through station or if it was just lowest cost path even without given station on schedule)

[foamy]

You can give a train an order with no wait conditions, causing the train to pass through the station without stopping - a "waypoint".

I suggest that when the train does so, the station should, for one pulse, send a signal on the circuit network if it has the option which is now called "Read Stopped Train" set. It would obviously be desirable that this option be renamed since a train passing a waypoint is not "stopped". I suggest "Read Train Serial Number".

This would improve the utility of waypoints, allowing additional circuit network tricks in vanilla.

A station whistlestop reading both train ID and train contents could be very helpful for circuit network stuff, yes.

[damerell]

Because bug report 75143 was rejected, it is most likely that trains only path to waypoint until brake distance reaches waypoint. After this, train no longer keeps pointer to waypoint it was going through (only part being updated is path extending). In that sense, i would not expect this idea to be ever implemented.

It can hardly be unfeasible. The train knows where it is and what its orders are.

You can use regular rail signals immediately before and after train station. If rail signal on entrance turns red then you know train passes here (not counting if it was pathing through station or if it was just lowest cost path even without given station on schedule)

You don't know _which_ train.

Come to think of it, signals could have an option to send the ID of a train that is stopped at, or passes through, them.

[boskid]

Come to think of it, signals could have an option to send the ID of a train that is stopped at, or passes through, them.

Train station to output signal must be first informed that train stopped. Because waypoints are implemented so train does not slow down, this means after braking point reaches waypoint, it is silently passed while train still not yet reached that station.

Adding extra code so train while moving would trigger all passed stations to output for one tick is possible (if head of train moves out of rail segment that contains train station registered on its end, tell train station to output for 1 tick particular train ID). For performance reason this would most likely be not limited to cases where train station was a waypoint because train may have waypoint on its schedule somewhere but not doing it while going in between stations A and B (only when going B->waypoint->A).

Another quite easy solution would be to change rail signals so they would be able to give back trainID of train for which block is reserved(yellow signal, first reservation on list) or trainID of train currently within block (red signal) (assuming there are no 2 trains in one block)

[Tekky]

I am against the suggestion. In my opinion, there are better suggestions for the circuit network to receive information from trains.

For example, in this thread, it has been suggested that the Train ID and other signals the train sends should be user-definable. Later in that thread, someone suggested that the signals the train sends should change according to the train's current orders (e.g. when it passes a waypoint).

Also, in this thread, I suggested that track signals should be connectable to the circuit network and provide the Train-ID of the train currently in its track segment. Later in that thread, I suggested that it should also be possible to read the cargo contents of the train instead of only the Train-ID.

If these two suggestions were combined, I believe it would make the suggestion made in the current thread redundant.

As a side note, I would also like to point out that In the following threads, it has been suggested that a wireless circuit network be implemented:

viewtopic.php?f=6&t=49317 Radio Links for signals transmission
viewtopic.php?f=6&t=47429 global circuit network
viewtopic.php?f=6&t=12652 Connection of circuit network over distances
viewtopic.php?f=6&t=51811 "Pipboy" for wireless network/circuit manipulation
viewtopic.php?f=6&t=62384 Logistic circuit signals through radars

If it were possible to also connect trains to this wireless circuit network, and, if as mentioned above, it were possible for trains to send a different signal based upon their current order, then connecting track-side signals (or stations) to the circuit network in order to determine whether a train has passed a waypoint may also become redundant, depending on your play style.

[damerell]

I am against the suggestion. In my opinion, there are better suggestions for the circuit network to receive information from trains.

I agree if these were implemented they would eliminate the need for what I suggest, but they also are more complex; it might be more practical to implement what I suggest.

[Squelch]

I have felt for a long time that signals should return the (first) train in a block. As present, or reserved. A simple presence signal based on the real world CBTC system

This would enable a player to force a route of a particular train using the circuit network and signals.

Only the train ID is required in my opinion. The cargo manifest should be left for the player to resolve, and can already be done when a train is at a station along with the ID. If there are more than one train in a block, I would consider this illegal, and brings problems that the player must already resolve. I would also suspect that attempting to send complete manifests together with the train ID could bring an adverse performance impact.

There have been many attempts at making a vanilla train logistics network by various players. Many use the duplicate station name system to aid multi drop situations. I too have tried to work around this missing feature by first registering the train ID, and then counting trains in sections along the route to identify the current location between the start and the destination. This becomes highly complex, and suffers badly at multiple way junctions, the use of chain signals, and it also scales badly. The alternative is to use the existing Station node ID output as waypoint stations that the train must stop at so it can register the ID. This is also very cumbersome.

The suggestion has already been made above. So to summarise:

A simple addition of Train ID in, or having reserved the block, to the existing Rail Signal item output of Signal color attributes.

[Edited for layout/comprehension]