Fleetsaving: route visibility and failure modes

Protect the return, not only the departure

Fleetsaving means moving ships and movable resources off a location during your absence. The dangerous moment is often the landing: another player may arrange an attack to arrive immediately afterward. Defenses can discourage a casual raid but do not make a valuable fleet safe.

Decide when you can genuinely be online before choosing a route. Use the game’s arrival display and server clock, not an estimate from yesterday. Research, ship composition and speed settings can change the duration. Leave time to reconnect, inspect events and act; an alarm at the landing second is too late.

Choose a method you understand

Without a moon, deployment between your own planets is a useful route to understand. Its outbound movement appears on a phalanx scan of the destination planet, not the origin. A recalled Deployment is absent from phalanx, although observations made before recall can help an opponent estimate its return. Deployment to an owned moon has no directly scannable destination. With two suitable moons, moon-to-moon Deployment avoids direct phalanx scans at both endpoints, but moon destruction, predictable habits and an unattended arrival remain risks.

Run the departure checklist

1. Gather the ships you intend to protect. Check outstanding returns and shipyard completions that could leave ships behind after departure.
2. Select the destination and confirm whether each end is a planet or moon. Pick deployment only when that is your intended method.
3. Set speed and read the resulting arrival time. For a recalled save, first practice and inspect the return timer with a small, expendable fleet.
4. Load resources within capacity, accounting for flight fuel. Make sure the destination or return location will have what you need for the next launch.
5. Send, then reopen the event list. Confirm the mission exists with the expected ships, cargo and time. A clicked button is not proof of launch.

Plan around real life

Use two reminders if helpful: one before you need to log in and one before the critical event. An unreliable connection is a reason for more margin, not tighter timing. If you cannot reliably cover any return window, investigate vacation mode and its current conditions before the absence. It is not an emergency button to assume will fix an already developing attack.

Recall timing and threat response

Do one small deployment while you stay online. Inspect its outbound event, recall it, and observe the displayed return. Repeat with the ship mix you normally use, because the slowest ship affects travel. This is a route check, not a promise of invulnerability.

When threatened, first read the incoming mission and time. Do not recall in panic without checking whether you can cover the resulting return. Ask an experienced ally to review the precise situation privately. Do not publish live fleet coordinates or return times in a public alliance guide. After every save, inspect the original location for leftovers and new production.

Match the mission to the exposure

Deployment remains the useful starting point because its outbound movement and recall have different visibility rules. With two suitable moons, a deployment avoids direct phalanx scans at both endpoints. Without moons, a deployment to another owned planet can be inspected at the receiving planet. Recalling removes that deployment from phalanx, but earlier scans may still help an observer estimate its return.

The important comparison is not simply moon versus planet. Check the mission, both endpoint types, which part of the flight is underway, and what happens if a moon disappears. The matrix below describes ordinary visibility before such changes.

Two deployment routines, two commitments

An arrival save ends with ships stationed at the destination. Plan to be present before they land, with the destination inspected and the next move already affordable. This is the simpler routine to understand, but a visible destination arrival can become a target.

A planned recall save adds a second commitment: you must recall before the original arrival and then cover the newly displayed return. Decide on that window before departure. The best route is not the one that produces the longest flight; it is the one whose required actions you can reliably perform.

Practise with a small fleet while online. Record the displayed outbound arrival, recall it at a known time, and check the actual return. Do not use a generic stopwatch rule for a valuable fleet when the live event list can tell you the result. Changing research, bonuses, composition or speed can invalidate an old preset.

When a moon disappears

Moon destruction can redirect a moon-related flight to the associated planet. That can create a scannable endpoint where none existed before. Re-read the event list after the loss instead of relying on the route you originally launched.

A player-recalled Deployment keeps its special phalanx treatment; do not apply that exception to every returning Transport, harvest or attack. Conversely, absence from a scan does not prove that an opponent lacks a return estimate. If someone observed the outbound Deployment and the moment it disappeared, they may have enough information to attempt a timed return hit.

Version caveat: a 22 September 2021 staff reply described a Deployment already en route from a planet to its own moon when the moon was destroyed: on reaching the missing destination, it automatically returned to the planet and became phalanx-visible. Live version 12.0.36, released on 27 March 2025, later included moon-loss Deployment visibility fixes, but its notes do not identify this exact same-coordinate case. The current-version behavior of that automatic return has not been verified. Do not assume an automatic return behaves like a player-initiated recall; recheck the actual route and landing.

The live March 2026 change slows Moon Destruction through a fixed Deathstar speed of 310, independent of normal server fleet speed and higher Hyperspace Drive. It buys time in some situations, not immunity. Other Deathstar missions use their normal speed rules. Check the incoming mission itself before estimating your response window.

Prepare the landing, including everything left behind

1. List the protected fleet, resources, outstanding returns and unfinished shipyard batches. Satellites, crawlers and defense are stationary assets and need their own protection and replacement plan.
2. Reserve enough fleet slots, local fuel and transport capacity for the next move. A fleet that has landed safely but cannot leave is still exposed.
3. Before logging off, reopen the event list and check the actual mission, planet/moon types, fleet composition and time. Inspect the launch location for ships or resources you missed.
4. Log in with a margin before the earliest relevant landing. Review all arrivals, not just the main fleet. Delayed expeditions and returning supply cargo may need separate handling.
5. If the schedule changes, reassess while there is still a choice. Plan longer absences ahead using the current vacation-mode conditions. Do not depend on an emergency setting to undo an attack already being resolved.

Common shortcuts that fail

These are risk checks, not guarantees. Keep operational coordinates, fleet sizes, recall times and screenshots in private alliance channels rather than in the public guide.