Regarding the last FFFs about trains

[Calid]

Regarding the last FFFs about trains, i have some concerns about the upcoming changes.

I think that using station names for game logic it hacky. It feels like trying to anticipate some specific user stories and cover these exact scenarios by implementing legalized workarounds. I don't think it will be beneficial long term as there will always be some unforeseen scenarios.

It might be better to revisit the train system as a whole. Each station should have a wide exposed variety of properties: immutable unique id, name, resource types to import or export, current stockpile, target stockpile, priority as a provider AND as a requester (two distinct values), train limit and allowed composition, and user defined tags. Some of them configurable with GUI, signals, or both. Then provide access to these fields to schedule conditions.

Stations in the schedule should be defined by an ID, not a name (obviously, represented by a name in GUI), so you can safely rename a station without compromising existing schedules (name is supposed to be just a label, after all).

I also don't understand the necessity of BOTH ordinary schedules and interrupts. Just the idea of "If Condition then Go to" is enough. Just evaluate that list from top to bottom each time a train departs a station. If you need to force specific order of stations, just add "current_station" to the list of the available conditions. It may even be a default condition for a newly added station to the schedule, so those who don't want to bother with train logic, won't have to.

Example of a very simple schedule:
0. If fuel < 200MJ
+ Go to station with id:0 ("Refuel")
+ Wait until fuel >= 1000MJ
1. If cargo is empty
+ Go to station with id:1 ("Iron Ore load")
+ Wait until cargo full
2. If iron_ore > 0
+ Go to station with id:2 ("Iron Ore drop off")
+ Wait until cargo empty
3. Else (No condition) // if no condition was satisfied or corresponding station was unavailable
+ Go to station with id:3 ("Depot")
+ Wait until target_station is not id:3 ("Depot") // so the train will not circle back to this station every time schedule is evaluated

Example of a generic schedule (Refuel and depot omitted for brevity)
0. If cargo is empty
+ Go to station with any_item in exports // generic signal from the latest FFF. Train will travel to any station which has at least one signal in exports
+ Wait until cargo full
1. If any_item in cargo > 0 // any_item is evaluated to the first item which passes the condition
+ Go to station with any_item in imports
+ Wait until cargo empty

Then you can do pretty much everything with your trains. You can optimize them in a way that train fills from multiple providers and delivers to different drop offs. After that it is just about exposing additional properties of a station for the conditions to make the system more robust.

[FuryoftheStars]

Re: the use of station names, as other discussions were suggesting in that thread: tags.

[Qon]

I think that using station names for game logic it hacky. It feels like trying to anticipate some specific user stories and cover these exact scenarios by implementing legalized workarounds. I don't think it will be beneficial long term as there will always be some unforeseen scenarios.

It might be better to revisit the train system as a whole. Each station should have a wide exposed variety of properties: immutable unique id, name, resource types to import or export, current stockpile, target stockpile, priority as a provider AND as a requester (two distinct values), train limit and allowed composition, and user defined tags. Some of them configurable with GUI, signals, or both. Then provide access to these fields to schedule conditions.

I like the changes for trains up to latest FFF 395, but I agree that they don't go far enough. I think rethinking it from first principles is a good idea and your suggestions are a good step in that direction, with some minor points you got wrong but could be fixed.

You said distinct values for "provider" and "requester". So these are priorities for kinds of trains, not for the stop which has exit and enter priority at same value. But stops being both providers and requesters seems rare. A more common and actually wanted scenario think is using same stop for different products, but all requests and maybe provides. But then priorities for each signal type would make more sense. Though the system would get a bit messy if it then also needed separate cabling for just priority. Also, a stop that has a train can't receive a train, so exit priority needs to be high if it has high enter priority. Not sure yet how a system of multiple values for requests and provides of many different products but still also having same enter/exit priority would work out... So maybe this is trying to make the priority system to advanced with no real practical purpose because it is contradictory.

Stations in the schedule should be defined by an ID, not a name (obviously, represented by a name in GUI), so you can safely rename a station without compromising existing schedules (name is supposed to be just a label, after all).

Wrong. ID's are unique, which means you would need an interrupt for each station with the same name if we switched to forcing ID's everywhere. This is just makes it annoying to deal with. Don't force ID's. But having them as an option is good.

Using names is good because it is a simple way to specify and group stops. Names shouldn't become just a visual thing because then they would be quite pointless and people would probably not name stops at all, ending up trapping themselves in an unorganized mess.

