User settable train tag for circuit network

[blahfasel2000]

TL;DR

Add a user settable tag/id value to trains that can be read from train stops through the circuit network.

What ?

I propose adding a numeric tag value to trains which works similar to the existing train id, but is settable by the user and remains stable through things like changing train composition, rebuilding destroyed trains etc. The value would be tied to the trains schedule, so in cases where two trains get joined the same logic that's already used to decide which schedule the new train keeps would also decide which tag value the resulting train gets. When copy+pasting settings between trains the tag would be copied over along with the train schedule and color.

When a train is connected to a train stop, the tag value of the train would be readable from the train stop through a signal on the circuit network, similar to how you can already read the train id. The signal used for the train tag would be configurable on the train stop itself, again similar to the train id.

The game itself wouldn't take any measures to keep train tags unique (in fact it can't in light of how the tag should be handled in cases of train modifications as outlined above). If a player wants unique tags, then they have to make sure of that themselves. That (and the fact that the term "train id" is already in use) is why I call it a "tag" and not an "id".

The tag value should be readable/writable for mods.

Why ?

If you want to implement special handling for specific trains at a train stop using the circuit network the only way (barring mods) to do so at the moment is by using the existing game assigned train id. The problem with that is that this train id isn't very stable. Each time something changes the train composition (parts of the train getting destroyed, replacing wagons/locomotives with upgraded modded versions, mods like Clusterio "teleporting" trains between surfaces/cluster nodes etc.) the train id changes. Each time that happens you have to manually go through all relevant train stops to update id values in the circuit network. The proposed train tag would provide a way to identify trains that would be stable over time.

In addition to that the tag could potentially also be useful for certain mods that have to keep track of specific trains (for example TSM or LTN). At the moment that's typically done through the train id as well, which leads to problems like losing track of scheduled deliveries in case something causes the train id to change. A mod wanting to track a train could set its own unique tag value on the train to identify it. Of course in case of multiple mods doing this it would be up to the user/mod authors to make sure that they don't interfere with each other (or are properly marked as incompatible).

[ssilk]

There are already ideas about this theme-block.

First I think this is already implemented with the train-id introduced in v0.15 (viewtopic.php?f=11&t=46234).

See this post, where it is explained, how that can be used to simulate “numbered tags”:
viewtopic.php?p=270930#p270930

That is a bit crappy, but it might work quite well.

If that is ever be thought to improve, I think this describes the current discussion very well:

It would be super useful like so:
Any train has in it's interface a knob. If you press the knop the interface for a constant cominator opens and you can put in ANY signal-configuration you want.
When a train comes now to a train stop he emits that configured constant combinator as signal.

Now we can enhance that: Every train-schedule-entry has also that knob and depending on the train-stop it add the signal of the train's constant combinator to that of the current stop.

Now add also copy paste of "normal" constant combinator into that of the train and vice versa.

And I a rule: Same signals will simply added together. So when coupling two trains the signal-values for two equal signals are also added.

I think the constant combinator can be read at minimum from the train-stops. When you think about it: they behave like tags with values.


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

Related:
viewtopic.php?f=6&t=47541 Signals should send Train-ID to circuit network

Related:
viewtopic.php?f=6&t=26359 Trains numbers for circuit network in v0.13
viewtopic.php?f=6&t=39002 Train-IDs for the circuit network



Edit: what I forgot is the idea, that a vehicle could have the ability to “programming it with circuits/combinators”. It needs to implement a “surface” into a vehicle. That output could be used for this, instead of a fixed combinator.

For trains this could mean: you send the train onto a schedule to grab the things from the outpost, that’s currently needed.

Quite unpolished idea till now, and I even didn’t find the source of that idea. But I wanted to mention this.

[blahfasel2000]

First I think this is already implemented with the train-id introduced in v0.15 (https://forums.factorio.com
/viewtopic.php?f=11&t=46234).

