Trains should wait for refuelling orders to complete before embarking on automatic schedule

[sarge945]

What did you do?
I had a train which I placed manually via ghosts, bots then built it.
Once it was complete, I set it to a train group, set it to Auto, and created a refuelling order (by ghost-placing some rocket fuel in the first slot).
A couple of robots came over and put some fuel in, and it immediately started moving

What happened?
Remaining bots would chase the train and try to put in the remaining fuel. Since the train is significantly faster, they ended up travelling a very long distance.

What did you expect to happen instead? It might be obvious to you, but do it anyway!
The train should wait until all it's fuel requests are completed before moving to the next station

Does it happen always, once, or sometimes?
Always

Extra Info
I'm not sure if this happens with trains placed via blueprint or not, I was doing it all manually because I needed to duplicate a train I didn't have a blueprint for.

[Rseding91]

Moved to ideas and suggestions.

[robot256]

Another side effect of the oversimplified, unconfigurable auto-start logic, I see. Once again I can't read

[worph]

You watched your bots chase the train but didn't click the "Manual" switch?
Seems fine enough to do that also before dispatching the ghost entities.
There is no reason why a train should wait for ghost items to be fulfilled in my opinion.

If you placed that train using bots, you might just as well place it in your refueling depot.

[Rseding91]

Another side effect of the oversimplified, unconfigurable auto-start logic, I see.

This isn't about auto start anything. In this case the player specifically set the completed train to auto, then ghost-requested fuel and as soon as the already-in-automatic-mode train got fuel it drove off.

[sarge945]

Moved to ideas and suggestions.

I'd consider this a bug rather than a feature request. It's an inconsistency in the game logic that results in unexpected behaviour (especially compared to space platforms which ALWAYS wait for requests to be complete). I get that it's probably *technically* working as intended, but not all bugs are actually technically bugs. Sometimes something just doesn't quite work right due to it's design.

In my view, any design decision (intentional or not) that makes playes instinctively go "wow, that's not working right!" is a bug.

[worph]

It's an inconsistency in the game logic that results in unexpected behaviour (especially compared to space platforms which ALWAYS wait for requests to be complete).

A logistics request is something far different from a ghost entity.

[quineotio]

I'd consider this a bug rather than a feature request.

The problem with this type of suggestion is that "fixing" it would create a different problem. In this case, you add a request for fuel in a place where bots can't reach and the train never moves. So you can't satisfy all possible conditions.

[sarge945]

I'd consider this a bug rather than a feature request.

The problem with this type of suggestion is that "fixing" it would create a different problem. In this case, you add a request for fuel in a place where bots can't reach and the train never moves. So you can't satisfy all possible conditions.

If the bots can't reach it, the fuel order will never be started, so making the train wait for any current orders to finish before moving doesn't change anything in this scenario. If the train is somehow in a logistics enabled area and there's no way to service the request then it doesn't matter either since your train has no fuel anyway, there's no difference between it actively waiting to be serviced or not - it's not going to move in either case.

This is specifically dealing with the case where *some* bots have delivered fuel, but more is on the way. The later bots are essentially forced to chase after the moving train.

A logistics request is something far different from a ghost entity.

Umm.... please re-read the original ""feature request"" (ie bug report, yes I am still salty about that).

The fuel order was done after the train was created, but before it was set to Auto. This is a logistics request. The inconsistency is that space platforms respect existing logistics requests before moving so as to allow them to finish completely, trains do not and are more than happy to start driving at full speed even if a bot is in the middle of making a delivery to them.

[worph]

Umm.... please re-read the original ""feature request"" (ie bug report, yes I am still salty about that).

The fuel order was done after the train was created, but before it was set to Auto. This is a logistics request. The inconsistency is that space platforms respect existing logistics requests before moving so as to allow them to finish completely, trains do not and are more than happy to start driving at full speed even if a bot is in the middle of making a delivery to them.

Trains do not possess the ability to make proper logistic requests for their inventories.
You manually put a ghost item (correct technical term: ItemRequestProxy) into it's inventory. Nowhere else in this game do these interact with schedules.

[quineotio]

If the bots can't reach it, the fuel order will never be started, so making the train wait for any current orders to finish before moving doesn't change anything in this scenario. If the train is somehow in a logistics enabled area and there's no way to service the request then it doesn't matter either since your train has no fuel anyway, there's no difference between it actively waiting to be serviced or not - it's not going to move in either case.

Ah ok, makes sense.

[quineotio]

Trains do not possess the ability to make proper logistic requests for their inventories.
You manually put a ghost item (correct technical term: ItemRequestProxy) into it's inventory. Nowhere else in this game do these interact with schedules.

I think that's why he's making a suggestion

[worph]

Trains do not possess the ability to make proper logistic requests for their inventories.
You manually put a ghost item (correct technical term: ItemRequestProxy) into it's inventory. Nowhere else in this game do these interact with schedules.

I think that's why he's making a suggestion

He is not suggesting to give trains proper logistic requests like tanks and spidertrons have. He is very clear about that:

I'd consider this a bug rather than a feature request. It's an inconsistency in the game logic that results in unexpected behaviour (especially compared to space platforms which ALWAYS wait for requests to be complete).

I hate to be this pedantic, but if you confuse the actual words and call a ItemRequestProxy a logistic request, you are confusing two things, and are bound to get into conflicts with how both of these things work. Understanding the underlying principles must be step one before actually asking for them to be changed.

There is nothing to be changed. Everything behaves very deterministically here. Trains do not know about ItemRequestProxies and changing that wouldn't be increasing parity between space platforms and trains. This is a fundamental misunderstanding. I have not addressed the actual suggested change because so far the OP has been unable to show that he understands logistic requests and ItemRequestProxies are two separate things, that are treated differently by the game engine.

[quineotio]

He is not suggesting to give trains proper logistic requests like tanks and spidertrons have. He is very clear about that:

Correct. He's suggesting something else.

Understanding the underlying principles must be step one before actually asking for them to be changed.

He just wants the train to wait for bots to arrive before leaving. The person making the suggestion doesn't have to understand how the game is programmed to make the suggestion. That's ridiculous.

There is precedent for the type of behaviour being asked for, which is that trains wait at a station if a bot is attempting to fulfill a quality upgrade. The suggestion would simply expand this logic to having trains wait if a bot is en route for other reasons.

The implementation details are up to the devs.