Instead, fix the drawbacks of names. Maybe allow stops to have multiple names, unless the tag system is made into a better solution. And tags would have the same issue when they are changed as names. So just fix that, make changing names/tags of stops give you the option of updating schedules instead of forcing it. Sometimes it's the behavior I want, sometimes not.

I also don't understand the necessity of BOTH ordinary schedules and interrupts. Just the idea of "If Condition then Go to" is enough. Just evaluate that list from top to bottom each time a train departs a station. If you need to force specific order of stations, just add "current_station" to the list of the available conditions. It may even be a default condition for a newly added station to the schedule, so those who don't want to bother with train logic, won't have to.

Regular schedules are less hassle to set up and read. Re-ordering interrupts doesn't work even if you make them "schedule-like", since they already have a bound "current_station == X" condition. Seems like you are trying to reduce features to make it simpler, but actually end up making it less simple to work with. And sure a GUI could be made so that interrupts with "current_station == X" show up in a list like schedules do now so that reordering them works like it does now and "current_station == X" condition is hidden for readabability, but then you are asking for implementation details and not features for users. Which is not up to you as a user to ask for because it doesn't matter. Also you can basically already do it yourself already with circuit conditions and all the other features you requested so why even bother?

Then you can do pretty much everything with your trains. You can optimize them in a way that train fills from multiple providers and delivers to different drop offs. After that it is just about exposing additional properties of a station for the conditions to make the system more robust.

I think the system could be improved in small ways to give us a lot more control. I think some of the things you ask for don't have clear use cases but also requires a massive amount of work. Which is why I asked for the smallest feature that would give me "complete" control over train with circuit network (see link, but adding values to generic signal and have generic in stop names as well so we can send trains to any stop "ID" with circuits). But feel free to improve each of your requests with a justifying use case.

[Calid]

First of all, thanks for an elaborate and thoughtful response.
I have some counter-arguments, but I will start with a disclaimer. I understand that my ideas of train schedule functionality is some massive work that is oriented towards rather hardcore players which make up just a small percentage, and might be not worth developing. Some might get repulsed, even.

Stations in the schedule should be defined by an ID, not a name (obviously, represented by a name in GUI), so you can safely rename a station without compromising existing schedules (name is supposed to be just a label, after all).

Wrong. ID's are unique, which means you would need an interrupt for each station with the same name if we switched to forcing ID's everywhere. This is just makes it annoying to deal with. Don't force ID's. But having them as an option is good.

Using names is good because it is a simple way to specify and group stops. Names shouldn't become just a visual thing because then they would be quite pointless and people would probably not name stops at all, ending up trapping themselves in an unorganized mess.

Instead, fix the drawbacks of names. Maybe allow stops to have multiple names, unless the tag system is made into a better solution. And tags would have the same issue when they are changed as names. So just fix that, make changing names/tags of stops give you the option of updating schedules instead of forcing it. Sometimes it's the behavior I want, sometimes not.

This is exactly my point, I think that grouping or routing should not be based on the station name. My idea is that grouping is performed by a specific station property. People may as well keep the default randomized station names unchanged without hindering usability of configuring train schedules. I agree with you that keeping something as an option is sometimes better than forcing it, same should go for the station names. Why force naming stations in some specific way to make something work?
Will it be an unorganized mess or not depends on how it will be implemented in GUI.

Picture this: when you click on "Add new station", a new window opens. There you get a list of all of your stations in a table format. Imported or exported resources, train limits (etc, all exposed fields) in separate columns. Some filters at the top of that window to allow for easier lookup. In essence, I'm describing what we already have as Universe Explorer in SE. Once you have your station added to the schedule, you can just mouse over that station to see the properties of that station in a tooltip.

One can argue that using names exclusively for describing station properties might result in a mess as well. What if I am to find all iron plate provider stations located on a certain planet with priority of 10 or greater. Maybe with "something" in tags, even.

And just to reiterate on grouping: you wouldn't need to create an interrupt for each station which have something in common. You can specify that common property of the station just once. "1. Travel to station which has 'copper_ore' in 'exports'. 2. Travel to station which has 'copper_ore' in 'imports'."

We share the same opinion that tags might be useful. I think that implementing just tags is a half-measure and we should go further by exposing other fields.

I also don't understand the necessity of BOTH ordinary schedules and interrupts. Just the idea of "If Condition then Go to" is enough. Just evaluate that list from top to bottom each time a train departs a station. If you need to force specific order of stations, just add "current_station" to the list of the available conditions. It may even be a default condition for a newly added station to the schedule, so those who don't want to bother with train logic, won't have to.

