Feel free to ask for anything else if you get stumped again, or if anything I said was unclear.

If/when you start getting into trains, signals might require some explaining. I remember having a difficult time gripping the concept of block signaling when I had to learn it for the Minecraft mod Railcraft, which has a very similar structure to Factorio's rail system.

Trains and space platforms work the same way as far as scheduling goes. They traverse the station list one at a time, in order, and loop back to the top when they get to the bottom.

When it gets to whatever stop it's targeting, it will start asking, "Can I leave yet? Can I leave yet? Can I leave yet?" incessantly in the background, and it will leave as soon as it hears "yes". By default, if you don't set any conditions, the answer is "yes", and the train or space platform will blow straight through without even stopping. If you set conditions, it will stop, and it won't leave until the combined answer to all of the condition you set is "yes".

The station conditions for trains are different from the station conditions for space platforms. For space platforms, some of the more relevant ones related to cargo are:

• Request satisfied: This condition makes you pick one of the requests you set, and checks only that one to see if it's satisfied. You want to use this condition only if some of your platform's requests are must-haves, and the rest are "nice to have, but don't wait for them".
• All requests satisfied: The platform will only leave if and only if every request you've set is satisfied. It will wait until they're all finished. This the one you want.
• Item count: For this, you pick an item, a number, and some kind of inequality symbol. If the number of items on your platform matches whatever your condition you set, the condition will trigger. You can use this as an alternative to "requests satisfied" and achieve the same thing that way. It's less convenient though, because if your requests change, this condition won't change with them.

The other request-related conditions tend to have uses for interrupts moreso than scheduled stops.

You can think of a train or space platform as always being stopped at a "phantom station" at all times, even when it's in motion, and it's always checking "Can I leave yet? Can I leave yet?" at that phantom station against all of its interrupt conditions at the same time. If any one of the interrupt conditions becomes true, the train or platform will immediately pause whatever it is doing and go to the station you set in the interrupt instead. A sort of "oh shit, emergency stop, gotta do this right now!" situation. Very useful for commanding, say, a platform that is low on fuel to stop what it's doing and head to your designated refueling station.

These negative cargo-based conditions are:

• Request not satisfied: The opposite of "request satisfied". You might use this in an interrupt to tell your platform, "Oh no, you aren't topped off on item, stop what you are doing and go fix that immediately."
• Any request not satisfied: Same as above, but instead of picking a request to check, it will trigger for any request that is not satisfied.
• Any request zero: A slightly more lenient form of the above condition. The above condition will trigger if any request is not satisfied. This condition will trigger if any request that wants more than zero of a thing is unsatisfied, and there is currently zero of that thing on your platform. Useful for when you want an interrupt for being completely out of something, but being fully topped off isn't important. Nuclear fuel might be one of these situations.

Keep in mind that for space platforms specifically, requests have to be set per-planet. I've already screwed up several times trying to request, oh, green arms from Vulcanus or something to deliver to Nauvis, and I get my platform all the way to Nauvis only to learn the platform never picked anything up because my green arm request was set to pick up from Nauvis and not Vulcanus. Still getting used to that detail.