Rationale:
Both CyberSyn and LTN use "temporary rail stops" to direct trains to a specific train stop because the station attribute only accepts a station name which is ambiguous if multiple stations with the same name exist. However, it is possible to pass in a LuaEntity representing a rail as the "rail" attribute.
I am suggesting to implement allowing a LuaEntity to be passed in as the "station" attribute which would make these workarounds go away. The LuaTrain object already has a station attribute that returns a LuaEntity
Suggested API changes:
ScheduleRecord would get a new attribute, e.g. "station_entity LuaEntity?" to read back the LuaEntity. This can be nil if only a station name was set. If 2.1 is still considered unstable, the return type of "station" could be changed to LuaEntity? and a new attribute station_name that returns string? could be added. This would then align with both LuaTrain and TrainStopFilter
TrainStopFilter could get a new attribute "station" which would filter by LuaEntity or array[LuaEntity]?
(I am leaving WaitCondition / BlueprintScheduleRecord alone as those are more important for player interaction; the API changes above would benefit mods that implement automatic train scheduling)
Suggested Behavior changes:
It is also possible today to add station names to the schedule that do not exist / exist on a different surface. This is not possible for rails (specifying a rail LuaEntity in rail = that is not on the same surface results in an error). It should be possible for both rails and the suggested station LuaEntity elements to add ScheduleRecords where the entities are on a different surface. This will allow mods to "send" trains between surfaces without all the workarounds/kludges needed today to manage the schedule. If a station / rail is not reachable in the schedule, the train should should show a "no path" error as it does today for a station name that exists but is not on the same surface.
With 2.1 slowly stabilizing, this would be a great time to implement this before a first stable release.
[2.1.14] Allow train stop LuaEntity when adding a record to LuaSchedule
Re: [2.1.14] Allow train stop LuaEntity when adding a record to LuaSchedule
What is the primary goal for having this feature? I thought that having rail + rail_direction is enough to precisely select a specific spot a train should go to. If a train stop was selected as a station, text visible to a player would have to be adjusted to show something like "Iron ore pickup at [X, Y]" to disambiguate it is not referring to any station under that name but to a specific one at specific position, and would have to possibly be a clicky thing. If that specific train stop was renamed, the schedule record would keep pointing at the same train stop which means the station name shown in the schedule would change and if that train stop was destroyed the schedule record would become invalid (no option to rewiring it into generic schedule record)
Re: [2.1.14] Allow train stop LuaEntity when adding a record to LuaSchedule
Hi,
Thanks for the quick reply. Primary motivator is that currently, you need to maintain "stop tuples" (one is the name of the stop, another is the temporary "here is a rail and direction") which makes for a lot of complexity especially when it comes to other mods inspecting and potentially modifying the schedule.
You raise good points. If a schedule would contain a "xyz stop at (x, y)" and the user would rename the stop, this should not matter IMHO as the train was sent to that specific stop entity independent of the name. Deleting the train stop while it is in the schedule would lead to the same situation as if you have a specific train stop name in the schedule and delete the last stop with that name. The schedule becomes invalid (red) and the train shows "no path".
I would not expect a player to direct a train to a specific stop (the GUI would be unchanged and still only support station names, same as today), this is an API addition for mods like LTN or CyberSyn.
If this is not feasible, how about loosening up the "rail must be on the same surface" restriction? As the rail stop is defined by an entity, being on a different surface, getting a "no path" would be fine, it would be up to a mod modifying the schedule (e.g. the Space Exploration Space Elevator) to move a train from one surface to another.
Thanks for the quick reply. Primary motivator is that currently, you need to maintain "stop tuples" (one is the name of the stop, another is the temporary "here is a rail and direction") which makes for a lot of complexity especially when it comes to other mods inspecting and potentially modifying the schedule.
You raise good points. If a schedule would contain a "xyz stop at (x, y)" and the user would rename the stop, this should not matter IMHO as the train was sent to that specific stop entity independent of the name. Deleting the train stop while it is in the schedule would lead to the same situation as if you have a specific train stop name in the schedule and delete the last stop with that name. The schedule becomes invalid (red) and the train shows "no path".
I would not expect a player to direct a train to a specific stop (the GUI would be unchanged and still only support station names, same as today), this is an API addition for mods like LTN or CyberSyn.
If this is not feasible, how about loosening up the "rail must be on the same surface" restriction? As the rail stop is defined by an entity, being on a different surface, getting a "no path" would be fine, it would be up to a mod modifying the schedule (e.g. the Space Exploration Space Elevator) to move a train from one surface to another.