Train Labels

[AntiBlueQuirk]

TL;DR

Similar to my other idea, I think trains should have labels. Or to put it another way, trains should have a built in constant combinator, accessed by train stops.

What ?

Trains should have a slot in their UI where you can select an arbitrary item stack. This would work exactly like selecting items in filter inserters or constant combinators. This label could be displayed in various places: on the train in alt-view, on the train on the map, and beside the name in the train UI.

There's also another utility for this. Right now, you can get train stops to read the "unique id" of a stopped train. The train stop would also have an option to read the train labels and output the label as a signal like the constant combinator.

Why ?

This would make identifying trains at a glance easier than ever, especially in cluttered areas and UIs. (The train UI can get ridiculous pretty fast, and trains are pretty unidentifiable on the map.)

Getting train ids is useful, and has purpose, but sometimes you don't actually care about which particular train is stopped, but what kind of train is stopped. Reading the train inventory doesn't work if the train is empty. You can map train ids to train types through circuits, but this is kludgey, and prone to breakage when train ids change, or you make new trains. Reading train labels would provide a simple and elegant solution to this, and provides interesting opportunities for station design.

[Deadly-Bagel]

Yeah publishing the train ID was only a half fix, was supposed to allow you to detect a train is at the station rather than to identify the train. I mean if you modify or rebuild the train you'd need to go around each stop and reconfigure its id, blegh. Would be better if the ID could be edited, even made non-unique, but the best solution would be to just allow us to set a signal.

[mrvn]

Picking an item to show as train label would be far simpler than picking a color. It's hard to make train colors looks like e.g. iron ore or iron plate but still see the difference at a glance. With an iron ore or iron plate icon it would be obvious which of the two the train is.

[evildogbot100]

This is a good QOL suggestion. If the devs read this, I can't see why it shouldn't be implemented.

[Engimage]

Interesting proposal.
While train ID is pretty useful and could be used all around if made more visualized all around I think pickable label is a nice thing.

To extend this idea I would propose to have the functionality of a constant combinator built into the train. So you can pick a signal (label) and a number. This will allow visualization, identification and grouping trains based on their signals like Iron Ore trains etc with the actual signal value being used for different purposes - from identification to something like requested amount of cargo.

And you can certainly use the signal to add icon on both real world view in Alt mode and to map view, optionally adding the value of the signal in brackets. Would be awesome I think.

[mrvn]

Interesting proposal.
While train ID is pretty useful and could be used all around if made more visualized all around I think pickable label is a nice thing.

To extend this idea I would propose to have the functionality of a constant combinator built into the train. So you can pick a signal (label) and a number. This will allow visualization, identification and grouping trains based on their signals like Iron Ore trains etc with the actual signal value being used for different purposes - from identification to something like requested amount of cargo.

And you can certainly use the signal to add icon on both real world view in Alt mode and to map view, optionally adding the value of the signal in brackets. Would be awesome I think.

This would also allow using multiple icons per train, say one per car. So you can label a train "Iron ore, Iron ore" to say it has 2 cars of the stuff.
Or you use the item count as bitfield to say which car contains what. So an "Iron ore 5, Copper ore 2" train would hold iron ore in the first and third car and copper ore in the second. This could be used to program filter inserters at the train stop.

[Factoruser]

Trains should be able to send a distinct circuit signal, that is combined with their cargo signals. This should also replace the train ID resp. the default signal is the train ID (signal T, value = ID). Therefore the train's interface would be enhanced, and the stations stop's interface gets reduced (only the "read train" checkbox, no longer selection of the signal).

- The train's names may further get changeable, because you're losing sometimes the overview of what purpose each train has. You might give them descriptive names then.

There are also some issues... the train's signals aren't available when the train stops. So the inserters start working, before the cargo information is available. This could be avoided of course if you connect the inserters with a signal from the train, that appears together with the cargo information. But the inserters are also dropping items in their hands, even if "disabled". A train shouldn't never be filled if the train stop conditions are not met, e.g.: "wait until cargo iron plate > 900" and the cargo has 901 iron plates, the train should pass the station without activating the inserters in any way. The train should even further omit a station if the "wait until" condition is true...

[mrvn]

I like the train stop sending a constant signal when a train, any train, is there. I think that should stay in parallel to the train sending signals.You can use one or the other or both.

[Tekky]

I also support this idea. It has already been suggested several months ago in the following threads:

viewtopic.php?f=6&t=46969 Constant Combinator for Locomotive
viewtopic.php?f=6&t=47747 Train names

[Factoruser]

I like the train stop sending a constant signal when a train, any train, is there. I think that should stay in parallel to the train sending signals. You can use one or the other or both.

It's not necessary. First, every train would send the signal "T=<ID>" if the player doesn't remove it. Second, if the locomotive's fuel is counted - and it should be - testing for "anything" can show you a train stops at the train stop.

