Train Target by Order of Schedule (was: Dynamic train schedule)

[mrvn]

So I split the thread after viewtopic.php?p=555209#p555209 — ssilk, 2021-10-29

Huh, a lot of frustration here.

Well, I can’t resolve frustration with words, but at least I want to let you know, that frustration is a kind of stress and stress blocks those parts in your brain, that could help you to find a solution to your problem. Because what I can say is: there will be no soon solution and even if there is a Factorio II then nobody knows, if this issue will be addressed.

What me helped was to see that all as part of the game - to work around those restrictions - and I recommend to see it similar, because anything else results in frustration like this. And it is much more satisfying than you might think to find a solution. Even if you currently exactly KNOW, there is no solution, I say: there is at least one to your current problem. Of course it would be cooler to have this feature, you would need not to think so much.

Problems in real live (engineering problems and other) are sometimes much more complex, than this one. So there is no need to cry. It’s much better to be happy, because you find an error in your planning and now you get extra hours for playing to solve this problem.

So in those situations, instead of playing I lean back and think about the problem by doing something completely different. Maybe one week or longer.

Hope this helps to get around the frustration.

Maybe some tip: What I really think is blocking your sight is that each station should have one train. That’s not working very well. Much easier to say I have one or more trains for each item/resource. That’s from my experience generally working much simpler, for example because it doesn’t matter if you have items left when loading. There are then much more restrictions if you have stations, that can load different items. But if you just follow the idea of “I’ve an iron ore train and now I have some stations that have iron ore and some that need iron ore” you see immediately that this is a quite simpler task.

You asked for a Mod: Well, I’m not 100% sure if that is what you want or already have looked for, but the LTN mod is a perfect solution to handle stations with multiple items. But it is not easy to handle, it gets much more complex, before it gets simpler, but then it’s pure fun. https://mods.factorio.com/mod/LogisticTrainNetwork

The thing I feel is most frustrating is that among the suggestions about dynamic train schedules and skipping stations there is one simple suggestion that would be trivial to implement and let players solve the problem on their own.

Add a signal (default D) to the train stop to set the trains next destination. If I send D=1 then the train goes to the first station in the schedule. D=5 and it goes to the 5th station in the schedule.