Not really, because the train id isn't particularly stable, a lot can happen that changes the train id, invalidating all circuits that rely on that id until they are updated with the new id.

That's exactly why I came up with my suggestion, as outlined in the "Why?" part of my thread opener.

See this post, where it is explained, how that can be used to simulate “numbered tags”:
viewtopic.php?p=270930#p270930

That post is also based on an assumed user-settable stable train id, not the actual game assigned unstable id.

It would be super useful like so:
Any train has in it's interface a knob. If you press the knop the interface for a constant cominator opens and you can put in ANY signal-configuration you want.

That is far wider in scope than what I have envisioned and has a lot more hard to solve implications.

And I a rule: Same signals will simply added together. So when coupling two trains the signal-values for two equal signals are also added.

That might make some small sense when you manually couple two trains together using the "G" key. However there are a lot of situations (that are a lot more likely - I'd wager a guess that a lot of players don't even know about "G"/"V", and most of those that do do so because they pressed them accidentally) of trains getting joined where summing the values wouldn't make any sense at all.

For example, you have a train that got a carriage in the middle destroyed (for example by biters). Rebuilding the destroyed carriage now joins the two halves back together, so with summing logic you'd have doubled all signal values set on the train previously. Assume an entire train got destroyed and gets rebuilt by bots. Depending on the exact order that the bots put down the replacement wagons and locomotives the resulting signal values would end up being multiplied by an essentially random factor, as the rebuilding could involve a multitude of train joining "events".

[ssilk]

Hmm. I never used that, sorry for my ignorance.

remains stable through things like changing train composition, rebuilding destroyed trains etc.

I think it’s important to know under which other circumstances the the train will loose that ID? So that we can discuss the different methods, of what should happen in which case.
E.g. What train-id should be chosen, if you join two trains?
And even with tags it would be an unsolvable problem to reproduce the state of the trains, that you split with V.

AFAIK the train-id is stored inside of the locomotive, so as long as that remains, the train will not loose the ID, even if all wagons are destroyed. So to solve that, we need to store that train-id also in the wagons. I think that’s already done with the schedule?

To the idea of using constant combinator and signal-values: yes, sorry for bringing in that idea. It has reasons. Tags - as I know them as “words” - cannot be transmitted through the circuit network in a way the player can see. So the idea of using signals, instead of tags, makes a lot of sense. But as already said: nearly everything can be achieved by have just a simple trains-id.

The idea with adding values is indeed stupid.

[blahfasel2000]

remains stable through things like changing train composition, rebuilding destroyed trains etc.

I think it’s important to know under which other circumstances the the train will loose that ID? So that we can discuss the different methods, of what should happen in which case.

Trains get a new id every time the train composition changes in any way. So for example adding a new carriage at the end of an existing train means that the train gets a new id. Remove a carriage from the end of a train and the train gets a new id. If a carriage in the middle of a train gets destroyed or deconstructed, both remaining halves of the train get a new id, no part retains the old one. If you rebuild the carriage the rejoined train gets a new id that is different from the id of any of the parts that were joined together.

E.g. What train-id should be chosen, if you join two trains?
And even with tags it would be an unsolvable problem to reproduce the state of the trains, that you split with V.

That's why I proposed to keep it with the schedule. There's already logic in place that decides which of the two schedules is kept when two trains are joined. In case of manually coupling with "G" it's the schedule of the part that the player doing the coupling is inside of. In other cases of joining trains I don't know the exact algorithm used, only that there is some algorithm in place that from my experience usually "does the right thing" (for example when adding a new waggon to the end the populated schedule from the preexisting train is used and not the empty schedule from the freshly placed waggon).

Note that even trains that consist of only wagons and don't have a locomotive can nevertheless have a schedule, there's just no way for the player to access it because the schedule GUI is part of the locomotive GUI (mods can set and modify the schedule on a locomotive-less train just fine).

AFAIK the train-id is stored inside of the locomotive, so as long as that remains, the train will not loose the ID, even if all wagons are destroyed.

