train stop id and TrainScheduleRedord.targetid

[rldml]

Give every train stop an unique ID (like you do it already with trains) and add an attribute to the Class TrainScheduleRecord: targetid.

If the targetid of the next TrainScheduleRecord is set, the method LuaTrain.recalculate_path() has to prioritize the corresponding train stop with the unique id as his target train stop.

Global rule: TrainScheduleRecord.targetid > TrainScheduleRedord.station

If targetid is set and the corresponding train stop doesn't exist anymore, the train behavior should look similar to a train, that can't find a train stop by its name.

The positive effect would be, that we can write specific mods to make train scheduling more dynamic and easier than it is handled now.

Greetings Ronny

[Godmave]

As a LuaEntitiy the train-stop already got an unique id in the unit_number.

[rldml]

Nice!

That means, we only need the extension of TrainScheduleRecord and of LuaTrain.recalculate_path()

Greetings, Ronny

[Rseding91]

I'm not strictly against the idea but this needs to be thought out more.

What happens once the train reaches the destination?
what happens if there is no path to the destination stop? Should it say "no path" or should it just pick another stop?
How would this information be conveyed to the player in the GUI that the train is preferring a specific stop over "any"?
Should it be copied when the player does copy-paste across trains?

[rldml]

I'm not strictly against the idea but this needs to be thought out more.

What happens once the train reaches the destination?

Just as it is right now: the train checks and wait for the wait conditions of his actual TrainScheduleRecord and after that it targets the next station in his TrainSchedule-Array. The existing id remains in the TrainScheduleRecord until it was changed through a user or any other entity in the game (like the modder coded it how it can change)

what happens if there is no path to the destination stop? Should it say "no path" or should it just pick another stop?

Exactly the same behavior as the train actually shows, if we work with unique stationnames as targets. If the "targetid" is set with any other value than "0" or "notdefined", the stationname should be completly ignored in this TrainScheduleRecord.

How would this information be conveyed to the player in the GUI that the train is preferring a specific stop over "any"?

Absolute Minimum

Since this is a modding-interface-request for make more possibilities to influence trains easier ingame, the GUI-part is a task for the modder who using this extensions.

Relative Minium

Advance the GUI like this:

NOW
myCustomStationName
mySecondCustomStationName
myThirdCustomStationName
...

FUTURE
by-name: myCustomStationName
by-id: specificIDHere (mySecondCustomStationName)
by-name: myThirdCustomStationName


ALTERNATIVE FUTURE
myCustomStationName
specific mySecondCustomStationName (klick to see which one)
myThirdCustomStationName
...

Optimum IMHO

See Relative Minimum +

- Advance the GUI of the train stop-entity with an option to read out his id and send it over circuit network
- Advance the GUI of the locomotive-entity to allow to make a TrainScheduleRecord, that uses an incoming virtual signal it receives at the moment it wants to leave the previous train stop. If the signal is missing, the old id remains as target. If the train never got any fitting virtual signal, it uses "0" (or "notdefined", whatever suits better to the internal factorio logic)
- Additional Option: Advance the GUI of the locomotive-entity to allow to make a TrainScheduleRecord with a manual entered number as targetid instead of a stationname.

Should it be copied when the player does copy-paste across trains?

yes.

In the moment you start doing TrainScheduleRecord-Logic based on train stop ids you're agree to the fact, that it can mess up your complete train network. It is the part, where train stuff can become complex - like an x-to-y-beltbalancer compared to a simple 2x2-balancer. That's why it should be optional completly

It could be the main argument to leave the usage of this extensions within a mod, because (in the view of a player) there could happen really confusing stuff through this

edit: I clarified some stuff in this post...