Oolite Bulletins

ShieldCycler Next 1.10.2 is now also available from the OXZ manager.

Given the developments in OxpConfig, i am changing the development tree plan.

v1.11.x will have the breakability, but also use OxpConfig v3 and have that version as a required dependency.

ShieldCycler Next 1.11 released as OXP & OXZ

Changes in v1.11 :


switch from unbreakable equipment to loss of functionality when damaged
used schema :
every direct hit will reduce functionality by 10% , but it won't go below 40% functionality
since the presence / absence of shield booster and mil shields already influences SC performance, i don't see the need for functionality loss when they are damaged
add repair option when docked (F3 screen)

repair price :
calculate total price of all installed SC devices
multiply by .5
multiply with (100 -functionality)/100

--------------------------------------------

Future plans

v 1.12
switch to OxpConfig v3


v1.13
in-flight repair options
Thargoid has told me he feels partial repairs don't fit in with the goal of repairbots. He has warned me about several potential problems, and urged me to keep them contained in my oxp at first due to these.

v1.20

re-release 1.13.x as stable
remove code to convert pre-1.10 savegames
add new cycler mode "Lowest" that mimics shieldequalizer functionality
investigate whether the timer based functionality (smooth transfer / sound ) used by shieldequaliser can be combined with my event-driven approach for shield cycler device
add capacitors from shieldequalizer, making sure they are compatible with other oxps.
Keep timer-based behaviour for capacitors ?
bigger capacitors, like in hardships oxp
additonal configure options (using OxpConfig) to work with the new devices
add start/stop functionality for capacitors
have SC next conflict with shieldequalizer+capacitors oxp

development version 1.11.1 released

Changes :

v1.11.1
bugfix in shipLaunchedEscapePod
implemented 1.82 functionality

Changes in v1.11.2 :
Cabal Common Library and OxpConfig are now required dependencies
new functions methods _sc_store_devices & _sc_retrieve_devices :
allow Ship Storage Helper to store/retrieve ships with SC devices installed correctly

Plans/Future versions

v 1.12 re-release 1.11.2 as stable

v1.13 switch to OxpConfig v3
list OxpConfig v3 as required dependency

v1.14
in-flight repair options
Thargoid has told me he feels partial repairs don't fit in with the goal of repairbots. He has warned me about several potential problems, and urged me to keep them contained in my oxp at first due to these.

v1.20

re-release 1.14.x as stable
remove code to convert pre-1.10 savegames
add new cycler mode "Lowest" that mimics shieldequalizer functionality
investigate whether the timer based functionality (smooth transfer / sound ) used by shieldequaliser can be combined with my event-driven approach for shield cycler device
add capacitors from shieldequalizer, making sure they are compatible with other oxps.
Keep timer-based behaviour for capacitors ?
bigger capacitors, like in hardships oxp
additonal configure options (using OxpConfig) to work with the new devices
add start/stop functionality for capacitors
have SC next conflict with shieldequalizer+capacitors oxp

Changes in v1.11.3 :
Upon buying a new ship, shield cycler devices were not removed anymore, corrected.
small fixes

version 1.12 released as new stable & development version.

Note :
ATM there's no difference between 1.12 stable and 1.12 development.

I've found 2 bugs in v1.12 : one is related to repair, the other influences aft & forward settings ONLY.
(Working on 1.12.1 that fixes both).

I also noticed in Equal setting, often both fwd & aft capacitor would be discharged simultaneously.
I THINK this is caused by both SC & SEC capacitors accessing the same values at the same time.
As SC is event-driven while SEC capacitors are timer-driven, it's hard to predict how often they will clash.
It could be solved by having SEC timer disabling shield cycling when they want to do their job, and re-enabling once SEC timer has done it's job.

SEC ShieldCheck timer does fire every .5 seconds, so this would result in a LOT of disabling/re-enabling SC.
Not good for performance, and feels clumsy to me.

A possible solution :
upon launch : store player.ship.maxForwardShield

Use 2 timers :
timer1 counts the time since last hit on forward shield of ship.