[mrvn]

I like the train stop sending a constant signal when a train, any train, is there. I think that should stay in parallel to the train sending signals. You can use one or the other or both.

It's not necessary. First, every train would send the signal "T=<ID>" if the player doesn't remove it. Second, if the locomotive's fuel is counted - and it should be - testing for "anything" can show you a train stops at the train stop.

That's not how I read the proposal. If the train has (is?) a constant combinator it would only send the signals the user puts in it. But however you get the T=<ID> signals is fine with me. Just seems more logical to have train stops determine weather that signal is used or not and not the train. Think of one train stop using T=<ID> and another S=<ID>. How will you configure the train then?

[Factoruser]

I like the train stop sending a constant signal when a train, any train, is there. I think that should stay in parallel to the train sending signals. You can use one or the other or both.

It's not necessary. First, every train would send the signal "T=<ID>" if the player doesn't remove it. Second, if the locomotive's fuel is counted - and it should be - testing for "anything" can show you a train stops at the train stop.

That's not how I read the proposal. If the train has (is?) a constant combinator it would only send the signals the user puts in it.

You also get the train's cargo signals, resp. additionally.

But however you get the T=<ID> signals is fine with me. Just seems more logical to have train stops determine weather that signal is used or not and not the train. Think of one train stop using T=<ID> and another S=<ID>. How will you configure the train then?

This is the decision of the player. E.g. to change the default signal for train IDs. And one signal would be enough for all uses. Some might use the train ID, even several times the same, others letters or colour signals.

The current solution is worse because you can't change the train's IDs for example. - I even dunno already where you can figure out which ID a train has. But it's useless anyway, because if I want e.g. some trains to load coal at a distinct station, I could only use it if I check whether the signal T is e.g. between 10 and 20, but I can't assign trains to that range. On the other hand I can't check with acceptable effort that train 4, 9 or 13 is currently in the station.

Okay, my "circuit control unit" would solve it:
viewtopic.php?f=6&t=52072

[mrvn]

But however you get the T=<ID> signals is fine with me. Just seems more logical to have train stops determine weather that signal is used or not and not the train. Think of one train stop using T=<ID> and another S=<ID>. How will you configure the train then?

This is the decision of the player. E.g. to change the default signal for train IDs. And one signal would be enough for all uses. Some might use the train ID, even several times the same, others letters or colour signals.

That's not what I ment. Say you have 2 train stops. One train stop is using the T=<ID> signal that would be default while the other uses S=<ID>. For example because you want both signals on a single wire so somewhere else you can check if both stations have a train.

But how would you configure the trains when they decide what signal so send? You would need all trains to send T=<ID> and then add an extra combinator for S=T+0 at one station.

[Factoruser]

Say you have 2 train stops. One train stop is using the T=<ID> signal that would be default while the other uses S=<ID>. For example because you want both signals on a single wire so somewhere else you can check if both stations have a train.

But how would you configure the trains when they decide what signal so send? You would need all trains to send T=<ID> and then add an extra combinator for S=T+0 at one station.

Trains won't decide what signal to send, they send a distinct signal, which is specified by the player, e.g. always T=13 or Red=1, etc.

If you want to check whether two trains are in two distinct stations, you'll have to use combinators, one checking for T=13, the other for T=11 e.g. and creating new signals in case. You may also have a combinator at one station that sends the signal S with the value of T into the network. It's depending on the player what signals he wants to use and how. He may use e.g. also "I" for trains that should load and deliver iron plates instead of using train IDs. But using different signals for the train's IDs makes no sense.

[mrvn]

Say you have 2 train stops. One train stop is using the T=<ID> signal that would be default while the other uses S=<ID>. For example because you want both signals on a single wire so somewhere else you can check if both stations have a train.

But how would you configure the trains when they decide what signal so send? You would need all trains to send T=<ID> and then add an extra combinator for S=T+0 at one station.

Trains won't decide what signal to send, they send a distinct signal, which is specified by the player, e.g. always T=13 or Red=1, etc.

If you want to check whether two trains are in two distinct stations, you'll have to use combinators, one checking for T=13, the other for T=11 e.g. and creating new signals in case. You may also have a combinator at one station that sends the signal S with the value of T into the network. It's depending on the player what signals he wants to use and how. He may use e.g. also "I" for trains that should load and deliver iron plates instead of using train IDs. But using different signals for the train's IDs makes no sense.

Yes, but at the moment I don't need the extra combinator since I select the signal at the station, not the train. A depot for 8 trains would now need 7 extra combinators to get the old behaviour.

And a train stop that disables itself when a train is present would now need to check for T or S or I or whatever any train uses that might stop at the station. Think of a refueling station. It might have to check dozens of signals now to see if a train is present.

So all I'm saying is that the T=<ID> in the train stop is very useful and should probably stay. What is the harm of leaving it as is while doing whatever you want to the trains?

