Hard Way

From Elite Wiki
Revision as of 16:03, 17 December 2020 by Cholmondely (talk | contribs) (Links and version history added)

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, altering game mechanics:

  • Collapsible Shields and Fuel Consumption
  • Gravity Well
  • Solar Wind Scoop
  • Warp Drive

Collapsible Shields and Fuel Consumption

This option was initially intended to compensate game imbalance. NPC never uses Torus drive! It is too easy to force NPC opponent, equipped with witchfuel injector, to burn up all fuel: just let him go off scanner range and pursue him with Torus drive. Working well for Constrictor hunt: fire, chase poor bastard on Torus drive, fire and chase again, repeat until he'll consume all fuel, close on fuel injector onto his 6 o’clock, give him coup de grace. Chase on Torus 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 you ship for battle after cruising on high velocity Torus mode it will be different and in some aspects more realistic game setting.

Forward/Aft shield level decreases to 1/4 of nominal level (red/yellow border level) in Torus drive mode and flight become a bit risky: recuperation of shields after mass locking takes a time (approx. 45 s for Cobra Mk III without extra energy unit). It is a good idea now to wait for complete shield recharging before attacking enemy ships! And it is a good idea now for green Jameson to use Torus drive carefully. So skill of visual observing of any potentially dangerous targets beyond scanner range will be extremely helpful.

In vanilla Elite/Oolite you have unlimited source of power for ship systems. You spend fuel only for hyperjumps or for witchfuel injector. You have completely functional ship even if fuel tank is empty. You can fight, you can continue patrol space without time limit. In this OXP fuel is consumed in cruise mode by core energy unit to provide power for ship systems. If you’ll burn up all fuel, core energy unit will shut down and ship will switch to auxiliary energy unit. Shields will be disabled and energy bank will set to minimal power consumption. Main engine will shut down also and you’ll have only auxiliary engine, restricting your max speed to 0.5 of normal max speed. You’ll have chance to reach safe station, but your chances to win combat in such condition will be virtually nil.

Rate on fuel consumption depends on ship state:

  • In economy cruise mode (speed below red zone) fuel consumption rate is 0.1 LY per 6 min
  • In fast cruise mode (speed in red zone - approx. 80…100%) fuel consumption rate increased to 0.1 LY per 3 min.
  • The additional fuel is needed to maintain function of gravity field compensator in mass lock state (total fuel consumption increased to 0.1 LY per 3 min in economy cruise mode and 0.1 LY per 2 min in fast cruise mode).
  • Flight on Torus drive also requires extra fuel (total fuel consumption 0.1 LY/min).
  • Additional fuel consumption is needed to charge energy stack (energy regeneration after enemy hit or collision, firing ECM and ore processing).
  • An attempt to use Torus drive after burning up all fuel leads to dramatic loss of energy and… Uh-oh! Press Space, commander!
  • You have limited time to reach station on auxiliary unit. Press Space, commander, after auxiliary unit depletion! Or pull hard Eject lever (I mean hit twice E key of course!) before auxiliary unit shutdown and continue journey on board of escape capsule, if you have this device.

I think fuel consumption rate is reasonably game-balanced: in Green state you have 7 hours patrol time in system with full fuel tank and 3 extra hours patrol time with one extra fuel tank. Route from entry witchpoint to main station without Torus drive typically takes approx. 30…45 min - 0.5…0.75 LY of fuel in Green state or 1.0...1.5 LY being mass-locked by system traffic in Yellow state. Not unacceptable big value (you need extra fuel tank to reach safely station after jump on 6.8 LY distance, of course!).

Gravity Well

In post-Elite space sims interstellar travel is often realized using network of permanent wormholes or artificial portals, so you need to travel from planet or spaceport to some point in system to depart. There are usually several such wormholes in system, connecting it with neighbors. In Elite and in Oolite we have ships, equipped with autonomous hyperdrive. So you don’t need to navigate for departure. Just leave proximity of station (approx 10 km in case of Coriolis) and hit H to initiate hyperjump sequence. Seems bit illogical. Relatively small station mass can completely abort hyperjump, huge mass of planet has no any effect (OK, I know, planet has no any mass in Oolite).

Gravity Well module changes game mechanics by simulating gravity field distortion in proximity of celestial bodies. Attempt to hyperjump below safe altitude can cause fuel leakage, cargo/equipment damage and/or misjump. Probability of malfunction increased as function of diving onto gravity well (less altitude – more chance of misjump). Upper boundary of gravity well influence (gravity well horizon) in case of planet is equal to mass-lock radius (H = R). In case of moon gravity well horizon is H = R too, but due to hardcoded minimal mass-lock radius for moons 25600 m gravity well horizon will be inside mass-lock radius. For safe departure from main station climb above station and activate hyperjump. For safe departure from planet port climb to leave planet mass-lock zone.

