[WIP] External Repair System (Subentity Repair System) 0.0.4

[GGShinobi]

GGIndustries announces the development of a new kind of repair system: The External Repair System.

Similar to the popular  Repair Bots/Ship Repair System from the  Aquarian Shipbuilding Corporation, the ERS will be using Nano Bots to perform repairs. But there are significant differences:

• The ERS doesn't repair the ships' internal systems, but damage to external parts of the ship (aka "Subentities"). We have the hope that this will greatly help our customers to reduce their maintenance overhaul costs.
• The nanobots are only doing the work - they do not integrate themselves into the repaired parts, so the system doesn't need to be recharged.
• Because of this, and in order to reduce their size, the nanobots also don't come with integrated energy cells, like the Repair Bots. The downside of this is that the ship needs to provide them with energy for as long as they operate. Our prototype still requires the energy equivalent to what can be produced by a  Tsierk Letaneya TV101 'Energia' engine unit, but we are confident that we will make great improvements in this area soon. *
• Instead of needing recharges, our nanobots do require the materials needed for repair to be available in the ships' cargo bay. Mostly this means that the ship needs to have alloys available. (If you are skilled or lucky enough, you may even use the hull plating that has just been shot from your ship and which you managed to scoop back in!) In some special cases, other materials might also be required. (e.g. turrets may need an energy source (e.g. radioactives), computers and other equipment, too)
• It is unknown yet whether or not, and if so, how much cargo space the ERS will require for installation. Our technicians are working hard to minimize this, but at the moment it fits only in ships with the approximate size of an Anaconda, requiring 500 units of cargo. ** But hey, we've just started working! Announcing the system already now will raise our value on the market, giving us the refunds needed to finish the development! So don't be shocked, but go buy our shares and become a shareholder of one of the most promising companies of the future!
• The system will be configurable, so that for instance you can prioritize repairs. The default settings will repair damaged turrets first.
• Due to the nature of the equipment, it will only be useful for certain ships***, and will only be offered for purchase if your ship meets the requirements.
• We don't know how much high-tech will be required, yet, but we think that star systems which have access to the Aquarian Shipbuilding Corporations' Repair Bots will also be capable of offering our product once it's ready. ****

GGIndustries seeks a close relation with its' customers and is therefore open for comments and suggestions.

Notes:
* Our technicians are not fond that we picked an engine with such high radiation levels - but it was the cheapest available engine with enough power. Since they want to end their exposure to the radiation, they've made reducing the energy usage one of their primary goals, so that the engine can be replaced by a less powerful one. Who says we don't know how to motivate our employers??
** I'm planning on making the cargo space required for installation a user-configurable option... I think the default will be for it to require approx. 5 tons of cargo space. If anyone has a ship which can't afford that much, he might still reduce the amount of space needed... Suggestions are most welcome...! UPDATE v.0.0.3: since the amount of alloys needed is pretty high, I've got the feeling that it will not be nescessary to make the equipment use cargo space. But still not sure on this...
*** ships with (frangible) subentities
**** the tech-level will be roughly the same as for Thargoids' repair system I think

Credits
Idea:

• Thargoids'  Repair Bots/Ship Repair System
• The Falcon-S from the Kestrel & Falcon OXP with all it's frangible subentities
• Oolite 1.77's "subentity get hit first-bug" (fixed by cim)

code inspirations and coding help:

• Thargoids'  Repair Bots/Ship Repair System
• Solonars' [wiki]Turret Toggler[/wiki] (howto remove subentity)
• Eric Walch for helping with HowTo detect that a subentity has been destroyed
• cim, Thargoid, spara, Diziet Sma, Smivs, Wildeblood, Rorschachhamster, Commander McLane, Lone_Wolf, Tricky, ... and many more members of the Oolite-community for countless hints, tips and ideas and helping me understand
• Svengali for his awesome OXPConfig
• Oktis' MinerPod.oxp showed me howto change the cargo (player.ship.manifest)
• Eric Walchs' modifications to Dr. Nil's Ore Processor showed me how to simulate energy usage

================= NEWS ========================

Version 0.0.4 is now available for download. This one is even a little bit "playable"!

