Hard Way

[stranger]

Hard Way

Latest OXZ - Version 2.8.0
Uploaded 29 November 2020

This OXP is oriented to player, seeking more complex and more challenging game rules. It will be a bit confusing to newbie, so I recommend to try Hard Way if you are familiar with vanilla game rules.
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 options:

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.

Find in hud.plist code line

Code: Select all

	selector = "drawAltitudeBar:";

and replace it for next two code lines:

Code: Select all

	selector = "drawCustomBar:";
	data_source = "RALT";

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

Dependencies and conflicts

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

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 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. 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.

[stranger]

Hard Way version 2.4.0 - fixed bug with invalid reference to undefined player.ship.position in case of ejection, generating error messages in log.
Seems it is not just fixed cosmetic issue - now several days are added to player clock after ejection, not only one.

[dybal]

I like this OXP modifications, especially cruising consuming fuel (I find the core-game assumption of free-cruising strange...), but if the player has the FuelCollector OXP installed and has bought the Fuel Collector scoop enhancer, there will be two routines checking and scooping periodically.

I like the mechanics of solar wind scooping for in-system cruising in your code better, since it takes into account the solar wind flux, while FuelCollector/FuelTweaks operate based on distance to sun, ignoring variations of solar activity (flares!).

My suggestion (code bellow ) is to defer solar wind scooping to Fuel Collector if it's installed in the ship, since that is its main funcionality and Fuel Processor (from FuelTweaks OXP) interacts with it to save the scooped fuel when the ships tanks are full into fuel storage units for sale.

I also added a line turning off scoop overwrite while docked... I had the "scoop active" voice message being played every few seconds while docked in Rock Hermits.


In solar_wind.js:

Code: Select all

this.shipWillLaunchFromStation = this.$startCollectFuelTimer = function()
    {
    if (player.ship.equipmentStatus("EQ_FRAME_FUEL_COLLECTOR") == 'EQUIPMENT_OK' || player.ship.equipmentStatus("EQ_FRAME_FUEL_COLLECTOR") == 'EQUIPMENT_DAMAGED')
        {
        log(this.name, "Ship has Fuel Collector, deferring solar wind scooping");
        this.$managesFuelScooping = false;
        return;
        }
    this.$managesFuelScooping = true;
    this.$fuelCollectFlag = 0;
    this.$fuelCollectCounter = 0;
    this.$endurance = this.self.serviceLevel/100;
    this.$wear = 1 - this.$endurance;
    log(this.name, "Launching: solar wind scooping starts");
    if (this.$fuelCollectWatchTimer)
        { this.$fuelCollectWatchTimer.start(); }
    else
        { this.$fuelCollectWatchTimer = new Timer(this, this.$checkCollectFuel, 0, 1); }
    }


this.shipWillDockWithStation = this.shipDied = this.$stopCollectFuelTimer = function()
    {
    if (this.$managesFuelScooping)
        {
        this.$fuelCollectFlag = 0;
        this.$fuelCollectCounter = 0;
        this.self.scoopOverride = false; // to avoid the 'scoop active' message being played while docked on Rock Hermits
        log(this.name, "Docking: solar wind scooping stops");
        if(this.$fuelCollectWatchTimer && this.$fuelCollectWatchTimer.isRunning)
            {
            log(this.name, "stopping fuelCollectWatchTimer...");
            this.$fuelCollectWatchTimer.stop();
            }
        }
    }

Cheers!

Dybal

[stranger]

Thank you for reply and for proposals, Dybal!
I need some time to test your added code lines, but your considerations looks reasonable!

[stranger]

Well, we have issue with Hard Way - conflict with Fuel Collector. These OXPs uses different mechanisms of in-flight fuel collection.
Dybal's proposal to override solar wind scooping realized in Hard Way if Fuel Collector equipment is installed is reasonable, but I think declaration of incompatibility will be right solution. If you have two equipment units with similar, but conflicting functionality, use one solution, not both.
So since version 2.5 Hard Way is incompatible with Fuel Collector.

@phkb
I'll appreciate your considerations how to integrate Hard Way fuel collection with Fuel Tweaks.

@dybal
Rock Hermit is special case - it is not mass-locking object (and Salvage Gang in Anarchies too!). Honestly, I omitted this case.
Used line from your code to fix issue.

[phkb]

I'll appreciate your considerations how to integrate Hard Way fuel collection with Fuel Tweaks.

I'll have a look at what's involved.

I guess the question to ask is, what functionality are we aiming for? In Fuel Tweaks, it plays with the built-in, standard fuel scooping method, allowing for additional fuel (ie more than 7LY worth) to be scooped at the same rate as normal. From my quick analysis, Hard Way will scoop fuel at potentially much greater sun distance (and at different rates, too, I think - not sure). So, are we looking for the Fuel Collector to work in concert with Hard Way, by overriding its own scoop distance calc and allowing additional fuel to be scooped at the same range/rate as Hard Way?

[phkb]

Although, having said that, I'm not sure if anything needs to be done. Hard Way isn't removing the current method of scooping - if you get to scoop distance the normal scoop process will kick in even with the OXP installed. A little bit of handwavium will suffice: "The Fuel Collecter can only collect fuel when the plasma input pressure exceeds the operational pressure of the collection input valve." (ie you can only scoop Quirium fuel which can be sold separately from the normal scoop distance).