The train id isn't stored associated with any particular carriage. Basically what is happening is that every time the composition changes the original train is destroyed and a completely new train with the new composition (and a new id) is created. Note that I'm not speaking of the individual carriage entities, those aren't destroyed and recreated, but the train object itself which is a separate object in the game engine.

To the idea of using constant combinator and signal-values: yes, sorry for bringing in that idea. It has reasons. Tags - as I know them as “words” - cannot be transmitted through the circuit network in a way the player can see.

I'm from a programming background, in that context tags can be anything you want, not just words.

The train tag that I'm proposing would be an integer value in order to be transmittable as a circuit network signal. As I outlined I didn't want to call it a "train id", because that name is already taken for something else in the Factorio context, also "id" usually has the connotation of being a unique value, which I specifically don't want the proposed train tag to be (because for one it would interfere with the stableness of the value in case of splitting/rejoining trains, and second there are valid use cases for non-unique tags, for example to mark not just a single but a whole group of trains for special handling). So "train tag" was the next best thing that I could come up with, but I'm open to other suggestions (aside from "train id" because of reasons mentioned above).

[ssilk]

I'm from a programming background, in that context tags can be anything you want, not just words.

Yes. But for signals - that we need to use here, because that’s how we can currently connect the train to some logic, that is able to read that - we can use only signals. And they are key-value pairs. And that’s not tags.

I would call it a map. Depends on programming language. Or we keep it to signals.

Sorry, when I’m riding too deep of that term. I now understood what you mean and currently I think I should play with that id, because it looks to me like that they took the train unique id and copied it to the train-id when it changes. Which is really a bit too simple.

[Silari]

While thinking on this it occurred to me there's a way to get this kind of functionality using what's already in the game with just a little modification: let trains output their locomotive color to the circuit network. Train colors are already in the game, use numeric values compatible with the circuit network, are user and mod viewable/settable, and are easily copied. They don't need any new logic for when a train gets joined/split/destroyed/whatever. They're also not randomly assigned - there's a default color thats used unless it was set explicitly via BP or Lua, so no need to change a bunch of station circuitry to account for every ID change like using the train ID.

Biggest advantage to doing it that way is you'd only need two changes that I can see. One is to add an option to train stations to output the locomotive color (same as the ID option already there) and possibly configure those outputs (same as configuring roboport robot stats output). By default it could output the R G B each to the red green and blue signals, and all three converted to an integer to White (so Sky Blue would be output as 8900331). Second is you'd need a methodology to figure out which locomotive's color to use, as trains can have multiple locos of multiple colors. Easy and simple option would be to start at the 'front' of the train at the station and keep going back along the train until you find a locomotive, then use that color. Nice benefit is you could potentially tell which way a double-headed train is facing based on color differences between the two locos.

Downside is you wouldn't have as wide a range of identifiers - only 3 bytes worth rather than the 4 byte integer the circuit network could use (You COULD include the Alpha value in with the color, but as that's not user viewable/settable it's probably not a good idea).You'd also need to change the loco colors to get unique values, and some people wouldn't want to change the color just to get a unique value for that train.

The fact that train color can't easily be enforced to be unique might be a downside (no event to tell if a train had it's color changed, so it'd be real difficult for a mod to enforce unique colors), but there's advantages in allowing them to be shared. If all your iron trains use the same color, it becomes VERY easy to tell if the parked train is an iron train or not, without needing to maintain a list of IDs of all your iron trains (and updating them every time one changes).

[ssilk]

I would not couple any functionality to aesthetics without need. There are players, which play around with the colors a lot.

[hreintke]

It probably is possible to keep track of changing train-id's with the use of on_train_created & entity_destoyed events.
Then a train-tag can be transferred to newly assigned trains.
If that is correct, then, with the use of on_train_state_changed and a constant-combinator the tag/signal could be send to the network.

[ssilk]

Yes, this can be made as mod relatively simple...