// //////////////////////////////////////////////////////////////////////////
// CHANGELOG:
// Changes from 0.0.3 to 0.0.4
// - energy and time usage:
// - added timers for repair and energy drain
// - renamed sounds to make them unambigous, and more sounds
// - more efficient sound handling (reuse SoundSources)
//
// Changes from 0.0.2 to 0.0.3
// - save/load ERS status with/from savegame
// - made estimations for needed materials more precise in order to make them more useful
// - made time estimation dependent on real time required
//
// Changes from 0.0.1 to 0.0.2
// - added sound when starting repair (still rudimentary test only)
// - repairs now cost something (exactly as much as calculated) - TODO: examination mode: if repairs cost more than estimated, stop repair and notify player
// - if they cost less, notify player, too (TODO: only in terms of material, or time also? Hmmmm...)
// - now estimations on expected repair costs (required materials and time) can be done (although times are still unused yet)
// - when repair failed because of insufficent material, auto grant estimation (if enough time has been spent).
// - improved program structure, some code cleanup
//
// Changes from 0.0.0 to 0.0.1
// - resolved a bug that prevented the equipment to work properly if this.$compatibleWithAllShips was set to true
// //////////////////////////////////////////////////////////////////////////

Features and limitations of this alpha version (0.0.4):

• working: does need materials for repairs
• working: need s time and energy for repairs
• limitation: repairs / damage evaluations can't be paused and later resumed yet
• limitation: many planned configuration options not implemented yet
• working with limitations: emergency repair (repairs turrets first) (does this very dumb though, also trying to repair an item which already failed before due to lack of materials)
• working: selective repair
• working: store ERS-data when game is saved!
• working: examine subentity to get estimations on needed time and material
• TODO: many more which I don't remember right now

Download
you can download the alpha-version from my box: GGIndustries_ExternalRepairSystem_0.0.4_2013_02_27.oxp.zip

playable beta-versions will be available for download soon (hopefully)

[Thargoid]

