Don't path to train stop if its exit condition's already met

[quyxkh]

(edited because I learned current pathing just prefers to avoid currently-occupied stations, it will still go there)

Trains pathing to stations they can't do anything with feels wrong. With some limits, planning around them is interesting and feels rewarding. This one, not so much, local loops need much too much fiddling.

I think I've got a simple fix: when pathing to the next stop,if the exit condition's already met don't even consider it, and if that leaves no candidates skip the stop entirely. Don't skip stops just because they're to the same name as the current stop; a train that's got no place left to go, that's skipped every station this way, then it picks its next scheduled stop skipping duplicate stop names but not considering exit conditions, as it does currently, to keep useless trains from causing special-case problems.

Just for concreteness, say I'm trying to feed two blue belts, 3 wagons will do for that if the route doesn't take too long — which, If I've got ten outposts, it will, if the train has to hit them all. A three-wagon circuit gets a little over a minute to feed that demand, that's enough for one or two nearby-ish stops, Make it a six-wagon train, you get 2:30, that's enough to get farther out, still no way enough to do a lot of piddling or redundant stops, though.

But look at what this check-exit-conditions-first setup allows: you could have the exit condition be "full cargo or iron ore < red" and put some hysteresis in that red value, have the loaders decrement the value so the train gets all that's there if it can, resetting the value when the train does leave, so the train doesn't come back until there's enough to suit your needs is a new puzzle.

[SupplyDepoo]

How would this work with circuit network conditions?

[Deadly-Bagel]

Well it would only need to calculate this once per trip right? It arrives at a stop, then calculates the next station it needs to go to. If conditions are met it can skip stops but once it commits to a stop it needs to go there, which is all done before it leaves the station it's currently at. So it can take into consideration the signals provided to its current train stop, pick a station, then go there.

Though this might need to be an option on the train stop or wait condition? It might otherwise have unintended consequences.

[mattj256]

One of the many new features in 0.15:

"Train Station - control trains by disabling/enabling the station - IMPLEMENTED"
viewtopic.php?f=9&t=30853

Does this resolve your issue or you need something else?

[quyxkh]

I was looking at the api and my first cut is to stutter-step the train, when it changes to on_the_path switch it to manual control, when it changes to manual control if I did that go in and check all the conditions at the stops on its schedule and rename any of the ones that fail, then switch it back to automatic control and when it changes again rename all the stations back; if it changes to no_path or path_lost then skip to the next scheduled stop ... dealing with multiple trains going on_the_path in a single tick, and I wonder whether other trains repath immediately when you rename a stop, I haven't gotten that far, could be a pain.

So I don't see at the moment how disabling a stop then enabling it a tick later is going to be different than renaming it and then renaming it back a tick later. Am I missing something about this 0.15 feature? Exit conditions are schedule-specific. It seems to me this is probably a code thing, A* examines nodes nearest-first, instead of just comparing the stop names, if the stop names match then also check exit conditions, surely passing around a search-context pointer so the exit-condition checks can run the right tests and record their results, then if the A* doesn't find a path, the caller can check the well-yes-it-did-but-they-were-all-useless bit and react accordingly.

I suppose allowing trains to check circuit conditions at a stop they're not at would be maybe a bit cheaty, perhaps that was @SupplyDepoo's point, and I think I agree. you could reasonably limit this to cargo conditions, circuit condition checks could only be done locally until you research signal multiplexing, then multiplexed train stops get an id, a special multiplexed output and an id-indexed memory buffer, their inputs are only connected to their (multiplexed) outputs when id on the multiplex circuit matches the train-stop id, and the train stop's multiplex memory records the last circuit condition on the multiplex by id, so trains leaving a multiplexed train stop check circuit conditions against the remembered state for the scheduled stop's id. I think you'd need a "poll" and "ack" signal too, maybe have a poll/ack lockstep with the low bit of the id, when polling train stops with matching ids connect their inputs to their outputs next tick, when acking all train stops record the multiplexed circuit state in the id-indexed memory buffer, Controlling id sequencing on the multiplex circuit and id assignment for train stops could be the player's problem.

It's also possible I'm too new at this game and I'm missing something relatively easy, or perhaps just missing the point. I promise to be nice if somebody wants to address that possibility

[quyxkh]

Multiplex trains get an assignable (presumably virtual) signal, like a combinator operand. Maybe make ordinary trains this way, just having a signal assigned is what makes them multiplex.

Train stops get an assignable id number (technically, code number, since it's not required to be unique) that multiplex trains know about.

When a multiplex train's at a stop that's sending it signals, it regards its assigned virtual signal as the multiplex channel number signal and train stop code. It keeps stop codes for train stops matching scheduled-stop names, and any time it sees a candidate (or current) stop code on the multiplex channel signal it either re-caches the results of exit condition checks in its schedule entries for that code or just remembers the signal set to check later, same effect either way.

Exit conditions are checked against the last-known conditions when deciding whether to leave the current stop and, when leaving, when choosing a destination. Stops for which the exit conditions as of the last-seen conditions for that stop already pass aren't considered candidates; scheduled stops with no remaining candidates are skipped entirely. Multiple scheduled stops for the same name work, since the current station's exit condition's already met, it's not a candidate. If exit-condition checks eliminate all candidates from the train's entire schedule, either rerun the schedule ignoring the exit-condition prechecks or just go straight to no_schedule and let the player sort it out.