New Train-Schedule-Mode / Conditions instead of Train-Stop-Names / Remove Names from Train-Schedule

[ssilk]

TL;DR

Trains can have two modes of operation: The already known hopping from stop to stop by name (which isn't touched here) and a new mode, that searches a possible stop by a condition.

What ?

This new mode works like so:
Instead of a train stop name which is the next target of a train you can set up "conditions", which must either be present at one or more train stops or at the current train. Only if a condition evaluates completly to true that train stop is a candidate for the target of a train.

Conditions are looking like so (examples):
- Is there at any stop more than 2000 iron ore?
- Is my own fuel below 200 MW AND is there a "Refuel"-signal at any stop?
- Is there an "Unload"-signal AND any iron-ore signal?

For more complex logistics this can be simplified:
- Am I empty AND Is there a positive number of iron-ore (a provision)?
- Am I not-empty AND loaded with iron-ore and is there a stop with negative number of iron-ore (a request)?

So in general this works so:
Like now there are "entries of schedules" for a train. And the train goes from one entry to the next. But instead of train-stop-names the entries are conditions. So when train leaves a stop he jumps to the next entry (=condition), and then he will search through all train stops for this current condition. All candidates, that evaluate to true with this condition are then put into a list of possible train-stop-candidates.

By default the list is sorted by distance. But there could be other sorting criterias like
- Order descending by WAITING TRAINS * 5 and by number of TARGETING TRAINS * 3.
- Order ascending by distance * 0.1 and ascending by requested iron-ore (from train stop).
...

Result should be a very flexible much more logistic-like transport.

This new mode can be part of a research (kind of useful to have already trains fully researched and combinators also).

Why ?

This is some kind of counter-suggestion to those suggestions, which want to mix the current usage of train-stop-names in combination with conditions. In my eyes the concept of train-stop-names in Factorio is really nice (and as said this isn't touched with this suggestion), but when used in combination with conditions, it gets soon very illogical and misunderstanding because of many small reasons, so I want to avoid this possible direction. Instead I want to introduce, that the schedule can be automated by setting signals on train stops and having some kind of program (the scheduling of conditions) in the train.

Names as part of a condition (which it is, when you look at the current system like so) is a dead end, when you see it from this direction, cause as long as the train-stop-name is part of the schedule any possible condition is pre-filtered.

Names are just names!

[Engimage]

I don't see anything different from train stop skipping conditions aside from complicating stuff by adding extra train mode

[mp0011]

There are two possibilities:
A) Train gets all data from stations at other station;
B) Train gets data from other station on the way.

In A case:
It's simpler, easier and more logical to implement with "skip (x) stations" signal at the station itself, so the station decide where trains goes.
So Train can get signal "departure = 1", which means "go to next on the list"; "departure = 2" - skip next station; "departure = -1" - go to previous station on schedule list. So, the stations logic circuit does all the calculations (You can set it in any way You like with more wiring) and also the station decides which train may fulfil the requests.

In B case:
Train should drive to station B (next on the list), and then, in the middle of the way, train should receive (telepathically) conditions from different stations (without mixing signals) and decide if it continue to station B or eg. turn back to station C? Or train should leave station without destination, circle around randomly waiting for signal?

[Optera]

This idea, if refined further, has the potential of making both Smarter Trains and Logistic Train Network obsolete by allowing their complex logic straight inside the schedules.

[Engimage]

Please look at my post
viewtopic.php?p=272612#p272612
I am sure that introducing skipping conditions in such manner can already let you implement most of logistical logics. In your idea you still have to hardcode stations into train script. Alternatively you can add those stations into schedule and just ignore (skip) stations that are not needed currently based on circuit conditions. There is no telepathy as all logics are evaluated when train is at the station and actual decision about next station is made. Sorry writing from my phone so can't really write much

[AntiBlueQuirk]

We could just go full blown programmable trains, and have the extra mode be a window with a Lua script that returns the index of the next train station to go to. Maybe it's a bit much, but I would enjoy it.

[ssilk]

This idea, if refined further, has the potential of making both Smarter Trains and Logistic Train Network obsolete by allowing their complex logic straight inside the schedules.

Yes. That was the point. My target was to have one "program" (one schedule) for all trains of one type. For example to look like so:

1. Search for a provision: Filter all train stops that
- provide something worth enough to transport
- are not a target of another train yet
- but only if there are also stops, that require that actually.
2. Search for a request: Filter all train stops that
- request one or more of the loaded items
- are not targeted by too many trains.
3. Filter stops, that
- are marked as refuel-stop
- if train fuel is too low.

Of course this is simple yet, but could be much more complex and so I would not say obsolete.

LTN could do some kind of auto-programming, so that the trains don't need to programmed by the player. Cause in complex networks there it could be, that there need to be not just 3 or 4 rules, but 10 or more so that the train finds the right stop. LTN also looks, if there are are possible useful schedules, before it creates an order. This suggestions doesn't do such thoughts/looks from a completely different perspective to the problem. This suggestion doesn't look for a complete order, but only for the next schedule (exception is the last rule in point 1, but I doubt that this is so easy to be implemented). So if there are some stop with lot's of iron ore and the train goes there, but there is then no stop, that requires that then - well - you have a problem.