[stranger]

In Fuel Tweaks, it plays with the built-in, standard fuel scooping method, allowing for additional fuel (ie more than 7LY worth) to be scooped at the same rate as normal.

So it seems safe to install both OXPs - Fuel Tweaks and Hard Way - without problems of functional interference.

So, are we looking for the Fuel Collector to work in concert with Hard Way, by overriding its own scoop distance calc and allowing additional fuel to be scooped at the same range/rate as Hard Way?

No. I think it will be better solution to avoid using Fuel Collector as additional device with similar functionality, i.e. to declare incompatibility between Hard Way and Fuel Collector.

[phkb]

I think it will be better solution to avoid using Fuel Collector as additional device, i.e. to declare incompatibility between Hard Way and Fuel Collector.

Sorry, my bad. I wrote "Fuel Collector" but I meant "Quirium Fuel Processor". But I think your first reply answers the question anyway - there is no incompatibility between Hard Way and Fuel Tweaks - they will both collect fuel in the ways they intend, and shouldn't impact on each other.

[stranger]

Thank you, sir!

[Norby]

How about adding auto eject when run out of fuel, instead of just explode? Like this:

Code: Select all

if( player.ship.abandonShip() ) {
                        player.consoleMessage("Out of fuel, auto eject!", 10);
} else { 
                        player.consoleMessage("Out of fuel, bye bye...", 10);
                        player.ship.explode();
}

Some more message would be good also, for example when you have not enough fuel to reach the main station so you must scoop first.
Btw nice work!

[stranger]

Thank you, Norby!
I'll think it over.
Just for clarity: ship exploding event in Hard Way not triggered by running out fuel per se, but by depletion of auxiliary energy bank. Having no fuel you have no ways to generate energy for ship reactor.

[stranger]

Thanks again to Dybal for detection of logical flaw in Hard Way code and proposed fix.
In Torus flight mode forward/aft shield values sets to 0.25 of shield max level to give gamer extra challenge. In case of mass locking onto hostile contact you need some time to recharge shields to max value before gunfighting. During Torus flight hardcoded energy management procedure tries to restore shield energy levels to full values. Default values of shield energy restore are 2 for forward/aft shield, 4 in total. So in worst case of Adder with its energyRechargeRate = 2 you’ll have 4 – 2 = 2 units of energy drain per second in Torus flight mode.
I was developing Hard Way initial concept six and half years ago, having poor coding skills and knowledge, so I just added 2 extra energy units per second to compensate energy drain. Lazy solution indeed. It was before Oolite 1.81 and forward/aft shield recharge rates were read-only values. Since Oolite 1.81 forward/aft shield recharge rates are read/write parameters. Moreover, if you have equipment, increasing default shield recharge rate, you’ll have increased energy drain! Ironically, due to this logical flaw equipment, intended for more effective energy management, creates energy shortage!
Simple and fine fix, proposed by Dybal:

Code: Select all

this.self.energy += (this.self.aftShieldRechargeRate + this.self.forwardShieldRechargeRate);

Adopted.
The same fix was added to compensate unintended energy drain in case of fuel depletion.

Maybe setting shields recharge rate to zero will be right alternative in terms of game logic, but in this case you’ll need to restore initial values after exiting Torus mode. More complex code with checking of special cases such as equipment status etc, more space for new logical flaws.

Also added non-critical code improvement. Extra fuel consumed during energy banks recharge now is function of ship energy recharge rate, not constant value. This is negligible value in any case – 0.1 LY fuel for recharging 360 energy units. So don’t worry

[stranger]

A bit more refining energy balance on Torus mode and on auxiliary power battery mode after fuel depletion.
Now using the next formula

Code: Select all

this.self.energy += this.self.aftShieldRechargeRate + this.self.forwardShieldRechargeRate - this.self.energyRechargeRate + 1;

so energy restore rate in Torus mode just covers energy drain for shield recharging + modest 1 unit per second for energy banks recharging.
Try to think in next terms. Despite having energy boosters your ability to generate more energy during flight in Torus mode is limited by efficiency of heat dissipation. You must be in common space to use full power of energy boosters.

[Milo]

I am using Sun Gear, Habitable Planets and Hard Way without any additional planets. It feels like the Warp Drive is not scaling up my speed (enough?) when traveling towards the sun, as it still takes a very long time to get there (even with developer build TAF set to 16).

I noticed in the script that the warpFlag is enabled if the distance to the nearest planet is at least 25 radii, and disabled if the distance to the sun is less than 25 sun radii. I also see that if there are any entities within scaled scanner range, it disables warp speed.

I am using Space Crowds and other OXPs which spawn some ships from time to time while I am in torus mode, so it is quite possible that there are ships behind me within the scaled scanner range. Would it be possible to exclude (for stopping warp) any entities that are behind the ship?

I also observe a strange phenomenon during torus mode where sometimes ships behind me will appear to fly rapidly forward in the direction I am traveling, and disappear into the far distance ahead.

(It is quite possible that some mix of other OXPs I am using is causing problems here, so I will investigate that as well.)