Selective Station Enabling

[MrGrim]

I've looked through the following threads, but I did not see this particular idea in them:

viewtopic.php?f=80&t=21899
viewtopic.php?f=80&t=30189

Many ideas center on controlling the train and have various implementation complications, but there's an idea I've seen outside these forums that I think would be very simple for the developers to add and open up a lot of possibilities for more advanced vanilla train control.

Simply put, allow the existing circuit condition used to enable a station to specify a train ID. Only that train will see the station as enabled.

That's it. I'm hoping it's so simple it could sneak its way into 0.17. Additionally, a special color for the station label on the map could be used when a station has been selectively enabled; perhaps yellow?

[Tekky]

Instead of allowing the station to specify a specific Train ID, I think a more flexible solution would be the ability to set conditional orders on the train itself. This has been suggested in the following threads:

viewtopic.php?f=6&t=49214 Train Entry-Condition
viewtopic.php?f=6&t=25944 Train station skipping conditions
viewtopic.php?f=6&t=58057 Trains ignore stop if wait condition already met
viewtopic.php?f=6&t=59378 Train-side stop disabling and a toggle for station skipping
viewtopic.php?f=6&t=58646 Jump on train automation

[MrGrim]

Perhaps, but I'm trying to keep two things in mind.

First, any new mechanic should be as simple and generic as possible if it's likely to be accepted and implemented at all. This capability is generic enough that it can be used to implement all of those other suggestions, and many more. A generic and simple tool that can be used to solve problems known and unknown is more useful than a single purpose tool designed to solve a single problem.

The second is I wanted to keep it simple enough that it has a prayer of being included in 0.17. I don't have access to the code, but this specific capability I think has a good chance of being a very simple and low risk addition. Maybe it's even simple and low risk enough to find its way into a point release just like the ability to read train ID's in the first place was?

[Sad_Brother]

Simply put, allow the existing circuit condition used to enable a station to specify a train ID. Only that train will see the station as enabled.

That's it. I'm hoping it's so simple it could sneak its way into 0.17. Additionally, a special color for the station label on the map could be used when a station has been selectively enabled; perhaps yellow?

Train ID is not the best thing to control.
I think other suggestions are better.

[Tekky]

Train ID is not the best thing to control.

That can be changed. This has been discussed in the following threads:

viewtopic.php?f=6&t=46969 Constant Combinator for Locomotive
viewtopic.php?f=6&t=56302 Train ID as Constant Combinator

[Sad_Brother]

viewtopic.php?f=6&t=46969 Constant Combinator for Locomotive
viewtopic.php?f=6&t=56302 Train ID as Constant Combinator

I can agree with each and even hard to see difference, but still this suggestion is not good for me.
Station should not change status based on train properties somewhere.

Instead of allowing the station to specify a specific Train ID, I think a more flexible solution would be the ability to set conditional orders on the train itself. This has been suggested in the following threads:

That way is better.

[MrGrim]

Instead of allowing the station to specify a specific Train ID, I think a more flexible solution would be the ability to set conditional orders on the train itself. This has been suggested in the following threads:

That way is better.

The problem with this is that you are limited to whatever conditional orders the devs think to add to the scheduling system. With my suggestion you are only limited by what you can do with the circuit network, which is practically without limit.

[slippycheeze]

Instead of allowing the station to specify a specific Train ID, I think a more flexible solution would be the ability to set conditional orders on the train itself. This has been suggested in the following threads:

That way is better.

The problem with this is that you are limited to whatever conditional orders the devs think to add to the scheduling system. With my suggestion you are only limited by what you can do with the circuit network, which is practically without limit.

Yes. The fact that LTN, TSM, Helmod's thing, and at least two other completely different ways to solve this in mods exist means, I believe, that we have concrete proof that there is no "one way" to do things.

Adding this to the base game would create the one way, and then anything else would either wither away, or would have to struggle to integrate with or replace the core version.

Better, I think, to leave this is the hands of mods, or to add the smallest possible "parts you can put together to build a train controller" into core, and let mods innovate with it. (eg: what the API for pathfinding did for AAI programmable vehicles.)

[Sad_Brother]

Instead of allowing the station to specify a specific Train ID, I think a more flexible solution would be the ability to set conditional orders on the train itself. This has been suggested in the following threads:

That way is better.

The problem with this is that you are limited to whatever conditional orders the devs think to add to the scheduling system. With my suggestion you are only limited by what you can do with the circuit network, which is practically without limit.

The problem with your suggestion is single train limit per station controlled. I do not think numerical train ID management is good idea.

Best wishes.

[MrGrim]

... or to add the smallest possible "parts you can put together to build a train controller" into core ...

That is essentially my argument. The problem with other suggestions, and even with mine, tbh, is the approach is backwards. It's "I have a problem here is a solution" rather than "here is a generic capability, what new opportunities does it open up and what problems can be solved with it?"

I feel that to get the devs to consider anything added into vanilla it can't just be a ham fisted "this is for train controllers" thing.

The problem with your suggestion is single train limit per station controlled. I do not think numerical train ID management is good idea.

Best wishes.

And this is the fundamental flaw with my idea.

Tho numerical train ID management itself is fine. Ideally we'd get to select the signal and value the train would send, like a mobile constant combinator.

[Tekky]

Ideally we'd get to select the signal and value the train would send, like a mobile constant combinator.

Wireless certain networks (which trains could also use) have been suggested in the following threads:

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

[slippycheeze]

The problem with your suggestion is single train limit per station controlled. I do not think numerical train ID management is good idea.

And this is the fundamental flaw with my idea.
Tho numerical train ID management itself is fine. Ideally we'd get to select the signal and value the train would send, like a mobile constant combinator.

Eh, the existing ID value would probably be fine. Until it changed because someone changed the wagon layout, anyway.

I ... think Sad_Brother is right that numeric train ID management is terrible, but then, I think that *all* the places in Factorio, and Factorio mods that use numeric identifiers for things are a terrible idea. Nothing beats out the usability of 17 to tell you exactly what that means, right? /sarcasm. It'd fit in with the rest of the game, though, since you don't get translation tables pretty much anywhere.

The "mobile constant combinator" version has a problem, though: what happens when I command train "1", having given ten trains the number "1" in their constant combinator? (or signal-red with value 1, or whatever duplication in the context of things you can do with human-assigned values in a constant combinator.)