Song of the Labyrinth: Exploration is an experimental scenario OXP for Oolite, set in a very different part of space, and a considerably lower-tech environment than the Oolite setting.
- 1 Overview
- 2 Download
- 3 Equipment fitting
- 4 Hyperspace
- 5 Version History
- 6 Musings
- 7 Links
The colony ship Local Maximum suffered an extremely severe hyperspace misjump around seventy years ago, arriving in an uncharted system thousands of light years away from known space. The colony ship's hyperdrive was severely damaged, and the dim red star they named Max's Drift had no habitable planets and poor mineral reserves. Most of the ship's internal equipment survived the accident, and the colonists have been able to survive using hydroponics facilities and extracting water and metals from the system's asteroids.
Mining has recently obtained a small surplus of Uranium and Osmium required for the production of hyperspace fuel, and a cargo shuttle has been extensively refitted to carry a small hyperdrive and a range of survey gear. Its initial task is to survey the local cluster, hoping to find minerals which so far have not been located in exploitable quantities, both to restock the colonists' reserves and to allow fuel and equipment to be produced for a more extended mission.
This is an OXP which uses the Oolite engine to make a game based on exploration rather than on combat and trading. The player starts off in the centre of the map and explores the surrounding systems visually and with a range of sensor tools. Implemented so far: Basic multi-planet system maps (much more to do here) Hyperspace is its own thing rather than a cut-scene tunnel More realistic (though still somewhat adjusted) system scale Basic planetary detection and parallax searches Gravitational sensors to measure planetary mass, and detect planets beyond visual range
There are 3 files.
- The Exploration OXZ (SOTL_Exploration_0.4)
- The Loader OXZ (Song_of_the_Labyrinth_Startup_1.1)
- And Altmap (Song_of_the_Labyrinth_Altmap_1.0) - see SOTL Altmap for details of this second scenario
As this is a scenario OXP which changes many of Oolite's basic rules, it is disabled in conventional Oolite games, and requires the starting of a new game from a special position to play it. This position is available in the SOTL Loader/Startup OXP (for technical reasons this must be downloaded separately).
None of your normal OXPs will be usable in a SOTL Exploration game.
For more information, see the forum thread
This is an experimental OXP, and the Startup OXP may need to be updated if the main OXP is - which will mean you lose any progress (and of course, you also have to use a nightly Oolite build). Comments during development are extremely welcome but don't get too attached to your progress yet.
The Shaula-class survey ship you fly can carry ten modules (in addition to the generator and flight computer which must be carried). The initial fitting is 3 fuel tanks, 3 capacitors, 1 gravity sensor, 1 spectroscopic sensor, and 1 prospecting laser, though you can customise this as much as you like before you leave.
The flight computer provides navigation support in both normal space and hyperspace, and integrates the output from your ships sensors - without it, you will have to carry out many more tasks manually, and you are recommended to return to base immediately for repairs.
It will automatically mark planets once you approach closely enough to get accurate information on their position and speed, and give them a preliminary designation. Information about the currently selected target will be displayed on your HUD
It has three primable modes:
- bookmark: place a waypoint at your current location and heading. Useful if you spot something interesting but can't immediately check it out. Only one bookmark can be used at once.
- lagrange: places a waypoint at each of the 5 Lagrange points of the currently selected planet. Both the planet and star must have mass estimates recorded for this to work. The L4 and L5 points are stable and may contain small clusters of asteroids.
- engine mode: switches the engines between "precision" and "cruise" mode. Cruise mode is significantly faster and will generally be used, but precision mode will make flying near asteroids and docking with the Local Maximum considerably safer. You must be stationary to switch engine modes. The HUD's speed bar will indicate either pn (Precision mode) or CR (Cruise mode).
Fuel tanks carry hyperspace fuel. Each tank carries 6 tonnes of fuel. A hyperspace jump consumes fuel in tonnes equal to the square root of its distance in LY (i.e. longer jumps are more fuel-efficient). Exiting a jump early will not save fuel. The only current source of fuel is the Local Maximum - plan your jumps carefully or risk being stranded in another system forever.
Capacitors store energy from your generator to provide boosts to particular energy-intensive systems such as the lasers and hyperdrive. The more you have, the more margin for error you have in carrying out tasks, and the longer hyperspace jumps you can safely carry out.
The gravity scanner allows the mass of nearby stars and planets to be estimated. If multiple gravity scanners are fitted, they are used in parallel to provide more accurate readings. You must be at a complete stop to use it. You may turn with it in use, but this will interfere with the readings.
Use the mode key ('b') to cycle between the four modes of operation, and press 'n' to activate the current mode:
- power on/off: initial mode, you must switch it off to re-engage drives
- scan on/off: while scanning, it will collect gravitational data, giving you the intensity and direction of the net gravitation force (in the screenshot, below and slightly ahead of the ship). The longer the scan runs for, the more precise a reading you'll get. You can turn the ship while the scan is running, but this will affect the data quality and you'll then need to wait a little bit for it to settle. Once you're happy with the data collected, press 'n' to stop the scan
- assign scan: assigns the scan data to the selected compass target (you need to pick for yourself what object you believe to be the gravitationally dominant one). The system will filter out components of the gravitational force not parallel to the direction of the target, and then use that to calculate surface gravity
- filter scan: if you already know the approximate mass of an object from a previous scan, you can filter it out of the scan by selecting it with the compass and pressing 'n' in this mode. This lets you get more accurate readings for unmeasured objects, and with sufficient practice and luck can also help you find undiscovered planets.
What are x,y,z? Where are they measured from?
Relative to your ship and its current axis set.
Why are they only positive?
They are not: there's an implicit zero-mark about half-way up the scale.
So if you turn your ship so that the X and Y are about half-way up, and the Z is all the way up, then the gravitational source should be in front of you. (On arrival in a new system, the dominant gravitational force will be the star, so this should be easy to verify!)
And what is the significance of all those "G" 's?
That's the gravitational field strength at the current location - minus any gravitational fields from previously-identified bodies.
How does one use this equipment to find planets?
So, to find planets:
- - get reasonably close to the star, turn to face it, verify that the grav sensor has the half-half-full XYZ readings mentioned above
- - set the star on the compass, assign the scan
- - now filter the scan to exclude the star
- - the high-unit (Gs, milli-Gs) of the grav scan should drop out
- - and you should have a new direction for the next most dominant gravitational source
- - turn to face that using the XYZ scans
- - then set off in that direction
- - hopefully after a while you'll come across a planet
Now you can repeat the process - do another G-scan, and you should get a pretty high milli-G reading when near the planet. Assign the scan, filter out that planet, and then see what's left to find a second planet. Eventually you'll have filtered out all the major gravitational sources, and your gravity scan will just be returning noise in the pico-G region. At that point you've probably found all the planets. cim » Thu Mar 03, 2022 9:17 am
Spectroscopic scanner and prospecting laser
The spectroscopic scanner lets you determine the composition of stars, planets and asteroids by measuring emitted or reflected light. It returns the relative amounts of ten elements or compounds of particular survey interest, on a logarithmic scale.
To use it, point your ship at the thing you want to scan, target it with compass or ident as appropriate, activate the sensor with 'n', and cycle the mode to the correct scan (star, planet or asteroid) with 'b'. Then, activate the scan with 'n' and watch the composition bars climb.
If the target is an asteroid, you'll need to fire the prospecting laser to get anything decent out of the scan.
When the scan looks done, press 'n' again to stop the scan and assign the results to the targeted body. Stars and planets are targeted with the compass; asteroids with the ident system.
Try to stop the scan when the highest of the ten bars reaches the top but no later. Stop too soon and you'll not have collected enough light and may miss some important trace components or have inaccuracies in parameters; stop too late and you'll oversaturate the sensors and corrupt the result.
The bars will go up faster the closer you are to the object, which reduces measurement noise - as does fitting multiple units - though this must be balanced against the risk of oversaturation.
You get different information depending on what you targeted
- Stars: brightness, and metallicity. Metallicity gives you a very rough idea of how likely the system is to be dense in heavy elements, based on the traces of them in the corona.
- Planets: surface temperature and atmosphere type
- Asteroids: mineral composition (there are a lot of potential minerals, so there's two scan types). Any minerals detected in exploitable amounts will be noted on scan completion - the threshold is a lot lower for the rare ones.
Sampling laser and sample collection bay
The sampling laser will break small chunks off an asteroid - ideally one you have previously scanned with the prospecting laser - which can then be scooped into the sample collection bay and returned to the Local Maximum for extraction of valuable minerals. Each collection bay will hold 15 samples. (On particularly mineral-rich asteroids, a single sample may contain multiple usable minerals)
Wreckage, Silicates, Ice and Ores
The list of commodities on the F8 commodities screen is adumbrated by the F8F8 entry for each item - so there is no current need for ice, but there is for Uranium, Rhenium, etc.
Hyperspace travel is dangerous - especially in a ship as improvised as the Shaula-class. When you activate the hyperdrive, an additional instrument display will be projected on to your HUD
- Above: progress to destination ("travelling"). This starts with you leaving the gravitational influence of your current system, then travelling through hyperspace, then entering your destination system. If you need to drop out mid-jump, this will determine where you end up.
- Right: current energy reserves. Hyperspace travel is energy-intensive. If you run out of energy mid-jump, your ship will be destroyed as it fails to maintain hyperspatial integrity. You can press 'h' again to abort the jump and drop out away from your destination, which will damage your ship due to the rough exit, but you should at least survive.
- Centre: jump status. If this is yellow or green the jump is going well. If orange, you are losing energy fast but should have sufficient reserves to finish the jump. If red, you do not have sufficient reserves at the current rate of energy loss to complete the jump (this will start flashing red/black if you have fewer than 5 seconds available)
- Left, bottom: jump alignment. You need to handle a lot of the jump yourself. Keep your yellow marks aligned with the moving green ones using your pitch and roll controls - the closer the alignment, the less energy you will need to maintain hyperspatial integrity.
The pattern you need to align to is a property of the particular jump you are making, so with practice you can use less energy. Additionally, the more times you complete a jump the more computer assistance you receive with future jumps on the same route, which reduces the precision needed to maintain energy levels. (This means you need to carry fewer energy banks and can carry more survey equipment instead)
Jumps are non-linear: - time aligning in hyperspace needed to complete the jump is proportional to distance - real time taken is proportional to distance squared - fuel usage is proportional to the square root of the distance
As large masses travel through normal space, they leave ripples behind them in the hyperspace medium, and semi-stable calm points. The larger the mass, the better the calm point. For this reason, a successful jump will place you in the calm point for the system's star.
See the BB Discussion thread for Cim's 2021 notes about what he had hoped to add.
- 0.4: added sampling laser and collection bay, adjusted HUD to be easier to read when facing star
- 0.3: added spectroscopic scanner, asteroids, prospecting laser
- 0.2: first public release, added gravity scanner, stars, planets
- 0.1: unreleased, hyperspace changes only
Cim's original plans for the future development of this OXP (or, what's missing!)
- A nicer cockpit/HUD.
- The longer-term idea was that your home base would only have a limited amount of hyperspace fuel - large, but not infinite.
- You'd then need to locate and mine particular materials from asteroids which could be synthesised into fuel back at the home base.
- While doing that you'd also be picking up other raw materials, which would let your home build additional equipment
- First basic one would be a mining drone which attached to an asteroid and started doing (slow!) automated mining of it. Build a few of those and you can start to get minerals in a bit faster. You'd have to give up a lot of your storage space to drag it out there in the first place, of course.
- That would then unlock additional deployable modules - a basic fuel storage depot, which would let you move fuel out from the base ship, and then run bigger expeditions from there - and then later a portable fuel refinery which would mean you didn't have to transport mined materials all the way back to base to get more fuel
- Probably then another sort of drone at some point which would pick up gas/liquid elements from planets for you, which would then extend the range of things your base could construct ... as well as resupply oxygen on the base ship, and other large-but-not-infinite consumables
- Goals: As well as modules for you, also goals to supply materials to repairs on the base ship
- Eventually, then a long-term goal to repair the base ship entirely (including its hyperdrive), and gradually move it across the chart to one of the habitable planets you found while exploring for the rest of this. (And then you've "won" but obviously you can keep exploring the rest of the map, with the benefit that you no longer need to keep dragging oxygen and water and minerals to your base)
I have no objection in principle to what there is being put in the Expansions Manager, maybe someone else will finish it off / take it in another direction someday.
But ... one reason I didn't put it in the manager is that Exploration depends on Loader, so if you install Exploration, you get the Loader OXP too (Song_of_the_Labyrinth_Startup). Loader can't depend on Exploration, because if it did, Exploration won't load in the core scenario, and then Loader won't load because Exploration isn't there, and then you can't actually start the scenario game. But that means when you're installing from the manager, if you install Loader it can't then auto-install Exploration ... and then if you try to run Loader it'll probably go wrong with an entirely unhelpful error message
The manager ideally needs a new relationship type adding to handle that sort of "install-time but not run-time" dependency, but I never got round to that either.
You might be able to make this clear enough with descriptions.
There seem to be three major points about this .oxp/game/proof of concept.
1) It is genuine exploration within the Oolite game framework. Although the map is known (ie the location of the stars), one must "discover" how to make the jump, and discover what is at the other end (planets, asteroids, etc). And as the only pilot, there is nobody else about to spoonfeed you the information!
2) The Hyperspace Jump is no longer a doddle - it's now an adventure! It now starts to resemble what one reads about in some of the science fiction.
3) Finding the planets is now an adventure too!
Since cim programmed this within the Oolite game framework, some of these ideas should be transferable to the main game for those with the skills.