Want to skip a station when destination full? Check train content to see if the loading/unloading is done, train still here a few ticks later? Send it to the next index in the schedule. Want to refuel the train as needed? Use the train inventory sensor (mod, train stops don't report fuel, another one of those trivial suggestions) and send the train to index 1 when low on fuel.

Want to build a turing machine using trains? Set D=<next state> to have the train transition to the next iteration.

So simple a change, so many options.

[ssilk]

Add a signal (default D) to the train stop to set the trains next destination. If I send D=1 then the train goes to the first station in the schedule. D=5 and it goes to the 5th station in the schedule.

Nice idea. But that’s not the original suggestion we’re talking here about.

Make an own suggestion if you want to discuss it.

[mrvn]

Add a signal (default D) to the train stop to set the trains next destination. If I send D=1 then the train goes to the first station in the schedule. D=5 and it goes to the 5th station in the schedule.

Nice idea. But that’s not the original suggestion we’re talking here about.

Make an own suggestion if you want to discuss it.

It's already a suggestion (or more than one) and linked in the first post: Train-stop id and train targets a train-stop by id(a bit off-topic)

[ssilk]

So I split the thread after viewtopic.php?p=555209#p555209 .

Here the link that mrvn points to
viewtopic.php?f=6&t=53792 train-stop id and train targets a train-stop by id

That’s a completely different suggestion. The Train-stop-Id is a kind of internal numeration of train-stops. It has no order. Usage of this ID is possible, but wired. Because the id can change. E.g. a train stop gets destroyed and you rebuild it.

You still can’t make any changes to the schedule, but you can change anything if you jump not wider than the schedule-length (if you have three stops in the schedule but you want to jump 5, then you cannot add any stop to the schedule without changing the logic).

You meant to use the order of the schedule. That’s much better. But has the disadvantage that you cannot make some changes of the schedule without breaking the correct functionality, if you use the order.

I would use a much simpler idea: a jump-signal, that lets a train “jump forward” in the schedule.

Jump signal is 0: no change in behavior, schedule just goes forward from station to station.
Jump signal is 1: jumps 2 stations (after the next station)
Jump signal is 2: jumps 3 stations forward in the schedule
Jump signal is -1: schedule jumps to the station before the current

Simplest example of that:
Station a is iron load, b is unload, c is refill.
Train goes to a, then b. On b the circuit for the jump signal goes from 1 to 0 if the train has not enough fuel on board. What counts is the signal state in the moment, when the train wants to leave.

I think that would be really simple to implement, and the game-value is really, really high. For example all want something that enables to jump over depot stations, if the target station is already empty. With this suggestion no problem, but with the twist that you need to know that TWO stations BEFORE, not only one. Which is in general always possible, but in reality it might be a hard puzzle to wire that correctly.

[mrvn]

The jump signal has potential. I totally agree that the train stop id is too fragile to use. There was another suggestion very much the same but using schedule indexes instead. If a relative offset is easier or seems more practical than an absolute index into the schedule then that's the way to go. Both absolute and relative has advantages and disadvantages. I don't think any has a clear claim to be better. Only use of both would tell I guess.

But I don't get what you mean by "TWO stations BEFORE"? The train arrives at the unloading station. While it is unloading you have some circuit logic check the loading station if it is ready for more trains and that sets the jump signal to 0 (go to depot) or 1 (skip depot).

I'm assuming the jump signal will be able to update as long as the train is still in the station, right? That would make it 0 stations in advance.

If you have to set the jump signal before the train arrives then that would be less ideal but still only one station in advance.

Two station in advance would mean that when the train is at the loading station and will go to the unloading station next you already have to set a jump signal for the stop after that. And then what does the jump signal at the unloading station mean? The second next stop is offset relative to the unloading station or to the already decided next stop (which can be depot or loading)? That would make the jump signal mean different things depending on what the last jump signal was. I smell chaos.


One thing that would be nice, but I'm not sure if it would work, would be if the jump signal could be changed while the train in sitting in a station with "No path" or "Destination full". Not sure if the train is considered to have already left at that point and won't read signals from the train stop anymore. The idea would be to have the train skip stations when they are full and go to the next lower priority station. The circuit logic would increase the jump signal until the train leaves the station.

[ssilk]

But I don't get what you mean by "TWO stations BEFORE"? The train arrives at the unloading station. While it is unloading you have some circuit logic check the loading station if it is ready for more trains and that sets the jump signal to 0 (go to depot) or 1 (skip depot).

Ya, and that happens two stations before the target station: one before is the depot, two before is the unload station. Not at the depot, then we are too late and not during the travel. You need to know it two stations before (or three, or four… depends on how far you want to jump). There is no way to influence the schedule while driving. Because you need to know which train can jump, and which not.

I'm assuming the jump signal will be able to update as long as the train is still in the station, right?.

As long as the train waits at the stop. See below.

And then what does the jump signal at the unloading station mean?

That you can “jump” back to the load station of course.

The second next stop is offset relative to the unloading station or to the already decided next stop (which can be depot or loading)? That would make the jump signal mean different things depending on what the last jump signal was. I smell chaos.

Don’t understand your problem. The current algorithm for train leaving a station is really, really simple (and I simplified it more … I don’t know how it is really implemented, it depends on many things. But it must be something like that):
- are all conditions green for leaving the stop? (No wait condition open?)
- increase target stop in schedule by one
- leave stop
- calculate path to the target
- drive calculated path

What changes: This suggestion does nothing else than replacing
“increase target station in schedule by one”
with
“increase target station in schedule by (one plus jump signal on current stop)”.
That’s it.

One thing that would be nice, but I'm not sure if it would work, would be if the jump signal could be changed while the train in sitting in a station with "No path" or "Destination full".

It should be so. But see algorithm: the schedule seems to change before leaving the stop. When it leaves the stop, the train is not longer bounded to that stop.

But with my algorithm if the target is full, it cannot begin to drive, because it cannot calculate the path. So you need to think some kind of loop around step 2 and 4, which is calculated whenever something changes, that could influence the result. That loop is currently only around step 4. I could think of a special rule, if a train just left a stop and yet has not changed position (not drive) it is still somehow connected with that stop. On the other hand, if the target is full, you have made an error in calculating the jump-size, nothing else.

So, again, it depends on how that part is really implemented and how complicated it is to change it without side-effects.

But it’s not a general problem, because you can already change the schedule, when the train is in that “loop”-state. It means also, this suggestion could be implemented by a mod.

[mrvn]

Don’t understand your problem.

Just confustion what you meant by two stations in advance.

One thing that would be nice, but I'm not sure if it would work, would be if the jump signal could be changed while the train in sitting in a station with "No path" or "Destination full".

It should be so. But see algorithm: the schedule seems to change before leaving the stop. When it leaves the stop, the train is not longer bounded to that stop.

But with my algorithm if the target is full, it cannot begin to drive, because it cannot calculate the path. So you need to think some kind of loop around step 2 and 4, which is calculated whenever something changes, that could influence the result. That loop is currently only around step 4. I could think of a special rule, if a train just left a stop and yet has not changed position (not drive) it is still somehow connected with that stop. On the other hand, if the target is full, you have made an error in calculating the jump-size, nothing else.

So, again, it depends on how that part is really implemented and how complicated it is to change it without side-effects.

But it’s not a general problem, because you can already change the schedule, when the train is in that “loop”-state. It means also, this suggestion could be implemented by a mod.

The idea there would be to change the jump signal based on feedback from the train so you don't have to string a wire to every single station in the schedule to know if they are open or not. Even with wire you would have delays from combinators and the stops themself making it impossible to never exceed the train limit unless you only allow one train per tick to leave a station.

[ssilk]

The idea there would be to change the jump signal based on feedback from the train so you don't have to string a wire to every single station in the schedule to know if they are open or not. Even with wire you would have delays from combinators and the stops themself making it impossible to never exceed the train limit unless you only allow one train per tick to leave a station.

You mean that the train returns … something… that you can read at he train stop where that train is currently stopped, that tells you … whatever … so that you know how much the jump should be now?

Sounds quite complex/mysterious versus “if you need to know the jump amount, get the right signals to the right place”. You can use a radio-transmitter-mod to help with that. That mod is btw. easier to implement into vanilla, than this suggestion.

[mrvn]

The idea there would be to change the jump signal based on feedback from the train so you don't have to string a wire to every single station in the schedule to know if they are open or not. Even with wire you would have delays from combinators and the stops themself making it impossible to never exceed the train limit unless you only allow one train per tick to leave a station.

You mean that the train returns … something… that you can read at he train stop where that train is currently stopped, that tells you … whatever … so that you know how much the jump should be now?

Sounds quite complex/mysterious versus “if you need to know the jump amount, get the right signals to the right place”. You can use a radio-transmitter-mod to help with that. That mod is btw. easier to implement into vanilla, than this suggestion.

The train stop already outputs the presence of a train. Or lacking that the signals do. But I can't see changing the jump signal having any effect if the train already considers itself having left the station and the train stop stops outputing the train ID.

Say you have a schedule: Load Coal (full cargo), Power Plant (empty cargo), Smelter (empty cargo). The Power Plant has a train limit.

Now the train is at Load Coal and fully loaded and you detect that by looking at the train content signals from the train stop. So the train should now leave for Power Plant but due to the train limit it can't and shows "Destination full" and doesn't leave. Connect a decider combinator to the train stop with "Coal >= 2000 ==> J=1", connect that back to the train stop. 1 tick after loading finished the train stop gets J=1.

If the train hasn't left 1 ticks after loading is complete the train stop gets a "J=1" signal and the train skips the Power Plant. Would be a rather simple way to skip stations with "Destination full". It doesn't really matter if the train moves, only if it's still reads the J signal from the train stop.

Currently you have this inconsistent behavior:

train.png (794.25 KiB) Viewed 1750 times

The train schedule conditions have all been met and the train should leave. The train stop no longer emits T=<id>. But it still transmits the train count as if the train was still targeting the station. A bit inconsistent but I guess it prevents a second train from coming to the station and exceeding the train limit when a train is blocked from vacating the station.

So there is already an inbetween state for trains. It has finished loading but has not yet left. If the train still checks the J signal in that state then the above idea works. You could increase J every tick till the train hits a schedule entry that it can reach.

Or you set J to trap the train with an unreachable train stop (limit = 0). Then read circuit signals from all over the place and if any station signals that it needs coal you change J to the right number to send the train there. It would truly allow programming trains dynamically with combinators.

[FuryoftheStars]

Edit: Blarg, nvm. I’m misremembering how things worked.

[mrvn]

Edit: Blarg, nvm. I’m misremembering how things worked.

No worry. I did too and actually just noticed due to this thread that the train count remains after a train "left" the station with Destination full. My first edit was to say such a state would have to be introduced just to notice it already exists. I believe it's an addition for the train limit.

[ssilk]

@mrvn: well, we can think deep, how this problem might be implemented.

But that’s not how software and especially Factorio is implemented. It’s done in a more or less agile style.

Which means in this case: where do I get the most bang for my bucks? That’s implemented first.

Here it’s obviously: add a jump input signal to train stop that influences the train-schedule.

The next thing might then be your enhancement. But who knows? When you play around with this suggestion then you probably find a much better idea. It would be really stupid to
- not change the plan if the surrounding changes
- insist on the plan, even if there are obviously better ideas now

[mrvn]

@ssilk: I'm not disagreeing with you.

I can't say for sure since I don't know the code. But from the behavior I see in the train stop with a train on "Destination full" having no train ID output but having a train count output it looks like your jump signal idea will work out perfectly for everyone with a straight forward implementation. There shouldn't really be anything extra to implement to make trains behave like I described, just careful placing of the code that makes the jump signal change the trains schedule index. If it's place so it acts when the train leaves the station as well as when it is in this stuck state we are golden.