Oolite Bulletins

Version 1.4 is available on the Expansion Manager and here.

Changes:

• don't transfer energy to/between shields while in Torus Drive (HardWay OXP might be keeping the shields drained), but do recharge the capacitors while in Torus.
• make possible to enable OXP functionality for NPCs, with the user defining if it's enabled or not (has performance and game balance consequences), default being not NPC enabled..

OXP functionality for NPCs is disabled by default (that's how this OXP worked before this version).

Enabling it will use more CPU (one timer for each ship that has Shield Equalizer or Shield Capacitors) if the player runs OXPs that award those equipments to NPCs (like ShipVersion). If that's the case, some NPCs will be harder to take down, affecting game balance against the player if the player's ship hasn't Shield Equalizer or Shield Capacitors, or making it more even if it has them.

Enabling the functionality for NPCs will affect only the NPCs spawned _after_ it's enabled, but the configuration will go into the savefile and be enabled at system populating time after the next load.

dybal wrote: ↑Wed Aug 05, 2020 4:48 pm

[*]make possible to enable OXP functionality for NPCs, with the user defining if it's enabled or not (has performance and game balance consequences),

A rather silly question Dybal but I admit that I didn't have a look at the code now:

Is it possible to assign the equipment to only specific NPC ships, like with this.ship.awardEquipment on spawn or a ship_script entry ? And if so would it work when the player deactivated NPC's ?

montana05 wrote: ↑Sat Aug 15, 2020 11:34 pm

dybal wrote: ↑Wed Aug 05, 2020 4:48 pm

[*]make possible to enable OXP functionality for NPCs, with the user defining if it's enabled or not (has performance and game balance consequences),

A rather silly question Dybal but I admit that I didn't have a look at the code now:

Is it possible to assign the equipment to only specific NPC ships, like with this.ship.awardEquipment on spawn or a ship_script entry ? And if so would it work when the player deactivated NPC's ?

I'm not sure I understood the question, so I will describe what I did and its limitations...

I have a shipSpawned worldScript that is triggered as any ship (what the core game considers a ship) is created. If the ship is NPC and NPC-enable config is true at that time, that script starts a on-time timer of 3 seconds. After those 3 seconds, if the ship has functional Shield Equalizer or Shield Capacitors, it creates several porperties in the ship.script to handle state, hooks the relevant functions into the ship.script and starts a timer bound to the ship script (Shield Equalizer + Capacitors is timer driven).

The 3 second delay in setting things up has two reasons:
- some OXPs set a new script to the ship after it's spawned (EscortdDeck does it to its escorts, for example), so any change I did to the ship.script in shipSpawned might be discarded;
- give time for other OXPs to award the Shield Equalizer and Capacitors equipments to the ship (like ShipVersion) in their on shipSpawned worldScripts.

So:

- the only time my code looks at the NPC-enable configuration setting is at the ship's spawn time;
- if the NPC-enable configuration setting was true at spawn time, at spawn time + 3 seconds my code looks at the ship and if it has he relevant equipments, sets it up.

This OXP doesn't award the equipments to the NPCs, that must be done by other OXPs by their own reasons (and I know of two who do, ShipVersion and Ship Storage Helper on behalf of EscortdDeck), it only ensures (if the configuration is enabling it) that any Shield Equalizer or Shield Capacitor awarded to the NPC ship in its first 3 seconds of existence will be functional.

One possible improvement would be hooking a equipmentAdded event handler to the ship script at spawn time and make that event handler set things up when and if a Equalizer or Capacitors was awarded to the ship... that would remove the timing constraint to the equipment awarding. It would be better as long as no other OXP is hooking its own equipmentAdded event handler to the ship script... if many tried it, it would get messy... There Can Be Only One

Thanks a lot, you actually answered all my questions. My basic idea was to add your equipment to certain ships like that:
I just wasn't sure if NPC's need explicit be enabled and yes, they need to enabled. Thanks again, next time I will save your time and look in the code myself.

I made it user-configurable because enabling the Equalizer and Capacitors to NPC will alter game balance by making the NPCs tougher, and I think the player should be able to choose.

And feel free to ask questions anytime - your questions made me see I didn't put all the reasons for the delay in setting things up in my comments in the code

EDIT: just to add that if you define $debug and/or $logging in the NPC ship.script and assign true to them, there will be some messages in the Latest.log to show the equipment's working (if they are not defined, my shipSpawned defines them and assigns false)... $logging will get you messages when energy is transfered to/between shields, and a sample (1 each 5s) of the Capacitors state while they are recharging; $debug will print the state of shields and capacitors once each minute. I made EscortDeck enable that log by default in my escorts, but you can toggle it in a single NPC while playing by targeting it (to get its reference) and using the DebugConsole to assign true to the variables in its ship.script.

Thanks. I've not played for 10 years and started a new commander with all the new goodies in Oolite about a month ago. Really liked this equipment and have it installed.

Commander Mosser, Asp Explorer: Nostaligia for Infinity. Rated: Average.

Version 1.5 is available on the Expansion Manager and here.

This is a maintenance release, fixing two bugs... there is no new functionality.

Changes:

• only allows NPC functionality enabling (includes the inclusion in Config for AddOns on F4) if there is an OXP installed that adds shields to NPCs - right now, that's only N-Shields;
• resets the array of references to NPC setup timers whenever all timers have ran, i.e., all spawned NPCs have been set up.

Shield Equalizer and Capacitors v1.6 is available on the Expansion Manager and here.

Changes

• Make the delay to setup NPC ship after they are spawned variable, between 0s and 3s. The delay is meant to make sure that any OXP that wants to award Shield Equalizer and Capacitors equipments to NPCs at shipSpawned event handler had a chance to do so before we setup the ship.
• Capacitor code re-factored so charging and discharging are in separate functions; charging is essentially timer-driven, but discharging, i.e., transferring energy from the capacitor to the shield, could be event-driven, and next version of Shield Cycler Next will take advantage of that to put the capacitors to use before balancing the shields.

This release is mostly a compatibility release to the next version of Shield Cycler Next. With Shield Equalizer and Capacitors alone you get timer-driven capacitors, i.e., the capacitors will feed the shields (if the shields aren't full and there is charge in the capacitors) each 0.5s, which means that a ship with shield at 128 and 64 in the capacitor that receives 150 of damage in that time interval between capacitor discharge checks will have its shield zeroed and sustain damage. With the next version of Shield Cycler Next (assuming the ship has Shield Cycler installed) that would not happen, as the capacitor will feed the shield (if there's charge in it) at each hit.

The next version of Shield Cycler is almost ready, I just have to test it with the currently released versions of N-Shields and Ship Storage Helper (I run the development versions usually) - which I plan to do in the weekend.

 Shield Equalizer And Capacitors OXP v1.7 is available on the Expansion Manager and here.

Changes

• Changes equipment processing order, so shields are topped up with Capacitors energy, if necessary and possible, before the Equalizer balances the shields.
• Tests for NaN before updating ship's energy (assigning NaN to ship.energy maxs out the ship's energy, leading to the "invulnerable to lasers" bug if done in the damage handling path).
• Adds thoughening up of Energy Grid against damage, as it's done for Naval Grid, SHield Booster and Military Shield Enhancement.
• Changes delay for setting up spawned NPCs to at least 2s to make sure ShipVersion's shipSpawned event handler has run and had a chance to award equipments.
• Re-factors equalizer and capacitor processing functions to unify code, so aft and forward shields are parameters to the unified code.
• Reduces Capacitor prices to a cost-benefit level comparable to Shield Booster (10% more expensive for shield energy depth added), so they are not over-priced anymore; the Equalizer remains a money-sink though.
• Adds scriptInfo towbar_max_salvage_price to the equipments to limit their salvage price when salvaging a derelict.

