Hard Way

This OXP is oriented to player, seeking more complex and more challenging game rules. It will be a bit confusing to new players, so I recommend trying Hard Way only when you are fully familiar with the Vanilla game rules.

Overview

Hard Way contains four modules, greatly altering the game mechanics:

• Collapsible Shields and Fuel Consumption: everything consumes energy - and using the Torus drive now reduces one's shields.
• Gravity Well: the planetary and lunar gravity wells now exist - and inhibit Hyperspace/Witchspace jumps.
• Solar Wind Scoop: allows scooping solar wind flux to compensate for everything now consuming energy.
• Warp Drive: speedier and speedier torus drive when not affected by local gravity, but manoeverability is inhibited and recency of maintenance is now vital.

Collapsible Shields and Fuel Consumption

This option was initially intended to compensate game imbalance. NPCs never use the Torus drive! It is too easy to force an NPC opponent, equipped with witchfuel injectors, to burn up all his fuel: just let him go off scanner range and pursue him with Torus drive. This works well for the Constrictor hunt mission: fire, chase the poor bastard with Torus drive, fire and chase again, repeat until he's consume all his fuel, close with your own fuel injector onto his 6 o’clock, and then give him the coup de grace.

Chasing with the Torus drive works well because your fuel reserve remains almost untouched until final phase of strike and also because you are ready for battle instantly just after mass-locking.

But if you need some time to prepare your ship for battle after cruising on high velocity Torus mode this all becomes very different - and in some aspects a more realistic game setting.

This module decreases the Forward/Aft shield levels to 1/4 of their normal level (ie: red/yellow border level) while in Torus drive mode. Flight now becomes a bit risky: the recuperation of your shields after mass locking now takes time (approximately 45 seconds for a Cobra Mk III without an extra energy unit). It is now a good idea to wait for complete shield recharging before attacking enemy ships! And it also now a good idea for a green Jameson to use the Torus drive very carefully! So the skills of visually observing any potentially dangerous targets beyond scanner range become extremely helpful.

In vanilla Elite/Oolite you have an unlimited source of power for ship systems. You spend fuel only for hyperjumps or for witchfuel injectors. You have a completely functional ship even when the fuel tank is empty. You can fight, you can continue to patrol space without any time limit.

With this module fuel is consumed in cruise mode by the core energy unit to provide power for the ship systems. If you burn up all your fuel (7 ly), your core energy unit will shut down and the ship will switch to an auxiliary energy unit. The shields will be disabled and the energy banks will be set to minimal power consumption. The main engine will also shut down and you’ll have only an auxiliary engine, restricting your max speed to 0.5 of normal max speed. You’ll have a chance to reach a safe station, but your chances to win combat in such condition will be virtually nil.

Rate of fuel consumption depends on ship state:

