Shield Cycler NEXT 1.12.2

[Lone_Wolf]

[wiki]ShieldCycler[/wiki]

Manual Downloads :

oolite 1.82 :
Stable version 1.12 in oxp format
Development version 1.12.2 in oxp format

Oolite 1.80+ :
Download of stable version 1.0 in oxp format

Oolite 1.76 :
version 0.30.3 , oxp format

--------------------------------------------------------------
Notes for players :

- new savegame format, automatic conversion .
The new savegame format is unreadable for previous 1.0 stable version.
Backup your savegames !

- Requires OxpConfig 2.3.1+ & Cabal Common Library 1.7.1

- Shield Cycler & Manual Configurator devices can be damaged, although NOT destroyed.
When damaged they will still work, but with reduced functionality.
There is a repair option, accessible from the F3 screen.

- None of the shield cyclers / manual configurator devices are visible in the F3 equipment screen, they are however visible in F5+F5 screen.

- The basic versions of Shield Cycler and Manual Configurator lay the groundwork which the other versions need,
that's the main reason why the standard/advanced versions are listed as upgrades.
removal is done by downgrading, but to make it easier for pilots the tech will combine several downgrades into one.



Notes for "Dark Siders" :

- If you have equipment items that are not compatible or require shieldcycler devices to be present :
The presence of any shield cycler device can be checked by testing for "EQ_SC_SHIELD_CYCLER_INTERNAL" .
to test for Manual Configurator devices only, use "EQ_SC_MANUAL_CONFIGURATOR_INTERNAL"

- SC has several functions that are meant for other oxps, see wiki for details.

- Incase you wish to use ShieldCycler for npc ships, check SC_Core.js script, function this._sc_adjust .

--------------------------------------------------------------
Why did i create shield cycler ?

I am a pilot that prefers to work with 1 laser, and hates missilies.
This means that in fights against multiple opponents i am often at a disadvantage and get cargo / equipment damage
I have tried ships with higher energy then the cobra and turrets, oxps like ironhide, but none really did what i wanted.

I also followed the discussion about balancing oolite / arms race between npc and player.
At first my view was : if the pirates don't attack in groups of 4+ anymore, then they can have the same options as me.
Over time that changed however, and I started thinking about different ways to improve my chances.
My manual dexterity is not good enough to be effective with side / aft lasers, so that doesn't help.

Those that have played Xwing or sequels may remember that you could divide the total power of your ship over lasers, engine and shields.
It also has keys to transfer energy between those 3 uses, and you could cycle shield energy between equal (the default) and forward / aft shields.
Using those keys / energy configurations well meant you improved your survival chances by being smart.

I've created an oxp where the player can select a shield configuration setting, and a script takes care of keeping the shield energy distributed in line with the setting.

Background

Why do spaceships have 2 shields and not 1 (round ship) or 12 (dodecahedron station) ?

