Guide: Spaceships

From Space Exploration
Jump to navigation Jump to search

(WIP - questions or suggestions can be directed to PeterHan5#1790 on Discord.)

Spaceship Systems[edit]

Power[edit]

Accumulator[edit]

Very short-range ships may be powered by accumulator only.

+ simple: easy to set up
- low-powered: available power is very limited.
- fragile: any event prohibiting travel or landing can leave the ship stranded and require an in-person visit
Solar + Accumulator[edit]

Adding solar panels addresses some issues of accumulators.

+ simple: easy to set up
+ low-maintenance: doesn't use any fuel or consume any items
- low-powered: available power is limited.
- bulky: uses a lot of space, and therefore hull integrity
- affected by solar yield: be careful as some areas may not have enough solar energy to power your defenses...
Rocket Fuel Engine[edit]

Switching to Fluid Isothermal Engines uses rocket fuel, but provides continuous power

+ simple: easy to set up
+ continuous power: generates constant power as long as you have fuel
- uses rocket fuel
Steam Battery[edit]

What holds a lot of energy in a small package? Nuclear steam!

+ simple: easy to set up
+ decent energy density
- uses a lot of cargo integrity
- no continuous power: must be frequently refilled with steam
Nuclear - Steam[edit]

Why carry around cans of steam when you can make it on-site?

+ good energy density
+ continuous power: good for long flights and high power usage
- bulky: uses a lot of space, and therefore hull integrity
- must be periodically refilled: condenser turbines only preserve 99% of the water used
- complicated: 2 kinds of fluid, and extra circuitry for efficiency
Antimatter - Steam[edit]

Fission Schmission, let's use ALL the energy instead of just a tiny part.

+ amazing energy density
- bulky: uses a lot of space, but at this point you have integrity to spare
- complicated: 3 kinds of fluid, and extra circuitry for efficiency

Cargo[edit]

Fluid tanks[edit]

Because you don't like having too many barrels

+ easy loading/unloading via underground pipes
+ carry twice as much fluid per stress (25K fluid for 12.5 stress, vs 20 barrels (1K fluid) for 1 stress)
- need pumps to fill or empty quickly
- may be slow depending on number of tanks
- only store fluids
Roll-on trains[edit]

Trains... burning coal... in space... what could go wrong?

+ easy input/output
- scheduling trains on multiple surfaces can be complicated
Logistic chests[edit]

Note: use buffer chests so logistic bots can both load and unload

+ easy loading/unloading via logistic robot
- may contribute to robot attrition
- may need a specialized logistic cell to load/unload completely
- may be difficult to control how many robots travel with the ship when it leaves
Normal chests - direct insertion[edit]

Direct insertion here means either long inserters over the wall or some sort of adjustable inserter mod.
(I recommend the adjustable inserter mod)

+ ...not much
- may be slow depending on inserter throughput.
Normal chests - belts[edit]

Space underground belts can tunnel through the spaceship floor and under the spaceship wall. Don't ask how that's airtight.

+ ... still not much. slightly faster than normal chests by direct insertion? maybe?
- limited belt throughput: 45 items/second with normal space belts.
- (if you're using deep space belts here, you need to think about your life choices)
- takes extra space... like 3-5 times as much space.
Static cargo cars - direct insertion[edit]

A static cargo wagon can be placed on 3 diagonal rails, and including a stack inserter, makes it a minimum of 10 tiles per wagon (if stacked next to other wagons).

+ doesn't use cargo integrity
- uses 5-6x as much space as a chest for its storage size
- can't connect to the circuit network to measure contents
Static cargo cars - belts[edit]
+ doesn't take cargo integrity
+ belts can measure I/O with some complicated combinator circuitry
- belts can measure I/O only with some complicated combinator circuitry
- throughput limited by belts
- takes even more space - like 2-3x as much as direct insertion cargo cars

Engines and Fuel[edit]

  • Spaceship rocket engine: uses liquid rocket fuel.
  • Ion engine: Uses electric power and ion stream.
  • Antimatter engine: Uses electric power and antimatter


Booster tanks and launching[edit]

Some kind of booster tank is required to launch the ship from any orbit, planet, moon, asteroid etc surface. Fuel is subtracted directly from the booster tanks when launching.

  • Rocket booster tanks: Needed to launch the ship, can take off from planets and moons.
  • Ion booster tanks: Needed to launch the ship, can only launch from orbit, asteroid belts, asteroid fields (already in space)
  • Antimatter booster tanks

The engines themselves serve for propulsion once the ship is moving. It's possible to combine different booster tanks and/or different engine types.

Rocket fuel tanks[edit]
+ simple: the standard way
- you brought enough fuel, didn't you?
Rocket fuel liquefaction[edit]

Why not bring the supply chain with us?

+ more dense fuel storage
+ can refuel with minimal planetary facilities
- the fuel plant takes space and power
Vulcanite block-> solid fuel -> liquid fuel[edit]

Why not bring the supply chain's supply chain with us?

+ even more dense fuel storage
+ can refuel with even less remote facilities
- twice the space, twice the power, unless you want to change the recipe manually

Raw vulcanite -> crushed vulcanite -> washed vulcanite -> don't even go there that's too much to put on a spaceship.

Antimatter[edit]

It's safe, I think...

+ amazing energy density
- can't refuel without a space facility and thermofluid

Defense[edit]

Note that spaceships without thrusters will not move fast enough for meteors to appear.

Repairing via Roboport[edit]
+ space efficient
+ lowest risk
- resource intense
Gun Turret[edit]
+ space efficient
- needs refilling
- longer journeys will need bullet stacks
Laser turret[edit]
+ consumes energy instead of resources
- requires a large amount of burst-able energy sources
- requires more turrets for a proper defense than gun turrets
Spidertron[edit]
+ uses no hull space
+ also allows for repairing without a roboport
- uses up chest space

Forcefield generator[edit]
+ sufficiently dense forcefields will stop anything
+ uses no ammo
- each one uses 1MW to stay on, plus 5MW or more to repair damage it takes
- max draw is 200MW (when turning on?)

Automation[edit]

Signal I/O[edit]

The spaceship clamps allow signals to be passed in and out, as well as power supply. There are two anchors to attach wires to: the top corner, which will be passed through to the docked twin clamp, and the bottom of the clamp to which it is possible to control the clamp itself.

Signals to console:[edit]
  • Speed - Tells the ship how fast to try to go. This is useful for regulating power usage on solar-powered ships to make sure there's enough power for the defenses. Recommended methods are either setting the three speeds manually or a math combinator linked to an accumulator (dynamically control speed depending on the power available).
  • Spaceship clamp # - indicates the clamp on the spaceship to use to dock

These two are the only console inputs required to be generated during the trip for automated spaceships. (Note that the example picture on the right is missing the Speed signal without which the ship won't engage.) All other signals are optional. There is no real benefit from using more than one clamp, so use one clamp and put the signal on a constant combinator attached to the console.

  • Destination

The destination signal for a surface can be found in the info box in the universe explorer - it's a signal unique to each zone or spaceship.

  • Launch signal
  1. Launch based on fuel: Useful when you want to pass a signal to take off from outside
  2. Launch based on cargo: Useful when you can wire up your cargo either directly or with a roboport
Using multiple docking clamps[edit]

It is possible to have more than one clamp on a surface with the same ID. The ship will dock to any clamp that is free and enabled. A clamp can be disabled sending the red signal value 1 to the clamp (bottom connector).

Automated Routing[edit]

Note: most of this description is an attempt to replicate some of the Automated Transport features built into vanilla Factorio trains. In particular, if the Improved Combinator mod is updated (it is currently unsupported and doesn't work on spaceships) or someone implements something equivalent, it will simplify much of this discussion, which is otherwise an attempt to implement what vanilla Factorio provides in the locomotive GUI. To be fair, one advantage of SE spaceships over Factorio trains (besides interplanetary travel) is that they are perfectly well-behaved: any number of spaceships can travel to/from any destination simultaneously and any number of spaceships will wait for any clamp to free up. The only concern with a queued spaceship is that it maintain power, defenses and supplies while waiting to dock.

Debug Safety[edit]

An important and useful debugging/safety feature to add to ships with automated routing is a lock-out that disables accidental launch. Simply add a constant combinator with a -1 launch signal connected to the spaceship console input. To enable automated routing (and launch!), turn the constant combinator off.

Onboard Back-and-Forth[edit]

The spaceship will travel back and forth between two specific destinations controlled by logic onboard the ship.

Use two banks of combinators located on the ship. Each bank performs two functions:

  1. Setting the guidance for the destination, and
  2. Determining if the ship is ready to launch for the other location.

Note that the guidance must be a constant signal for the duration of the trip but the launch instruction only needs to be a single tick transient. See the spaceship console section in Spaceship for details on input/output signals.

First, determine how the logic will determine which destination is the next one. The most straightforward case is a ship that will load a single type of ore from one location (planet, asteroid belt, etc.) to transfer it to another location, and then return, possibly with some supplies for the mining base. Suppose the ship will carry 50,000 iron ore when fully loaded. The guidance can be set using a constant combinator outputting:

  1. 999, the destination ID on the correct channel (planet orbit 999)
  2. 222, the ship's clamp ID to dock with (left clamp 222)
  3. 444, the dock's clamp ID to be docked to (right clamp 444)
  4. 100, the ship's target speed if less than maximum.

Feed the output of the constant combinator to a decider combinator that checks if the ship is full of ore, and outputs EVERY if true. Send that signal to the ship console.

For the launch signal, create a bank of decider combinators that tests each desired signal and outputs checkmark=1 if true. Gang the output of the bank of combinators and test if the combined checkmark signal is equal to or greater than the number of signals being added. For example, you might test that:

  1. =333, the ship is at the correct location right now,
  2. Rocket fuel in booster tanks is sufficient,
  3. Stored bullets are sufficient,
  4. Enough ore has been loaded into the ship's storage, etc.

and send = 1 to the console input if true.

The other bank has the same two functions for the return leg. The other guidance signals are set by a constant combinator, which feeds into a decider combinator that tests that the ore onboard is zero, and outputs EVERY if true. Send that signal to the ship console. The console will see only one set of guidance signals depending upon whether the ship is full of ore, or empty of ore.

Similarly, the launch logic can be specific to this other location. Maybe the ship refuels at only one location, so only one set of launch logic tests if the fuel level is sufficient for launch.

Onboard with Multiple Destinations[edit]

The spaceship will travel between a sequence of multiple destinations, in the same order, repeatedly, using logic carried on board the ship.

The back-and-forth logic can be used for multiple legs if and only if the destination can be determined by conditions on board the ship during flight, because the guidance must remain constant during each leg of the trip. For example, an ion engine ship that carries a full load of ore from a mining planet back to a factory planet, but refuels at an orbital platform before returning for more ore can use the following logic to determine which constant combinator sends guidance signals to the console:

  • If the ore is full, pass the factory planet guidance to the console,
  • If the ore is empty AND rocket fuel is not full, pass the orbital platform guidance to the console,
  • If the ore is empty AND rocket fuel is full, pass the mining planet guidance to the console.

In this case, the rocket fuel remains full during the entire trip from the orbital platform to the mining planet, so it can be used to discriminate between the second and third destinations. Here is the logic table for this example:

Destination Ore Rocket Fuel
Factory planet Full Not Full
Orbital platform Empty Not Full
Mining planet Empty Full

The guidance logic will require three decider combinators for each of the second and third cases. Thus, guidance for three stops requires a minimum of 7 decider combinators and 3 constant combinators. In the special case where a fourth destination happens to be the missing Boolean case (Ore Full, Rocket Fuel Full), the four stops require 4*3=12 decider combinators and 4 constant combinators. If another signal needs to be used it will have a multiplicative effect on the number of required combinators.

External Guidance Using Onboard Memory[edit]

The ship's next destination will be set by logic external to the ship prior to its launch.

An arbitrary route can be implemented using memory cells on the ship to hold the guidance signal for the destination, where the memory is overwritten at each stop. The launch logic is also implemented for each stop at that stop.

The minimum number of memory cells required is one cell for the docking clamp ID at the destination and one cell for each destination type the ship will visit (planet, planet orbit, moon, moon orbit, star, asteroid belt, asteroid field). For example, a ship that travels between two planets, both planets' orbits and an asteroid belt will require four memory cells (docking clamp ID, planet ID, orbit ID, asteroid belt ID) on the ship. Guidance signals that are required but don't change can be fed to the spaceship console by a separate constant combinator. These probably include the ship's clamp ID and the maximum speed. If the ship will use different onboard clamps at different destinations, or will use different speeds for different legs, those signals will also require their own memory cells.

If using the Factorio wiki Positive and Negative Cell, use a timer at the stop to send a momentary reset signal to all memory on the ship when the ship docks. Send the ship speed =-2 signal ("Anchored") from the ship console output through the clamp to start the timer. While timer is counting up to a short value (60 ticks = 1 second), send the reset signal back through the clamp. The Factorio wiki Basic Clock can be used as the Reset timer. While the timer is counting up, send R=1 to the reset input on all the memory cells. When the timer stops the memory cells will set to the new guidance signal values provided by an external constant combinator sent through the clamp. Note that destination types will be zeroed out automatically if they are not included in the new guidance.

For example, before arrival at this stop the ship's memory is set to:

999 333

while is zeroed out ("holding" a value of 0). The ship docks to 333, which starts the Reset timer.

When the timer ends, the stop's constant combinator sets the ship's memory cells for the next destination:

888 336

and now is zeroed out.

The launch logic is also implemented at each stop. See the preceding Onboard Back-and-Forth section on onboard launch logic and implement it externally at the stop. The launch signal is sent through the clamp to the ship console.

To repeat and summarize what happens at each stop:

  1. A constant combinator with the new guidance signals for the next destination is connected to the dock clamp,
  2. When the ship docks, the = -2 "anchored" signal triggers an external timer that briefly sends a reset R=1 signal back through the clamp,
  3. Onboard memory is reset, with unused destination IDs set to zero,
  4. The next destination guidance information is set in onboard memory for the next leg of the trip,
  5. External logic determines when the = 1 launch signal is sent back through the clamp.

Conceptually, the guidance logic could be implemented at another location entirely and transmitted using AAI Signal Transmission. The stop would only reset the ship's memory and send the guidance transmission at the signal receiver through the clamp. Maybe the signal receiver could be onboard?

Because there is no explicit space constraint at the stop (unlike the ship), much more complex logic can be used to determine when to launch. A timer can be used as a launch condition to allow the ship to loiter at the step for a fixed period of time before launching. This is useful for legs where the ship is supposed to carry supplies to the destination but those may be arbitrary. The ship will leave at a fixed time bringing whatever was loaded before the timer finished.

Finally, with onboard memory complex conditions can be implemented where the ship is dispatched to a destination with a specific cargo depending upon circumstances. The ship is sent to a pickup location where the intended cargo is waiting. The cargo is loaded and the destination is set in memory. The ship launches when the loading is complete, or perhaps when it receives an explicit launch signal because the cargo is now needed at the destination. When the cargo is offloaded, the ship can be sent to pick-up another cargo at another location, or returned to a supply base until needed, and so forth.