Ship Log
Understanding Ship Logs
First thing’s first, I’ll define some terminology regarding ship logs in the game, and how ship logs are structured.
Entries
An entry is a card you see in rumor mode, it represents a specific area or concept in the game, such as Timber Hearth’s
village or the southern observatory on Brittle Hollow.
An entry is split up into facts, a fact can either be a rumor fact or an explore fact.
In red you can see an entry, in green you can see the entry’s facts
Curiosities
Curiosities are entries that represent big ideas in the story, such as the ATP or the OPC.
Non-curiosity entries have a Curiosity attribute that can be set to make the color of that entry match the color of the
curiosity (Like how everything regarding the Vessel is red)
The Ash Twin Project is an example of a curiosity (internally it’s called TIME_LOOP)
Child Entries
Entries can be children of other entries, meaning they’ll be smaller.
The murals at the old settlement on Brittle Hollow are examples of child entries
Rumor Facts
A rumor fact represents the information you might hear about a specific area or concept, usually, you get these through dialogue or maybe by observing a faraway planet.
Explore Facts
Explore facts represent the information you learn about a specific area or concept.
The XML
Now that we know some terminology, let’s get into how the XML works.
Every planet in the ship log is represented by a single XML file, you can see this if you use the unity explorer mod and
navigate to ShipLogManager.
Example File
Using The Schema
In the example XML, you may notice something like xsi:noNamespaceSchemaLocation
at the top, this tells whatever editor
you’re using that the file at that link is the schema. The game simply ignores this though, so it won’t be able to catch
errors at runtime.
Some editors may require you to Trust the workspace to use
the schema file. Doing this varies per-editor, and you may also have to right-click the link and click download.
Loading The File
You can load your XML file to your planet by doing adding the following to your planet’s config
Rumor Mode Options
Entry Layout
By default, entries in rumor mode are laid out by rows, where each row is one planet. This will not make for a perfect
layout, so you can use the entryPositions
property in your star system config to change them.
For example, if I want to change an entry with the ID of EXAMPLE_ENTRY
and another with the ID of EXAMPLE_ENTRY_2
:
To help with this, download the unity explorer mod and manually position entries (they’re located under Ship_Body/Module_Cabin/Systems_Cabin/ShipLogPivot/ShipLog/ShipLogPivot/ShipLogCanvas/MapMode/ScaleRoot/PanRoot
), then simply use the dev tools to dump all the entries to a json string you can copy and paste into your config.
A set of entries laid out with auto mode
Images
Custom entry images are a bit different from other custom images, instead of pointing to each file for each entry, you point to a folder:
Each file is in this folder is then named the ID of each entry.
for example, EXAMPLE_ENTRY
’s file would be named EXAMPLE_ENTRY.png
.
you set alternate sprites by making a file with the entry’s ID and _ALT
at the end, so EXAMPLE_ENTRY
’s alt image
would be EXAMPLE_ENTRY_ALT.png
.
Curiosity Colors
Colors for each curiosity is given in a list within the star system config, so if I wanted the curiosity EXAMPLE_ENTRY
to have a color of blue:
The curiosity’s color is changed to blue
Map Mode Options
Layout
Layout in map mode can be handled in two different ways, either manual or automatic, if you try to mix them you’ll get
an error.
Also, adding planets to the vanilla solar system requires you to use manual layout.
Automatic Layout
In automatic layout, each planet that orbits the center of the solar system is put in a row, then, each planet orbiting those planets are put in a column, then, each planet orbiting those planets are put in a row for as many planets there are. The order of each planet is determined by their semi-major axis, if two planets have the same semi-major axis then they’re sorted by order loaded in.
An example system laid out with auto mode
Offset
The offset
option lets you adjust a planet’s offset from the last planet.
For example, this offsets example planet in map mode by -5 units.
Manual Layout
The manual layout is a lot more involved than automatic but offers much greater freedom.
Manual layout requires you to fill out both manualPosition
and manualNavigationPosition
Manual Position
Setting the manualPosition
option in the mapMode
object sets its position (if manual position isn’t set, it assumes
the planet is using automatic mode)
Manual Navigation Position
This setting tells Outer Wilds how to handle navigation for this object, the x and y values correlate to the row and column of this planet. For example, the sun station is at navigationPosition (0, 1) as it is in the first column on the second row (you can’t select the sun, so it doesn’t have a row or column). So, by making a navigation position of:
We say this planet is to the right of the sun station (putting in a position that is already occupied will override what is in that position).
Overriding Vanilla Planets
You can also move vanilla planets by creating configs with their names and changing their manualPosition and manualNavigationPosition
Settings for both layouts
These settings can be used for both type of layouts
Sprites
Reveal Sprite
A path to the sprite to show for when the planet is revealed
Outline Sprite
A path to an outline to show for when the planet is undiscovered
Invisible When Hidden
Settings invisibleWhenHidden
to true makes the planet entirely invisible when not discovered instead of showing an
outline.
Scale
How much to scale this planet in the map mode screen (you may have to change offset to compensate)
Shrinks the planet by one half
Remove
Don’t include this planet in map mode at all, simply ignore it
Details
Details are images that go on top of a planet in map mode, and changes states with the planet (like the sand funnel between Ash Twin and Ember Twin)
As you can see, they have similar properties to planets, with the addition of rotation
Revealing Facts
Of course, having a custom ship log is neat and all, but what use is it if the player can’t unlock it?
Initial Reveal
You can set facts to reveal as soon as the player enters the system by adding the initialReveal
property to your star system config
Signal Discovery
You can set a fact to reveal as soon as a signal is identified by editing the signal’s reveals
attribute
Dialogue
You can set a fact to reveal in dialogue with the <RevealFacts>
tag
Reveal Volumes
Reveal volumes are triggers/colliders in the world that can unlock facts from a variety of actions.
Reveal volumes are specified in the Volumes
module, its key is revealVolumes
.
Position
The position of the reveal volume, relative to this planet’s center
Radius
How big the collider is (use the collider visualizer mod for help)
Reveals
A list of facts this volume reveals
Reveal On
Can be any of the following:
Enter
When the player or probe enters the trigger, reveal the facts
Observe
When the player observes the trigger, reveal the facts
Snapshot
When the player takes a picture of the trigger, reveal the facts
Max Distance
Can only be used if revealOn
is set to Observe or Snapshot, the max distance away the player can be and still be able
to trigger the reveal
Max Angle
Can only be used if revealOn
is set to Observe, the max angle the player can be looking away from the trigger to still
trigger the reveal
Example
Setting Entry Locations
Entry locations are the “Mark On HUD” option you see when in map mode, this allows the player to go back to where they
were in the event of the big funny.
Adding an entry location is similar to adding a Reveal Volume:
Extending Base Game Entries
You can add new facts and sub-entries to existing ship log entries by adding a dummy entry to your ship log XML file with the same ID as an existing entry. Any facts and sub-entries will be applied to the existing entry. For example, to extend the “Village” entry on Timber Hearth (which has the internal ID “TH_VILLAGE”):