Early shields could not protect a whole spaceship, only small areas of the ship.
Engines, power core, cockpit, crew quarters were among the first areas to get shields protection.
Soon this let to many small isolated shield pockets throughout the ship, and that was not managable.
The military (well known for having the 'right' priorities) decided that the crucial parts of a spaceship were
powercore and cockpit.
Without power your weapons are useless, and you also need someone to press the trigger (or repair the powercore ...).
In all existing shipdesigns at the time the powercore was at the back of the ship, and the cockpit at the front side.
(there was no weapon powerful enough to damage a space station, so they didn't have shields at all).
This resulted in aft shields and forward shields.

As shield technology improved, more and more of the ship got shield protection.
The closer the aft and forward shielded parts got together, the more they influenced and weakened eachother.
A new device was proposed to deal with these problems : a shield inhibitor.
The idea was to put many of these devices in speficic locations in the ship to achieve the desired effect.
During Proof of Concept small scale lab tests of the inhibitor, an intern messed up some settings.
Instead of 2 separate shields they had 1 shield for about 2 minutes.
The designer was informed of this, checked and realised he had used simplified algorithms for the basic components.
By using the latest quantum physics algortihms for the components, he was able to proof both combining and separation of shields were possible.

Converting the algorithm to a solution usable in a device however was much harder.
Analysis showed that solving the combining equations would take atleast 1000 times
the computer effort needed for the separation.
Guess what solution was chosen by the military ?

Location :

"The Loving Feline", a Seedy Space Bar somewhere in Santaari

While sipping Zaquession evil juice, commander Lone_Wolf (rated competent) reflected upon his trip here.
During the voyage from the witchpoint to the main station, his cobbie had become the target of 10 pirates at once.
Injectors saved the cobbie, but while running 6 equipment items had been damaged.
Lone_Wolf was an engineer before he chose a new careerpath as a bountyhunter / trader and had repaired the items with succes.
What bothered him however was that when the damage occurred, his forward shields were still at full strength.
Only the aft shield was depleted.
He knew the shield technology history, but computers had become much more powerful since that choice was made.
"A combining inhibitor would have saved me a lot of work today, and likely have saved the lives of many pilots".
a few tables further a mixed group of 5 pilots was talking, all were rated dangerous or higher.
"Time to ask more experienced pilots"

From the experiended pilots Lone_Wolf learned that there were rumours about a "Shield Equalizer" being in development. No details about it were known though, not even the name of the designer or company.
Lone_Wolf decided it was best to start a design by himself and see if he could find more info.
Fortunately the Loving Feline had a high enough tech level and good hyperspace communications, so he decided to stay there a while. (the presence of both clean and pirate ships near would help with testing).
The first prototype of LW's "Shield Cycler" was ready soon, and worked ok, but lacked options for control and finetuning.
A few weeks later a redesigned prototype was ready for it's first in-flight tests, but no clean pilots were available to help with testing. Lone_Wolf decided to take a break and do some research.
He found out the hypermail address of the developer of "Shield Equalizer" , CommonSenseOTB, and contacted him.

It turned out this guy was indeed working on a similar device, but felt it should be fully automated and need very little pilot control.
He also planned to combine the equalizer with a capacitor that stored shield energy & indicated he planned to use the Shield Equalizer as the starting point for a company.
LW had no interest in starting a company, but intended to release the design into the public domain, so engineers everywhere could build it.
LW and CSOTB did agree to make their designs compatible, so pilots could use both but their goals were to different to make 1 device.

[Capt. Murphy]

I like the basic premise, makes perfect sense to me. Going into a fight you prioritise your front shield, once in the midst of a furball set it to both, and when it's time to run away prioritise the rear shield.

I think the equipment should have a 'cost' though - inherent inefficiencies in the shield energy transfer rate.

edit to add - I've just taken a peek at your code - a way you could add an inherent say 10% inefficiency is to include a modifier.

You could have a couple of versions - a Consumer version with 10% inefficiency and a more expensive Military version with 2% inefficiency or something.

Something along these lines I think would work...

Code: Select all

if ( player.ship.forwardShield < player.ship.maxForwardShield )
			{ 
			  this.shieldDiff = player.ship.maxForwardShield - player.ship.forwardShield
			  if ( this.shieldDiff > player.ship.aftShield * 1.1 )
			    {
			      player.ship.forwardShield += player.ship.aftShield;
			      player.ship.aftShield = 0;
			    }
			  else
			    {
			      player.ship.forwardShield = player.ship.maxForwardShield;
			      player.ship.aftShield -= this.shieldDiff*1.1;
			    };
			};

Code: Select all

this.totalShield = (player.ship.aftShield + player.ship.forwardShield) * 0.9
			player.ship.forwardShield =  this.totalShield / 2 ;
			player.ship.aftShield = this.totalShield / 2 ;

[Commander McLane]

I like the idea, an I like the idea of it not being 100% efficient. I'd even say the inefficiency should kick in right from the start. Whatever amount of shield energy gets transferred, only 90% or 95% or 98% (whatever, depending perhaps also on the price of the device) should arrive.

But I really like the idea. A clever contribution to the game mechanics!

[Lone_Wolf]

While play testing i noticed i skipped the standard oolite / disabled configuration all the time, so i'm going to take that out of the configurations.
default setting will become both, and i'll add the option to sell the equipment so those that want the default behaviour back can sell the equipment.

I like the idea of the device being somewhat inefficient, and will implement that.
The most likely end of the background story is that LW will not start a company to produce this (or team up with one), but will make the plans publically available, so anyone can build it.
This will mean the quality of the device will depend on the quality of the components used and the skill of the builders.

As you may have gathered from the background story, LW is not very fond of the military.
Also i sometimes feel that the civilian / military schema is to limiting with only 2 tiers, besides i want this device to get a high place on the 'equipment every ship should have'-lists. That means we need a cheap version for new pilots.

How about these variations :

Code: Select all

Type          Efficiency   Price       TL

Basic         75%            100      2
Standard      90%          12350     10
Advanced      98%          54300     14

[DaddyHoggy]

Brilliant idea L_W and as an X-Wing pilot of old I'm very happy to see it added to the Ooniverse!

[Zireael]

I love the idea!!! Downloaded.

[Capt. Murphy]

To avoid any possible confusion I should say that I may have misunderstood the shipTakingDamage handler when I posted those code snippets above. Wiki suggests that for players it only kicks in once a shield is down which I didn't realise. Should make it easier to code for the inefficiency though. I've edited the offending post.

[Lone_Wolf]

To avoid any possible confusion I should say that I may have misunderstood the shipTakingDamage handler when I posted those code snippets above. Wiki suggests that for players it only kicks in once a shield is down which I didn't realise. Should make it easier to code for the inefficiency though. I've edited the offending post.

You did understand shipTakingDamage correctly, it does kick in whenever a ship gets hit.
in case the ship still has shields the damage amount value will be 0, so you can use it to determine if shields have been depleted.

I have thought about the energy cost and feel it should be applied for all transfers , BUT also be worse when bigger amounts of energy need to be transferred.

i've decided to switch to 3 different versions of the shield cycler, each with these efficiency ratings :
a. energy transfer < 64
b. 64 <= energy transfer < 192
c. 192 <= energy transfer < 320
d. 320 <= energy transfer

(shield strengths go 128 - 256 - 384, but i feel there should be some overlap)

Basic version will have price 100, TL 2 , efficiency 95 / 90 / 80 / 66
Standard version : price 12450, TL 10, efficiency 97 / 93 / 85 / 75
Advanced version : price 43200, TL 14, efficiency 99 / 95 / 90 / 85

The standard version is a bit cheaper then shield boosters, while the advanced version is just below Mil shield cost.
Basically this is intended to create a natural upgrade path, where the shield cycler will be upgraded before the shields.
This will also mean smart players will be able to avoid the worst case efficiencies below 85% .

[Commander McLane]

Just in case you haven't noticed yet: in the activation script of v 0.12 there is a break; missing after case 0.

I am also wondering why you reset missionVariables.shieldCycler_setting to 0 after a witch jump. I'd prefer to keep the current setting even after a jump, and change it myself if I need/want to.

[Commander McLane]

And another suggestion: activating either setting could immediately transfer the shield energy accordingly. So if you activate the 'Front' setting during battle, the front shield should by maxed out right away, not only after the first hit. Because you need to cycle through the settings, this should be lossless, though. It would be unfair to lose more shield energy when switching from Aft to Front than you lose when switching from Front to Aft.

[Lone_Wolf]

Just in case you haven't noticed yet: in the activation script of v 0.12 there is a break; missing after case 0.

I am also wondering why you reset missionVariables.shieldCycler_setting to 0 after a witch jump. I'd prefer to keep the current setting even after a jump, and change it myself if I need/want to.

I'll check v 0.13 more carefully for such code errors.
My main reason for setting to 0 after a jump was to have a standard begin situation, as you don't know what setting you will need in the next fight.
But cycle commands are placed in commslog, so you can always look up what setting you have.
Ok, i'll remove the code to reset the configuration on both jumping and launching.

(a Hud indicator for the shield configuration would be nice ...)

And another suggestion: activating either setting could immediately transfer the shield energy accordingly. So if you activate the 'Front' setting during battle, the front shield should by maxed out right away, not only after the first hit. Because you need to cycle through the settings, this should be lossless, though. It would be unfair to lose more shield energy when switching from Aft to Front than you lose when switching from Front to Aft.

This does seem logical, and instead of taking shield energy i can take it from ship energy for these cases.

[Commander McLane]

My main reason for setting to 0 after a jump was to have a standard begin situation, as you don't know what setting you will need in the next fight.
But cycle commands are placed in commslog, so you can always look up what setting you have.
Ok, i'll remove the code to reset the configuration on both jumping and launching.

I'm okay with having a default setting after launching, however I don't consider a witch jump as a new beginning. You may in fact continue the same battle with the same pirates in the new system. That's why only the reset upon leaving witchspace struck me as odd. But I'm also okay with removing both resets.

Your OXP, your decision. I'm only voicing my thoughts.

[Lone_Wolf]

Your OXP, your decision. I'm only voicing my thoughts.

And i intend to listen.

Changes in v 0.13 - DOWNLOAD
(same link as in first post)

Shield Cycler

Continually distributes shield energy in 1 of 3 configurations :

Both - Equal shields aft and forward (default when buying)
Forward - Max forward shield, remainder on aft shield
Aft - Max aft shield, remainder (if any) on forward shield
Upon station lauch setting will always be 'both'
NOTE : The equalizer from CommonSenseOTB' oxp is incompatible equipment, the capacitators should work with ShieldCycler.

changes are instantaneous, but reduce ship energy related to the amount that needs to be transferred :
(to avoid draining energy banks very fast, for cycling between settings a fixed amount of energy is used).

a. energy transfer <= 127
b. 127 < energy transfer <= 255 (happens only with shield boosters)
c. 255 < energy transfer (occurs only if you have mil shield)

Code: Select all

Version     Price 	TL 	a_loss	b_loss   c_loss
Basic         100 	 2	  1%		5%		10%		
Standard    12450	10      1%		3%	    8%
Advanced    43200	14      1%		3%	    6%

Set configuration :
Shift+n to prime ShieldCycler

press n : cycle = both
press n : cycle = forward
press n : cycle = aft
press n : cycle = disabled
press n : cycle = both

Afaik the code works now as intended, the main thing now is play testing to see if the energy loss percentages are correct for game balance.
TLK and prices are still 1 / 1 for testing purposes.

[Lone_Wolf]

New version 0.14 uploaded., download link in 1st post.

Changes
0.14
- Added History & to do list
- Basic Shield cycler made incompatible with Shield Booster and Mil. Shields
Standard Shield cycler incompatible with Mil. Shields
- cycling the configuration now subtracts 4 * # of energy banks from ship energy.
- adjusting also uses shield energy, but the amount is now fixed and related to the transferred amount of shield energy.


To do list

currently the energy recharge rate is NOT a factor in the energy loss calculations , and this favors ships with high recharge rate / EEU / NEU.
Should this be included ?

Note :
energy recharge rate is not exposed in JS afaik, but there are atleast 3 devices that increase it :
Mil. Shields
Extra Energy Unit
Naval Energy unit

[Commander McLane]

The device prices are not like stated in the readMe. All three variants cost only 1 cr, and the resell costs are 10, 125, and 432 cr respectively.

This is a little strange, as you are paying more for the resell than for buying the device in the first place. (Usually, if selling something, you would expect to be paid, not to pay.)

EDIT: more problems:

1) I get the "configuration: equal" message every time I launch, even if I don't have a shield cycler.

2) There are only 3 settings: equal, forward, aft. The "disabled" setting is gone.

I removed the old shield cycler from my save-file before buying a new one, in order to avoid upgrading bugs.