To provide more visual cue altimeter dial is hiding above gravity well of nearest celestial body. It helps to discern mass-locking caused by planet from mass-locks caused by ships/stations. You have no any new useful info constantly watching completely filled altitude dial, right? Watch carefully for altimeter dial before hyperjump countdown activation. In case of hyperjump countdown activation below safe altitude abort countdown by repeated pressing of H key, climb to safe altitude and repeat activation of hyperjump. You can safely follow another ship's wormhole in green altimeter zone (AI often jumps below mass-lock horizon), but the general rule is to avoid hyperjump below safe limit. Actually there is some margin of error below gravity well horizon for safe hyperjump – but not too wide.

Custom altimeter data source is added: altitude is calculated as ratio to planet/moon radius instead default fixed 40,000 m scale (4000 km in planet scale). See more details on custom altimeter mode below.

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

Solar Wind Scoop

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

Solar Wind Scoop allows to compensate fuel consumption by collection solar wind in proximity of sun (minimal solar wind flux to start collect fuel is 0.1 LY/min). Sometimes during solar flares solar wind flux exceeds this minimal value even en-route from entry witchpoint to station - but as a rule you need journey closer to sun to fill the tanks. Not so close and so hot encounter as for sun skimming. 5...10 solar radii will be sufficient. Solar wind collection is fully automatic process, you need only Fuel Collector installed. If solar wind collection is started you’ll see animated icon of fuel scoop indicator on HUD and hear “champing” noise. To give info for solar wind flux lock Advanced Space Compass onto sun and switch MFD onto Sun Info page. Pay attention - solar wind collection is possible only during cruise mode and Green condition, not in Torus drive mode nor in WFI (afterburner) mode! Solar wind readings on MFD will be zero if you are NOT in Green condition.

Warp Drive

Well, this module was initially written as standalone OXP, but it is best suited for additional changes of ship dynamic properties. The main function of this module is high velocity engine mode for exploration of vast new solar systems, available since Oolite 1.82. If player's ship is beyond range 25 radii from sun and 25 radii from nearest planet and fly on Torus drive, ship speed multiplied up by warp factor as function of distance to sun, expressed in sun radii. So unlike “quantum leaps”, implemented in Norby’s Far Planets / Torus to Sun, you have smooth movement. It takes only several minutes now to reach any object in solar system using warp drive in clear space (actually you’ll have occasionally mass-locks if you have OXPs like Deep Space Pirates or Deep Space Dredgers). Warp mode activated automatically in Green state and aborted if any entity detected in proximity of ship (scan range proportional to warp factor), preventing accidental collision with ship or asteroid (but jump drive remains working in 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. Shield energy bars indication turns OFF if Torus mode activated and ON in case of Torus drive deactivated. Use it to check Torus drive status in case of manual deceleration. It takes several seconds to decelerate from warp velocity in case of manual Torus mode deactivation, so don’t use manual Torus drive shut down if you have planet, moon or station on collision course! It is safe to allow Warp drive to switch off automatically.

Additional functions of Warp Drive module:

  • Player's ship turn rate in torus/warp mode is inverse proportion of speed.
  • Turn rate in yaw channel set to 1/4 turn rate in pitch channel
  • Player ship's max speed, thrust and energy recharge rate depends on ship's technical state.

Some explanations for these changes

Turn rate vs velocity

Turn rate in vanilla game seems to be independent from ship velocity. Cobra Mk III on full throttle, full stick deflection on pitch axis. Complete loop for 6 s – approx. 1 rad/s. The same Cobra Mk III on Torus x32 speed. Stick deflected… The same 1 rad/s. Well, I can agree with argument “ship movement in Elite/Oolite is not Newtonian movement – it is surfing on wave of space curvature without huge inertial moments”. Flight model in Oolite is extremely simple. But we can modify it to feel game more realistic. There is Wildblood’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’m realized my solution. Having ability to readjust course you can avoid most mass-locks on deep space dredgers – these huge ships are visible from enough distance to react before mass-locking.

Turn rate in yaw/pitch channels

You can use both max_flight_pitch and max_flight_yaw parameters in shipdata.plist, but usually the last is omitted and by default is equal to max_flight_pitch. Seems NPS never uses yaw channel to change flight directions. Seems also some human players never uses yaw channel too, but having joystick with rotating stick you have easy way to do it. Default max_flight_yaw equal to max_flight_pitch seems to be too sensitive, especially for joystick. Reducing player ship’s turn in yaw channel helps to ease precise aiming without switching control sensitivity. Too high rate of turn in yaw channel is also contradicts with my perception, based on piloting glider in real reality – turning aircraft without banking is extremely ineffective maneuver comparing with coordinated turn.

Ship dynamics as function of technical state

So-called serviceLevel parameter is mostly hidden from player. Starting from 100 it gradually decreases with every hyperjump to 75 and remains frozen in this 75 value until next ship renovation. The only visible effect is 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 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 invest in your security if misjump – sooner or later – is not your option. But in the game you always have save/load option. So increased malfunction probability is not enough motivation, and I know players who never spend money for ship maintenance overhaul. Situation will be different if ship performance will be function of ship technical state.

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

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

Jameson, Ooniverse is not as friendly personally to you as you like to think. Do regular maintenance to restore 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

It is recommended, but not obligatory, to use Planetary Systems OXP, not Additional Planets OXP, 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).

Links