Same goes with Smarter Trains. All it does is making the logistic and mods that deal with that a lot simpler.

We could just go full blown programmable trains, and have the extra mode be a window with a Lua script that returns the index of the next train station to go to. Maybe it's a bit much, but I would enjoy it.

Currently the Lua-Api doesn't allow to head a specific stop. See http://lua-api.factorio.com/latest/Conc ... duleRecord
It can target only names. That is the technical background behind this suggestion, cause that needs to be extended to enable Lua to select a target stop just by ID, so that the train cannot decide between two (or more) names. That simple extension would also help a lot for future mods around this subject.

[Optera]

Currently the Lua-Api doesn't allow to head a specific stop. See http://lua-api.factorio.com/latest/Conc ... duleRecord
It can target only names. That is the technical background behind this suggestion, cause that needs to be extended to enable Lua to select a target stop just by ID, so that the train cannot decide between two (or more) names. That simple extension would also help a lot for future mods around this subject.

This would allow fine control of automatic trains in lua.
However it also would mean StopA (ID 1) and StopA (Id 2) would somehow need to be different inside the normal game UI schedule, which would break basically any stacker station design as well as train control logic using trains going to the nearest station of a given name.

[ssilk]

However it also would mean StopA (ID 1) and StopA (Id 2) would somehow need to be different inside the normal game UI schedule, which would break basically any stacker station design as well as train control logic using trains going to the nearest station of a given name.

Yes, I know. Changing that would break the current behavior (*), which makes sense in it's focus.
So I thought we need just a second mode of operation for the trains, that is not dependent from train stop names.

(*) That is not really the case, it could be really simple re-implemented: We would need just a special filter that matches on train-stop-names (not a signal) and afterwards sorts by distance (which is default). That's all.

Which means, there is no need to have a hard switch between those two modes of operation.

[darkfrei]

If we have extra surface for every train, then it can be completed with combinator red and green wiring!

[AntiBlueQuirk]

We could just go full blown programmable trains, and have the extra mode be a window with a Lua script that returns the index of the next train station to go to. Maybe it's a bit much, but I would enjoy it.

Currently the Lua-Api doesn't allow to head a specific stop. See http://lua-api.factorio.com/latest/Conc ... duleRecord
It can target only names. That is the technical background behind this suggestion, cause that needs to be extended to enable Lua to select a target stop just by ID, so that the train cannot decide between two (or more) names. That simple extension would also help a lot for future mods around this subject.

I was actually joking a bit when I made the suggestion initially, but I've been thinking about it, and it would be pretty cool:

trainluamock.png (164.91 KiB) Viewed 5860 times

First, add the ability to give "Next stations" to each order. This is an optional field that lets the schedule be non-linear. The lua code just runs whenever the train hits that point in the schedule. It returns a number corresponding to an order entry, and that becomes the train's next order. If the code returns nothing or an erroneous value, it uses that order's next station entry instead. The lua code would run in a reduced environment, about equivalent to what the conditionals would have.

If you're not a fan of lua actually being part of the game, (It is a little out of place.) then you could just replace the lua pane shown here with a standard conditionals pane, and allow setting the next station on each of those conditionals instead.

[Ripshaft]

We could just go full blown programmable trains, and have the extra mode be a window with a Lua script that returns the index of the next train station to go to. Maybe it's a bit much, but I would enjoy it.

Currently the Lua-Api doesn't allow to head a specific stop. See http://lua-api.factorio.com/latest/Conc ... duleRecord
It can target only names. That is the technical background behind this suggestion, cause that needs to be extended to enable Lua to select a target stop just by ID, so that the train cannot decide between two (or more) names. That simple extension would also help a lot for future mods around this subject.

I was actually joking a bit when I made the suggestion initially, but I've been thinking about it, and it would be pretty cool:

trainluamock.png

First, add the ability to give "Next stations" to each order. This is an optional field that lets the schedule be non-linear. The lua code just runs whenever the train hits that point in the schedule. It returns a number corresponding to an order entry, and that becomes the train's next order. If the code returns nothing or an erroneous value, it uses that order's next station entry instead. The lua code would run in a reduced environment, about equivalent to what the conditionals would have.

If you're not a fan of lua actually being part of the game, (It is a little out of place.) then you could just replace the lua pane shown here with a standard conditionals pane, and allow setting the next station on each of those conditionals instead.

hahaha I'm on board with this... though might be more accessible to have a flowchart/visual scripting language implementation =p

[AntiBlueQuirk]

hahaha I'm on board with this... though might be more accessible to have a flowchart/visual scripting language implementation =p

Yeah, Lua might be a bit much for most of the userbase, but adding non-linear schedules and some sort of decision system would open up so many options.

Interesting idea: get the "next-station" index from a circuit signal piped into the train stop. I think this would have some flexibility issues, but it would basically make trains controllable by circuit network, and would fit the current game systems pretty well. The biggest issue I see is that all the trains going into the station would need to have "specially formatted" orders, or the next station index wouldn't make any sense. (Chaos ensues.)