Factorio Forums

TL;DR

Space platforms which have met all their departure conditions should only wait for rockets that have actually launched, not those that are being loaded; there should be a separate, explicit (and thus optional) departure schedule condition that waits for rockets that have been requested but no yet launched.

What?

Currently, a space platform which has met all its departure conditions will not actually leave if there are rockets 'on the way', but 'on the way' is defined to start from the moment the request to launch a rocket is made, and thus includes rockets that currently being loaded by bots, or which are fully loaded but cannot launch. This can result in platforms getting stuck in orbit if:

• There was enough of an item in the logistics network to meet the minimum payload, so a silo was assigned to launch them, but then some or all of them were removed from the logistics network, making it impossible to fill the silo and launch
• The item the silo is attempting to launch is spoilable, and some of it spoiled, meaning there's no longer enough to fill the silo
• The platform doesn't have enough hub storage space to accept the rocket's contents

This both traps the platform in orbit, and renders the assigned silo unavailable for any other launches.

Instead, a space platform which has met all its departure conditions should only wait for rockets which have actually started their launch animation. If there are any other pending launches, they are cancelled; if the silo was loaded by bots, any items already loaded are moved to the trash slots.

For cases where the player wants the current behaviour, space platform schedules should gain a new condition, 'No pending launches'. This condition is false if any silo has been assigned a launch for this platform, but has not yet started it's launch animation, and true otherwise.

Why?

The current behaviour is implicit, automatic, and operates separately from the player-controlled platform schedule. Thus it cannot be controlled or overridden by the player.

Now, for obvious reasons, platforms cannot leave when an inbound rocket is in flight. However, the delay between the start of the launch animation and the arrival of the cargo at the platform is fixed, and as of 2.1 platforms will no longer queue new launches once departure conditions are met, so the maximum time a platform can be forced to wait for them is finite. Meanwhile, the amount of time one can potentially wait for a rocket which is not yet launched is unbounded. If a player wants to wait for them, that's what the new departure condition is for, but by moving that into the platform schedule, they have the option of adding alternate conditions, such as 'after 120s, leave anyway' or 'leave immediately if you are taking damage or running out of ammo'.

I'd prefer that platforms simply couldn't get stuck this way. If a rocket silo thinks it can handle a request, but then fails to do so (insufficient items are available or whatever), the request should be aborted and the platform should be free to leave.

Specifically:

If a player wants to wait for them, that's what the new departure condition is for

Why would a player want a rocket silo to be indefinitely stuck trying to fulfill a request that cannot be fulfilled? We shouldn't add a new schedule item for behavior that won't break platforms. Just make the behavior everyone's already using work correctly.

Alfonse215 wrote: Sat Sep 05, 2026 3:41 am I'd prefer that platforms simply couldn't get stuck this way. If a rocket silo thinks it can handle a request, but then fails to do so (insufficient items are available or whatever), the request should be aborted and the platform should be free to leave.

So, the downside of this is that it could potentially cause a lot of annoying and wasteful back-and-forth. Let's say you've got your iron smelting area set up to load 1k iron plates into its buffer chests. A ship comes in requesting iron plates, so it the request is assigned to a silo and bots start transferring iron there. Midway through, an inserter grabs a handful of plates to be turned into gears, which takes you below 1k total iron. Whoops! Unsatisfiable request, cancel it! All the already-loaded plates get moved to the silo's trash and the bots start unloading them instead. Then, a second later, your foundries, having noticed the deficit, make a replacement plate, brining you back above the required 1k, so a new request gets assigned to a silo - maybe not the same silo - and the bots start carrying plates there instead. All to top it all off, the ship was set to 'All requests fulfilled', so it can't leave until the rocket is actually launched no matter how long that takes!

Similarly, a ship might temporarily have insufficient space to accept a delivery, until it drops some other items to the planet, or moves items out of the hub via inserter, and you wouldn't want to immediately cancel the request and start unloading the silo.

Fundamentally, the game has no way of knowing whether these conditions are temporary or permanent. The current system implicitly assumes they're always temporary, which causes a problem when they're actually permanent (or at least long-lasting). Your suggestion, on the other hand, effectively assumes they're always permanent, and thus is highly suboptimal if they're actually temporary and will go away on their own shortly. My suggestion leaves it in the hands of the player, who can set up their departure conditions for whichever one they think they're going to encounter, or even both if they want.

Alfonse215 wrote: Sat Sep 05, 2026 3:41 amSpecifically:

If a player wants to wait for them, that's what the new departure condition is for

Why would a player want a rocket silo to be indefinitely stuck trying to fulfill a request that cannot be fulfilled? We shouldn't add a new schedule item for behavior that won't break platforms. Just make the behavior everyone's already using work correctly.

A player wouldn't want a rocket silo to be indefinitely stuck trying to fulfill a request that cannot be fulfilled, no, but they might well want to wait for a request which cannot be fulfilled now but will become possible to fulfil if it just waits a little while.

For instance, let's say you want your ship to pick up widgets from Aquillo, but don't want it to wait around for any particular amount; just pick up what's currently available and go. You might use a schedule like this:

• [5s inactivity] AND [No pending launches]
• OR [120s elapsed time]

The inactivity timer gives time for the widgets to be assigned to silos. The pending-launches check ensures the ships doesn't leave before they launch, even if it takes more than 5s for the bots to deliver all the widgets. And the elapsed time creates an escape condition that protects against a stuck silo.