I have not read this long-ish thread, but it seems fair to say: this OXP spams the log. For:
The spamming makes it hard to find errors in the logs. I imagine that it hurts performance too!

I have version 1.7 of the OXP.

Had the same problem but it can be fixed with a few quick Tweaks. Line numbers are from Notepad++ and may vary depending on the code editor you use.

Line 48 Line 87 Line 132 The last one is probably not really needed in this case but it is here for completeness. Basically in any OXZ/OXP that is flooding Mr. Latest Log with entries you are looking for JavaScript code that begins with <this.$logging> or <log(this.name)> or something similar to do with <log> or <logging>. Once found you can use one of the methods in the code blocks above to disable the spamming of entries to Mr. Latest Log - True to False; On to Off; or by Commenting Out the appropriate line of code.

Dear Nite Owl

Thank you for doing that work. I was hoping that the work would be done by the maintainer of the OXP. Note also that if a user does this work then she will have to unpack and then repack the OXP. I think that instead I will remove the OXP from my PC.

UK_Eliter wrote: ↑Fri Jul 23, 2021 2:28 pm

Dear Nite Owl

Thank you for doing that work. I was hoping that the work would be done by the maintainer of the OXP. Note also that if a user does this work then she will have to unpack and then repack the OXP. I think that instead I will remove the OXP from my PC.

Dybal is gone and most likely will never return. The OXP is still kind of a WIP and currently unmaintained.