Timer2 checks if time-since-last-hit > a given value (say 5 seconds)
It checks if shields are at or above original max values, if so it increases the max value (until capacitor limit is reached ).

Every hit on forward shield will reset the counter AND reduce the max shield value to original value or current strength (whichever is greater) .

On docking, reset player.ship.maxForwardShield to original value.

Do the same for aft shield.

This would preserve the temporay shield improvement capacitors give, but the discharging would be done by the core game code.
That way the clash between SC cycling and SEC capacitors discharging would be avoided.

Please comment on this approach.

Lone_Wolf wrote:

I THINK this is caused by both SC & SEC capacitors accessing the same values at the same time.

You should test this to confirm, I think a timer can not break the run of another js function in the middle.

Lone_Wolf wrote:

SEC ShieldCheck timer does fire every .5 seconds, so this would result in a LOT of disabling/re-enabling SC.

Running a few js lines usually need very-very little performance if not contain cycles, missionVariables or worldScript keys.

Lone_Wolf wrote:

upon launch : store player.ship.maxForwardShield

Not a good idea: can break any other (future) OXPs which use the same variable. If you must choose between this two solution then the first is better imho.

Norby wrote:

Lone_Wolf wrote:

I THINK this is caused by both SC & SEC capacitors accessing the same values at the same time.

You should test this to confirm, I think a timer can not break the run of another js function in the middle.

I've done some checking and it does seem JS is NOT mutli-threaded.
With HTML 5 and Web Workers [1] [2] you appear to be able to run javascript tasks in the background, but this requires a special setup.

Norby wrote:

Lone_Wolf wrote:

SEC ShieldCheck timer does fire every .5 seconds, so this would result in a LOT of disabling/re-enabling SC.

Running a few js lines usually need very-very little performance if not contain cycles, missionVariables or worldScript keys.

Lone_Wolf wrote:

upon launch : store player.ship.maxForwardShield

Not a good idea: can break any other (future) OXPs which use the same variable. If you must choose between this two solution then the first is better imho.

Didn't think about that, but that's indeed a big disadvantage.
After posting i realised i dislike both approaches (to complex) , and think the best solution to avoid clashes would be to make sure SC only cycles AFTER relevant capacitors have been discharged.



[1] https://en.wikipedia.org/wiki/Web_worker
[2] http://ejohn.org/blog/web-workers/


EDIT :
A search in Oolite 1.82 sourcecode indicates oolite does support workers, but i see no sign core game code uses them.
Workers appear to be implented in a thread-safe way, even if core code does use JS worker it shouldn't pose problems.

Lone_Wolf wrote:

A search in Oolite 1.82 sourcecode indicates oolite does support workers, but i see no sign core game code uses them.
Workers appear to be implented in a thread-safe way, even if core code does use JS worker it shouldn't pose problems.

My understanding is that workers are implemented only if the macro JS_THREADSAFE has been defined for the JS library build. At this moment, the Windows port uses a js dll built without JS_THREADSAFE (for various technical reasons) and that could explain the lack of any use of them in the core code. Just wanted to mention this, in case of potential future compatibility iusses.

Just running this line in the debug console under Windows:
var w = new Worker("work.js")
generates
Exception: ReferenceError: Worker is not defined

another_commander wrote:

Just running this line in the debug console under Windows:
var w = new Worker("work.js")
generates
Exception: ReferenceError: Worker is not defined

Same result under linux , 1.82 dev build.

ShieldCycler next 1.12.1 released .

Changes in v1.12.1
- upon repair, equipment wasn't removed which made consecutive repairs impossible
- transfer needed in aft & forward setting was calulated wrong, this could sometimes result in unwanted free shield strength out of nowhere.
- With capacitors and shieldcycler both active, there were some weird effects.
Although codewise they don't clash, i've changed the code so that SC will only cycle AFTER relevant capacitors are emptied.

There's a tiny bug in the "this._sc_stop" function in both 1.12 and 1.12.1.

In both versions: should be

Thanks for the report,phkb.

Personal issues keep me from doing much oxp'ing for the time being, but i'll make sure to put some time aside to upload corrected versions.

ShieldCycler next 1.12.2 released, small bugfixes