[Factoruser]

Yes, but at the moment I don't need the extra combinator since I select the signal at the station, not the train. A depot for 8 trains would now need 7 extra combinators to get the old behaviour.

Where I don't get how and for what this should be good for.

And a train stop that disables itself when a train is present would now need to check for T or S or I or whatever any train uses that might stop at the station. Think of a refueling station. It might have to check dozens of signals now to see if a train is present.

It has not. First of all, inserters are putting in the fuel automatically, this is even a problem because they do so before the train's cargo is available to the network. (Example: iron plates < 900 alone; the inserters will operate a few ticks until the network has the information iron plates > 900. You might put a piece of copper wire in the cargo and check for it to activate the inserters, but this could also be better done with a signal like "I")

And if you want to know whether a train is present, you'll just have to check the "Anything" signal. It should also count the locomotives' fuel. The train has to become completely empty that this won't work and locomotives without fuel are not very desirable.

So all I'm saying is that the T=<ID> in the train stop is very useful and should probably stay. What is the harm of leaving it as is while doing whatever you want to the trains?

I think it's redundant. Of course it would be easier just to add signals to the trains and leave the train stops as they are. But if you want to avoid any confusing behaviour, a train stop would have to check and take the T signal of a train as train ID then.

[mrvn]

Yes, but at the moment I don't need the extra combinator since I select the signal at the station, not the train. A depot for 8 trains would now need 7 extra combinators to get the old behaviour.

Where I don't get how and for what this should be good for.

And a train stop that disables itself when a train is present would now need to check for T or S or I or whatever any train uses that might stop at the station. Think of a refueling station. It might have to check dozens of signals now to see if a train is present.

It has not. First of all, inserters are putting in the fuel automatically, this is even a problem because they do so before the train's cargo is available to the network. (Example: iron plates < 900 alone; the inserters will operate a few ticks until the network has the information iron plates > 900. You might put a piece of copper wire in the cargo and check for it to activate the inserters, but this could also be better done with a signal like "I")

And if you want to know whether a train is present, you'll just have to check the "Anything" signal. It should also count the locomotives' fuel. The train has to become completely empty that this won't work and locomotives without fuel are not very desirable.

So all I'm saying is that the T=<ID> in the train stop is very useful and should probably stay. What is the harm of leaving it as is while doing whatever you want to the trains?

I think it's redundant. Of course it would be easier just to add signals to the trains and leave the train stops as they are. But if you want to avoid any confusing behaviour, a train stop would have to check and take the T signal of a train as train ID then.

A train stop that disables itself is for example one that reads the train signal, that goes into a decider combinator with T=0 ==> Green=1 and then back into the trains stop, which enables when Green > 0. If you have multiple station with the same name then it makes sense to disable the station if a train is blocking it so all other trains will pick one of the alternative stations. Otherwise they will stay before a red signal for quite a while and block traffic before the decide to try another station (if at all).

I guess checking the anything signal would work, but not as you describe. As is a locomotive doesn't output it's fuel so an empty train does not output anything. Electic trains also wouldn't output any fuel even if that is added. But with your suggestion it would output it's train ID (when enabled). So Anything would trigger on the train ID no matter what signal was used. I guess that works.

[Factoruser]

A train stop that disables itself is for example one that reads the train signal, that goes into a decider combinator with T=0 ==> Green=1 and then back into the trains stop, which enables when Green > 0. If you have multiple station with the same name then it makes sense to disable the station if a train is blocking it so all other trains will pick one of the alternative stations.

I thought trains already pick automatically the next available train stop with the right name...?

Further detecting a train could also be done by reading the signals - just whether a train is in the train stop's signal block, not if it's holding at the train stop.

As is a locomotive doesn't output it's fuel so an empty train does not output anything. Electic trains also wouldn't output any fuel even if that is added.

All you have to do is to ensure a signal for your trains, as default they'd send T with the train's ID value.

[mrvn]

A train stop that disables itself is for example one that reads the train signal, that goes into a decider combinator with T=0 ==> Green=1 and then back into the trains stop, which enables when Green > 0. If you have multiple station with the same name then it makes sense to disable the station if a train is blocking it so all other trains will pick one of the alternative stations.

I thought trains already pick automatically the next available train stop with the right name...?

They do, eventually, if they are stoped at a red signal. When disabling a station all trains going there re-path right that tick. So you gon't get trains stopped at a signal thinking to themself "shall I go somewhere else? shall I? shall I?" and blocking everything behind them.

[Drury]

Let me just voice my support for this real quick. Having an entire constant combinator interface in a train would be nice, but really even just one slot would do. I'd be perfectly fine if the train ID reading got removed entirely in favor of this.

Currently my workaround is to tell trains to leave an unloading station with a bit of cargo left, which is used for identification purposes at universal loading stations. It's a bit wonky to say the least.