Regular schedules are less hassle to set up and read. Re-ordering interrupts doesn't work even if you make them "schedule-like", since they already have a bound "current_station == X" condition. Seems like you are trying to reduce features to make it simpler, but actually end up making it less simple to work with. And sure a GUI could be made so that interrupts with "current_station == X" show up in a list like schedules do now so that reordering them works like it does now and "current_station == X" condition is hidden for readabability, but then you are asking for implementation details and not features for users. Which is not up to you as a user to ask for because it doesn't matter. Also you can basically already do it yourself already with circuit conditions and all the other features you requested so why even bother?

Maybe, you are right. And I agree that specifying "current_station" in every condition might seem like abstraction leak which overcomplicates things.

I'm trying to find a way to make it simple without limiting schedule capabilities, because for now it seems to me that mix and match of an ordinary and interrupt schedules in a single train might be unnecessarily hard to follow. Okay, how about that. Radio button with two options: Basic (or sequential) schedule and Advanced (or conditional). Basic schedule is what we already have, unchanged. Advanced is what I described above.

More than that, if a conditional schedule is configured properly, you would never need to specify current_station in the list of conditions to keep your stations in a sequence. Why would you care about some specific station order, if your conditions are set correctly? If you need that, go there, If you have that, move it there. If you are low on fuel, there you can find it. If you want to implement a more complex schedule with some multi-level branching logic, why not. If you don't want to bother and just keep stations in a sequence, you have a basic schedule for that.

About requester and provider being the same station. Admittedly, I've never tried that kind of configuration myself, so I don't have a strong position here.

[Qon]

This is exactly my point, I think that grouping or routing should not be based on the station name. My idea is that grouping is performed by a specific station property. People may as well keep the default randomized station names unchanged without hindering usability of configuring train schedules. Will in be an unorganized mess or not depends on how it will be implemented in GUI.

Name is a property. Making it possible to target many different kinds of properties sounds fine, but removing name as an option doesn't add anything. Giving names that make sense to you and the organization of your factory makes sense when you look at your map. And if you don't want names and want to give generic names for all stops then you can just name generic stops "." or something and use other properties to target them.

Maybe other properties could be visualized on the map instead of name, but different trains might target them on different properties. It could get messy, "not name" might suddly disappear completely when the stop gets no signal because it doesn't request anything more at the moment, ir might get 1000 signal types as input and cover the map. So now we need a way to configure what kind of visualizer should be shown for each stop instead of name. And then I might just name everything same as now and choose name as what to display on map, and then have to configure stops to require/provide same thing as what the name suggest. And now there's a risk that the signals might accidentally not be same as name suggest because the different configurations of name and requests aren't enforced by the game to be coherent. Sure, there could be a setting to automatically set name from requests or vice versa. But then we have just reinvented scheduling by name again with extra steps. I'm not sure we are actually solving a problem that needs a solution.

Picture this: when you click on "Add new station", a new window opens. There you get a list of all of your stations in a table format. Imported or exported resources, train limits (etc, all exposed fields) in separate columns. Some filters at the top of that window to allow for easier lookup. In essence, I'm describing what we already have as Universe Explorer in SE. Once you have your station added to the schedule, you can just mouse over that station to see the properties of that station in a tooltip.

One can argue that using names exclusively for describing station properties might result in a mess as well. What if I am to find all iron plate provider stations located on a certain planet with priority of 10 or greater. Maybe with "something" in tags, even.

I think your "properties" sound a lot like my suggestion "send train to stop with signals matching these inputs...". But yours is described as being configured with a static GUI selector while I wanted to match on input signals to trains exiting a stop with another stop getting input signals. But of course we both want both, maybe. Maybe adding constant combinator GUI to train stop GUI is kind of pointless when you can simply wire a constant combinator to a train stop instead. I think "requests" and "provides" might unnecessary concenpts for the game engine though. What I want is some signal (property) matching and I can make requests and provides myself by matching on positive or negative signals. Trains could use a more sophisticated GUI for matching properties/signals though, you can't really have ranges described with signals in a simple way. And interrupts should be able to add multiple temporary stops to schedule, so that you can chain both pickup and delivery based on need on delivery.

And just to reiterate on grouping: you wouldn't need to create an interrupt for each station which have something in common. You can specify that common property of the station just once. "1. Travel to station which has 'copper_ore' in 'exports'. 2. Travel to station which has 'copper_ore' in 'imports'."

Is "exports" a name for a wire connection point?

We share the same opinion that tags might be useful. I think that implementing just tags is a half-measure and we should go further by exposing other fields.

What are tags though? Like names, but you can assign multiple to a single stop?