Restoring sub-entities in-flight could screw up certain advanced ships which deliberately use sub-ent variations in-flight, for things like activating/removing turrets or to simulate carrying/dropping off hardware. An example of that is my Vortex, which uses this to switch off its turrets (it's the code that Solonar based his turret switcher off too).

I can easily block this equipment in the Vortex case, but there may be other ships out there which would get messed up by this. They should be quite rare, but it may need some consideration about what can be restored (and when).

[Smivs]

Will this affect subentities deliberately removed by script?

[Eric Walch]

Will this affect subentities deliberately removed by script?

You can't just restore a single subentity. When restoring, first all remaining subs are removed and than all subs are initiallised from scratch. So, any oxp that stores info in subent properties of in its script, will lose that info.

[Thargoid]

That being the kind of scenario I was referring to above. Missing sub entities aren't always because they have been shot off.

[GGShinobi]

Thanks everybody for the feedback. I hadn't considered this, yet. I see it's more complicated than I thought. (Isn't it always?)

Will this affect subentities deliberately removed by script?

You can't just restore a single subentity. When restoring, first all remaining subs are removed and than all subs are initiallised from scratch. So, any oxp that stores info in subent properties of in its script, will lose that info.

I don't know how subentities are added when they are restored, but I hoped it would be possible to do something like "new subentity(owner: player.ship)" - that is, just create a new subentity of the same kind like the one that got destroyed, instead of restoring them all.

If that is not feasible: what do you think about the idea to save all existing "player.ship.subentity[x].script"s somewhere before calling "restoreSubentities()", and re-assign them after the call?

And that brings me to my next question: I'm using

Code: Select all

player.ship.subentity[x].script.shipDied = function(whom, why) { ... my code here ... }

to be able to notice when a subentity has been destroyed. But when I do this, any subentity.shipDied()-function that already existed prior to my redefinition will be overwritten, am I right? If so, I've got 2 questions:

• what's the best way to check if such a function already exists? I'd guess if (player.ship.subentity[x].script.shipDied) {...} would do the trick (but haven't tested it yet)
• is it possible to "extend" a function that already exists? That is, keep it's original code and add additional code to it? I'd be very surprised if that was possible, but I ask out of curiosity (if I'm not wrong, Ruby allows something like that?)

And yet two other questions:

• is "shipDied()" only called when the ship dies a "natural" death, or also when it is removed by scripts?
• would it be possible to automatically detect if a certain ship is already doing fancy stuff with subentities. (I'd guess I need to check if subentity.script is empty, if not => fancy stuff)

I'm asking because I want to evaluate my options of determining the compatibility of the current player.ship, and add appropriate exceptions if necessary (e.g. automatically deactivate the ERS for Vortex after having found out that it is incompatible)

[cim]

what's the best way to check if such a function already exists? I'd guess if (player.ship.subentity[x].script.shipDied) {...} would do the trick (but haven't tested it yet)

Strictly that doesn't check if the 'shipDied' is actually a function, but it's unlikely to be anything else.

is it possible to "extend" a function that already exists? That is, keep it's original code and add additional code to it? I'd be very surprised if that was possible, but I ask out of curiosity (if I'm not wrong, Ruby allows something like that?)

No, but you can do this:

Code: Select all

player.ship.subentity[x].script._shipDiedOld = player.ship.subentity[x].script.shipDied;
player.ship.subentity[x].script.shipDied = function() {
  // stuff to run before original
  this._shipDiedOld();
  // stuff to run after original
}

is "shipDied()" only called when the ship dies a "natural" death, or also when it is removed by scripts?

Maybe.

would it be possible to automatically detect if a certain ship is already doing fancy stuff with subentities. (I'd guess I need to check if subentity.script is empty, if not => fancy stuff)

No, probably not.
1) The subentity script will never be empty, though it might simply be the default ship script.
2) The subentities could be being manipulated from the main ship script, or from a frame callback in a worldscript, or somewhere else.

It might be safer to make a list of ships which have frangible subentities but don't do anything else with them and only allow the system for ships on that list.

[GGShinobi]

cim, thank you again for your awesome answers.

This community is really great!

I'll experiment some more and hope to have a beta version available for download soon

[GGShinobi]

It might be safer to make a list of ships which have frangible subentities but don't do anything else with them and only allow the system for ships on that list.

A good idea - I will use a whitelist, then.

I thought it might be nice to have a variable that ship creators can add to their new ships' scripts to make them compatible with the ERS even when they are not on the whitelist yet, so I wouldn't need to update it every time a new compatible ship is released. Here is what I just added to the ToDo-List of my ERS.oxp:

Code: Select all

// TODO:
//   - check ship.script for presence of variable "GGIndustries_ERS_compatible"
//     - if present, use it's value as reference: allow ERS only if "true".
//     - if not present, use whitelist: allow ERS only for ships that are listed
//     - check for presence: at startup, playerBoughtNewShip, ...?

I'm planning to gather the data for the whitelist through the beta-test

[GGShinobi]

sorry for spamming, but I've got another question:

The wiki page about playerBoughtNewShip() states that "The playerBoughtNewShip handler is called when a new ship is bought. May be needed to re-evaluate the old equipment as buying a new ship does not trigger equipment removal."

But the wiki-entry about isPortableBetweenShips() page says: "true if equipment of this type is kept when buying a new ship." - which sounds to me as if the game will remove the equipment automatically when the value is false.

I'm a little confused now - which one is right? Do I understand something wrong?

[cim]

The equipment will be removed, but event handlers which might normally fire when equipment is removed will not happen. So, if state needs to be changed when equipment is removed or damaged, you need to check for that event handler as well as the equipment-related ones.

[GGShinobi]

The equipment will be removed, but event handlers which might normally fire when equipment is removed will not happen. So, if state needs to be changed when equipment is removed or damaged, you need to check for that event handler as well as the equipment-related ones.

Aaah, now I see!! I guess I'll try to extend the wiki entries a little bit, to make this clearer. (might be I cite you - currently can't think of how to put it better) Thank you again, cim, and also for your answer in the Scripter's cove - very good news indeed!!

[Diziet Sma]

Very interesting project.. those Falcon repair bills were getting a bit much, eh?

[GGShinobi]

Very interesting project.. those Falcon repair bills were getting a bit much, eh?

Yeah, you got it, Diziet Sma!

It might be safer to make a list of ships which have frangible subentities but don't do anything else with them and only allow the system for ships on that list.

What would be the best way to identify a ship for the purpose of creating a whitelist? ship.name?

[cim]

What would be the best way to identify a ship for the purpose of creating a whitelist? ship.name?

ship.dataKey is probably best.