• In economy cruise mode (speed below the red zone in the Vanilla game HUD) the fuel consumption rate is 0.1 LY per 6 min (
• In fast cruise mode (speed within the red zone - approx. 80…100%) the fuel consumption rate increases to 0.1 LY per 3 min.

The Vanilla game HUD fuel bar is green between 0 - 25%, yellow between 25 - 80%, and red above 80% of maximum speed.

• Additional fuel is needed to maintain the functioning of the gravity field compensator while in mass-lock state (ie. Yellow and Red Alert. Total fuel consumption increases to 0.1 LY per 3 min in economy cruise mode and 0.1 LY per 2 min in fast cruise mode).
• Flight with Torus jump drive also requires extra fuel (total fuel consumption 0.1 LY/min).
• Additional fuel consumption is needed to recharge the energy stack (energy regeneration after an enemy hit or a collision, firing the ECM and ore processing).
• An attempt to use the Torus jump drive after burning up all fuel leads to a dramatic loss of energy and… Uh-oh! Press Space, commander!
• You have limited time to reach a station using your auxiliary unit. Press Space, commander, after auxiliary unit depletion! Or pull the hard Eject lever (I mean hit the E key twice, of course!) before the auxiliary unit shuts down, and continue the journey on board your escape capsule, if you have this device.

I think the fuel consumption rate is reasonably game-balanced: in Green state you have 7 hours patrol time in system with a full fuel tank and 3 extra hours patrol time with one extra fuel tank. The route from the entry witchpoint to the main station without using the Torus drive typically takes approximately 30…45 minutes - 0.5…0.75 LY of fuel in Green state or 1.0...1.5 LY being mass-locked by system traffic in Yellow Alert state. Not an unacceptable large value (you will need an extra fuel tank to reach a station after jumping a 6.8 LY distance, of course!).

Gravity Well

In post-Elite space sims interstellar travel is often realized using a network of permanent wormholes or artificial portals, so you need to travel from the planet or spaceport to some point in system to depart. There are usually several such wormholes in system, connecting it with the neighbours. In Elite and in Oolite we have ships equipped with an autonomous hyperdrive. So you don’t need to navigate for departure. Just leave the proximity of the station (approx 10 km in case of Coriolis) and hit H to initiate the hyperjump sequence.

Seems a bit illogical. A relatively small station mass can completely abort hyperjump, but the huge mass of the planet has no effect (OK, I know, planets don't have any mass in Oolite).

The Gravity Well module changes game mechanics by simulating a gravity field distortion in the proximity of celestial bodies. Attempt to hyperjump below a safe altitude can cause fuel leakage, cargo/equipment damage and/or a misjump. The probability of malfunction increases as a function of diving into the gravity well (less altitude – greater chance of misjump).

The upper boundary of this gravity well influence (gravity well horizon) in the case of a planet is equal to its mass-lock radius (H = R). In the case of a moon's gravity well, this horizon is H = R too, but due to the hardcoded minimal mass-lock radius for moons, the 25600 m gravity well horizon will be inside the mass-lock radius.

For safe departure from the main station, climb above the station and then activate hyperjump. For safe departure from a planet's spaceport climb to leave the planet's mass-lock zone.

The default altimeter dial is useless for locating the gravity well horizon of the nearest celestial body. It merely helps discern mass-locking caused by the planet from the mass-locks caused by ships and stations. There is now no useful information from constantly watching a completely filled altitude dial, right?

Watch carefully for altimeter dial before hyperjump countdown activation. In the case of hyperjump countdown activation below the safe altitude, abort the countdown by repeatedly pressing the H key, then climb to a safer altitude and repeat the hyperjump activation.

You can safely follow another ship's wormhole in the green altimeter zone (AIs often jump below the mass-lock horizon), but the general rule is to avoid hyperjumping below the safe limit. Actually, there is a small margin of error below the gravity well horizon for safe hyperjumping – but it is not too wide.

A Customised altimeter data source has been added: the altitude is now calculated as a ratio of the planet's or moon's radius instead of the default fixed 40,000 m scale (4000 km in planet scale). See more details under Custom Altimeter Mode below.

An additional digital altimeter provides altitude data in a range from 2500 to 500 km on the planet scale. It intended to provide safe planetary landing and works only during descent to minimize interference with other messages.

Solar Wind Scooping

Sun skimming in vanilla Oolite seems to be an exotic ritual in the game. Almost all players try to do it just for curiosity ... and almost all players never use it in the regular game. Fuel is cheap and always available in (almost) any space port market, so you only have an urgent need for the risky voyage to extract fuel from the sun's corona if you are persona non grata on main station. You understand me, gentlemen.

Solar Wind Scoop compensates the perpetual fuel consumption of the first module above by collecting the Solar Wind Flux in the proximity of the sun (the minimum solar wind flux to allow this is 0.1 LY/min). Sometimes during solar flares, solar wind flux exceeds this minimal value even en-route from the entry witchpoint to the main orbital station - but as a rule you will need to journey closer to the sun to fill your tanks. Not as close and as hot an encounter as required for sun skimming. 5...10 solar radii will be sufficient. Solar wind collection is a fully automatic process, you only need Fuel Scoops installed. Once the solar wind collection has started you’ll see icon of the fuel scoop indicator on your HUD animate - and hear the usual “champing” noise.

To find information for the value of the solar wind flux in your area of space, lock your Advanced Space Compass onto the sun and switch an MFD onto the Sun Info page (Useful MFDs also gives this value now that Dybal has tinkered with it).

Pay attention - solar wind collection is possible only while you are in normal cruise mode and in Green Alert condition, not in Torus drive mode nor in WFI (afterburner) mode! The solar wind flux readings on the MFD will be zero if you are mass-locked in Yellow or Red Alert.

Warp Drive

Well, this module was initially written as a standalone OXP, but it is best suited for additional changes of the ship's dynamic properties in conjunction with the above.

The main function of this module is providing a high velocity engine mode for the exploration of vast new solar systems, available since Oolite 1.82. If player's ship is beyond a range of 25 radii from the sun - and of 25 radii from the nearest planet - and flying on the Torus drive, the ship's speed is multiplied up by a warp factor which varies with the distance to the sun, expressed in sun radii. So unlike the “quantum leaps”, implemented in Norby’s Far Planets / Torus to Sun, you now enjoy smooth movement.

It takes only several minutes now to reach any object in the solar system using a warp drive in clear space (actually you’ll have occasional mass-locks with OXPs such as Deep Space Pirates or Deep Space Dredgers). Warp mode activates automatically in Green alert state and is aborted if any entity is detected in the proximity of the ship (scan range proportional to warp factor), preventing accidental collisions with ships or asteroids (but the jump drive remains working in the case of asteroids!). This option was borrowed from Norby’s Far Planets / Torus to Sun.

To abort warp mode manually just press J to switch OFF Torus drive.

The bars indicating Shield Energy turn OFF while the Torus drive is activated and ON when the Torus drive is deactivated. You can therefore use it to check your Torus drive status in the case of manual deceleration. It takes several seconds to decelerate from warp velocity in the case of manual Torus mode deactivation, so don’t use manual Torus drive shut down if you have planet, moon or station on a collision course! It is quite safe to allow the Warp drive to switch off automatically.

Additional functions of Warp Drive module

• Player's ship turn rate in torus/warp mode is now an inverse proportion of the velocity/speed.
• The turn rate for yaw is now set to 1/4 the turn rate for pitching.
• Player ship's maximum speed, thrust and energy recharge rate depends on the ship's technical state.

Some explanations for these changes

Turn rate vs velocity

The turn rate in the vanilla game seems to be independent of the ship's velocity. For a Cobra Mk III on full throttle, with full joystick deflection on the pitch axis: a complete loop takes 6 s – approximately 1 radian/second. For the same Cobra Mk III at Torus x32 speed, with full joystick deflection… The same 1 radian/second.

Well, I can agree with the argument that “ship movement in Elite/Oolite is not Newtonian movement – it is surfing on a wave of space curvature without huge inertial moments”. The flight model in Oolite is extremely simple. But we can modify it to make the game feel more realistic.

There is Wildeblood’s Bullet Drive OXP with maneuvering completely disabled in Torus drive mode. It’s consistent with original Elite lore, but seems too radical. So I’ve realized my own solution. One still has the ability to readjust course to avoid most mass-locks with Deep Space Dredgers – these huge ships are visible from enough distance to react before mass-locking.

Turn rate in yaw/pitch channels

One can use both max_flight_pitch and max_flight_yaw parameters in the shipdata.plist, but usually the last is omitted and by default is equal to max_flight_pitch. It seems that the NPCs never use the yaw channel to change their own flight direction. It also seems also that some human players never use the yaw channel either: but for players with a joystick with a twisting z-axis there is an easy way to do it.

A default max_flight_yaw equal to the max_flight_pitch seems to be too sensitive, especially for a joystick. Reducing the player ship’s turning in the yaw channel helps to ease precise aiming without switching control sensitivity. Too high a rate of turn in the yaw channel also contradicts my own perceptions, based on piloting a real glider in reality – turning an aircraft without banking is an extremely ineffective manoeuver compared with a more coordinated turn incorporating a roll.

Ship dynamics as function of technical state

The so-called serviceLevel parameter is mostly hidden from the player. Starting from a value of 100 it gradually decreases with every hyperjump to 75 and remains frozen at this 75 value until the next renovation/maintenance servicing of the ship. The only visible effect is the decreasing sales price of the ship.

WTF, why I must pay 1...1.5% of ship price (1500+ credits for Cobra Mk III!) for just a cosmetic renovation if I don’t have plans to sell my ship now or in the nearest appropriate system?

Well, serviceLevel affects malfunction probability too: so in real reality you’ll want to invest in your own security if misjumping – sooner or later due to poor maintenance – is not your favoured option. But in the game you always have the save/load option. So an increased malfunction probability is not enough motivation, and I know players who never spend money for a ship maintenance overhaul. The situation will be different if ship performance will be a function of the ship's technical state.

If you have a vanilla Cobra Mk III, for example, it has maximum speed of 350 and an energy recharge rate of 4.0. The ship technical state degrades over time from an initial 100 points to 75 points. The maximum speed of unmaintained Cobra is now reduced to 328, the energy recharge rate to 3.5. Wear & tear effect also affects the fuel collection rate. If you have fuel collection rate of 1.0 LY/min in a vanilla Cobra Mk III, the fuel collection rate of a highly used Cobra now drops to 0.8 LY/min.

Next example, maybe more obvious. You just switched from your old good Cobra Mk III to a Cobra III XT. She is pretty: max speed 375, thrust 36 and energy recharge rate 4.5. Well, if you’ll avoid regular maintenance, its performance will degrade to a speed of 352, thrust of 32 and energy recharge rate of 3.9 – almost similar to a regularly maintained Cobra Mk III. So the only your advantage in battle will be an energy capacity of 320 instead of 256 – and maybe the 6 missile hardpoints instead of 4.

Commander Jameson, the Ooniverse is not as friendly personally to you as you like to think. Do regular maintenance to restore your ship's maximum performance!

Custom Altimeter mode

Default altimeter dial has fixed range 0...4000 km in planet scale (0...40,000 m in game units). Not suitable for main planets with radii range 2800...6900 km. In latter case you have 2900 km dead zone – no any useful readings of altitude. Large additional planets are the worst case. Having planet with 16,000 km radius you’ll have 12,000 km dead zone – almost ten minutes of flight on full thrust for Cobra Mk III without any useful altitude readings.

This optional mode allows display of altitude as fraction of planet/moon radius. Use SW HUD CAI with custom altitude dial to exploit this option (I plan to present this OXP in relative topic). Or you can edit any other HUD with analog altitude dial.

Once you have managed to open the HUD .oxz, find in the hud.plist the code line

Code: Select all

selector = "drawAltitudeBar:";

and replace it with the next two code lines:

Code: Select all

selector = "drawCustomBar:";

data_source = "RALT";

If you do not have the SW HUD CAI installed or any HUD modified in the above-described way you’ll get the default altitude fixed scale.

Dependencies and conflicts

• You need Sun Gear installed to collect solar wind flux.
• Hard Way conflicts with TorusToSun and Fuel Collector OXP due to similar functionality.

It is recommended, but not obligatory, to use Planetary Systems OXP, not Additional Planets, if you’ll have Hard Way installed. Hard Way OXP using event this.shipEnteredPlanetaryVicinity to switch altimeter onto nearest celestial body. It is safe for Planetary Systems / Moons - you’ll never have false switches because planets and moons widely separated. Having more tight planet-moon configurations in Additional Planets you’ll sometimes possibly have false switches due to overlapping horizons of this.shipEnteredPlanetaryVicinity event (3 planet/moon radii).

Game balance considerations

I was asked: can I distribute the Warp Drive, for example, as a separate package without such annoying options as consumable fuel or shield recharging? Answer is – no. Consumable fuel is annoying option for most Oolite players maybe, but for some players it is challenging option, and I like to create OXPs for this kind of people. Consumable fuel and solar wind collection IMHO is nice example of complementary additions to game mechanics. Having consumable fuel you need to plan carefully a point of no return like in fighter sims. Having solar wind scoop you can replenish your fuel, so making in-system flight it can be useful sometimes to set flight path like planet A – sun proximity – planet B instead direct flight from planet A to planet B. Space is no more vast void, it is dynamic environment now, like ocean for sailors.

There are some issues with this altered game mechanics however.

• Start Choices (author spara) offers Harder Start scenario – Adder without fuel and missiles and with empty cash. This is really hard scenario in vanilla Ooniverse, but having Hard Way it will be suicidal. So restrain your ambitions and select Hard scenario instead – the same Adder, but with 7 LY fuel, missile and 100 credits.
• Having ship with poor rate of energy banks charging such Cobra Mk I or Adder you’ll see energy level drop during shield recharging. In case of stock Adder with single energy bank and energy recharge rate only 2.0 energy level during shield recharging will drop deeply below red alert state. This is no bug, this is feature. :mrgreen: Shield recharging is energy consuming process and some ships has poor performance in terms of energy management. Installing extra energy unit as soon as possible is obvious way to deal with this issue.

Enjoy!

Credits

• Wildblood - part of script from Altimeter OXP.
• Thargoid - part of script from Military Fuel Injector OXP.
• Norby – algorithm of detection of potentially dangerous entities in advance.
• Tch - algorithm of distance to nearest celestial body calculation.
• vasig - very useful help in refining concept of Gravity Well during initial development.
• dybal - valuable proposals for compatibility issue with Fuel Collector OXZ and for detection issue with special case of external ports without mass-locking.

License

• This OXP is released under the Creative Commons Attribution - Non-Commercial - Share Alike 3.0 license.
• You are free to use and distribute this OXP on non-commercial basis.
• Rebundling of this OXP within another distribution is permitted as long as it is unchanged.
• Any mods/derivatives of this OXP must be distributed under another names.
• The license information (either as this file or merged into a larger one) must be included in the OXP.

Version history

• 20.05.2020 - Version 2.7.0 Additional refining of energy balance on Torus mode and after fuel depletion.
• 19.05.2020 - Version 2.6.1 Fixed issue with energy drain on Torus drive flight in case of energy boosters such as shield capacitors or naval energy grid installed.

Fuel used to recharge energy banks now is function of ship energy recharge rate, not constant value.

• 05.03.2020 - Version 2.5.1 This readme file edited.
• 04.03.2020 - Version 2.5.0 Fixed logical flaw in conditions for fuel scoop activation, leading to 'scoop active' message being played while docked on Rock Hermits and other external ports without mass-locking.

Declared incompatibility with Fuel Collector OXZ with conflicting functionality.

• 21.04.2019 - Version 2.4.0 Fixed bug, generating error messages in log after player ejection on escape pod.
• 11.02.2019 - Version 2.3.1 Converted onto OXZ.
• 13.01.2019 - Version 2.3 manifest.plist added.

Code refactoring.

• 01.06.2018 - Version 2.2 Indication of solar wind collection added.
• 09.05.2018 - Version 2.1 Code edited to satisfy OXP Standards recommendations.

Solar wind collection script updated to refactored AstroLibrary.

Custom altimeter data source is added.

• 17.08.2017 - Version 2.0 Injector speed factor and fuel burn rate readjusting for player and NPS ships transferred onto Stranger Set bundle OXP.
• 30.12.2016 - Version 1.9 Injector speed factor for player and NPS ships reset to 4 instead default 7.

Fuel burn rate reduced from default 0.25 LY/s to 0.125 LY/s.

• 04.07.2016 - Version 1.8 Altitude calculation procedure improved (system scan on this.shipEnteredPlanetaryVicinity event).
• 25.12.2015 - Version 1.7 Max speed after burning all fuel set to 0.5 * max speed in normal state.
• 08.09.2015 - Version 1.6 Wear & tear effect readjusted.
• 05.09.2015 - Version 1.5 Max speed after burning all fuel reduced to 0.25 * max speed in normal state.
• 04.09.2015 - Version 1.4 Wear & tear effect for fuel collection added.

Wear & tear effect for energy recharge rate added.

• 03.09.2015 - Version 1.3 Warp drive script transferred into package.

Additional wear & tear effect on ship dynamic properties implemented.

• 25.06.2015 - Version 1.2 Direct check of Torus drive status.
• 06.03.2015 - Version 1.1. Forward/Aft shield levels in jump drive mode readjusted from 0 to 1/4 nominal level.

Altimeter scale sensitivity reduced to integer numbers.

• 22.10.2014 - Version 1.0. Integrated HUDs removed to provide better support for extra HUDs and to fix bug with MFD display switch.

Auxiliary unit capacity depends on energy stack capacity.

• 24.06.2014 - Version 0.9. solar_wind.js transferred from Sun Gear OXP to Hard Way OXP.

New MFD feature added to integrated HUDs.

• 03.06.2014 - Version 0.8. Fuel consumption in proximity of massive celestial bodies readjusted from 0.1 LY/min to 0.1 LY per 2 min

(ship speed below red zone)

and 0.1 LY per 1.5 min (ship speed in red zone)

• 31.05.2014 - Version 0.7. Fuel consumption in cruise mode reduced twofold if ship speed is below red zone

(0.1 LY per 6 min in economic mode vs 0.1 LY per 3 min in full speed mode).

• 23.12.2013 - Version 0.6. Digital altimeter switched ON during descent and OFF during climb.
• 21.12.2013 - Version 0.5. Digital altimeter is added to provide altitude readout during EDL phase.
• 15.11.2013 - Version 0.4. Fuel consumption in proximity of massive celestial bodies increased.

Additional fuel consumption to charge energy stack is added.

• 04.10.2013 - Version 0.3. Minor bug in calculation of moon gravity well is fixed.

Calculation of gravity well effect refined: probability of misjump is correlated with jump altitude.

• 01.10.2013 - Version 0.2. Fuel counter refined.

Fuel consumption in jump drive mode slightly increased.

• 30.09.2013 - Version 0.1. Initial release (internal testing).

Tips

• It can take a long time to collect enough fuel for a long jump if you are distant from the sun. You might find Scriptable Pause/AutoPause useful - but be aware of its limitations...
• On exiting Torus, your energy banks are hammered as they recharge your shields, especially if you have enhanced their strength. Shield Equalizer And Capacitors OXP might prove helpful in this regard, as might other oxp's which affect the Energy banks or the Shields.
• If travelling to systems which are - say - 6.8ly distant you will want to think about wormhole scanners, fuel tanks, and/or the Advanced Navigation Computer. Note that Smiv's "Extra Fuel Tanks" require your main fuel tank to be empty before fuel transfer can take place. This is a major pain in the unmentionables and limits their use!

Links

3-{{{2}}}

• Strangers World (SW)
• Discussion on Bulletin Board
• Solar Wind Flux

Hard Way is counterbalanced by other SW .oxp's such as Traffic Lights, Energy Rebalance & Internal Fuel Tank.