Sanity check, or a humble request to the mightier modders.

[steedcrugeon]

I have begun modelling a part with a very specific purpose for one of my mods (REKT) however I feel it would really benefit from a custom plugin.

I was hoping to ask those of you knowledgeable in the ways of the plugin if this was viable as a part module:

I was thinking along the lines of 'ModuleAbandonShip'

The part would also have the stock 'ModuleDecouple' to which the REKT pods would attach (default set to high jettisoning force).

The 'ModuleAbandonShip ' would have a toggle action of 'Abandon Ship' Which would (automatically) pull kerbals from surrounding parts from the vessel, starting from the nearest part, and put them into a waiting REKT pod (attached to this part). With a REKT pod manned it would fire/trigger the ModuleDecouple without input from the player, jettisoning the pod to safety.

I was thinking this would be done with a delay between each pod launch, both to reduce the strain on the physics/graphics loading and because I think that's how it would be done in real life too, to avoid collisions.

On top of this (and this may be a bigger ask) is the plan that each pod 'bay' on the part with ModuleAbandonShip would have it's own frangible seal over, which would behave like stock fairings (in the sense that its plays nicely with aerodynamics and the like for launches but when fired its becomes physic-less and disappears (is not debris). An alternative would be a single frangible cowl or faring over all the pod 'bays' and when the first one is launched it jettisons the cowl).

Is this something that a single .dll could do? If so, who do I buy beer/biscuits for that could help me achieve this?

[Diazo]

The issue is that you talk about "a" part (singular) and part"s" (plural) in your post.

Notably you talk about ModuleDecouple (joins two parts together) and a part that has launch bays, but no mention of how the launch bays will hold pods.

Are they going to be clip-in where you add the launch bays part, then add each pod to a bay in the editor? Or will it be one part where you add the launch bays part in editor and the pods magically appear when you actually abandon ship?

Both methods are possible, but very different in code.

D.

[steedcrugeon]

29 minutes ago, Diazo said:

The issue is that you talk about "a" part (singular) and part"s" (plural) in your post.

Notably you talk about ModuleDecouple (joins two parts together) and a part that has launch bays, but no mention of how the launch bays will hold pods.

Are they going to be clip-in where you add the launch bays part, then add each pod to a bay in the editor? Or will it be one part where you add the launch bays part in editor and the pods magically appear when you actually abandon ship?

Both methods are possible, but very different in code.

D.

Good points, let me try to clarify; take for instance the current REKT inline triple adapter. This part has three 'ModuleDecouple' in it's config, one for each of the door nodes that the REKT pods attach to. 

My current plan is that the future single part will X number of 'ModuleDecouple' corresponding to the recesses (bays) on the mesh in the model. Each gets it's own transform (empty GameObject) for the 'ModuleDecouple' to work from. For instance the part 'REKT Launch-Bay 12' would be one part, one model, with 12 'ModuleDecouple' in it's config, along with 'ModuleAbandonShip'.

These 'ModuleDecouple' will also be the attachment nodes which the REKT pods attach too, so no magic materialisation of pods, the player will have to manually add them in the VAB/SPH.

[flywlyx]

On 1/25/2017 at 4:30 PM, steedcrugeon said:

Good points, let me try to clarify; take for instance the current REKT inline triple adapter. This part has three 'ModuleDecouple' in it's config, one for each of the door nodes that the REKT pods attach to. 

My current plan is that the future single part will X number of 'ModuleDecouple' corresponding to the recesses (bays) on the mesh in the model. Each gets it's own transform (empty GameObject) for the 'ModuleDecouple' to work from. For instance the part 'REKT Launch-Bay 12' would be one part, one model, with 12 'ModuleDecouple' in it's config, along with 'ModuleAbandonShip'.

These 'ModuleDecouple' will also be the attachment nodes which the REKT pods attach too, so no magic materialisation of pods, the player will have to manually add them in the VAB/SPH.

I would suggest make a ModuleEscapePod for pod and a ModulePodBay for podbay.  ModuleEscapePod detach the pod itself and do some awesome maneuver after that, ModulePodBay collect kerbonauts，deploy them to pod and tell every pod on it when to deploy. By doing so, your pod is independent from podbay and could work both together and separately. 

Edited January 27, 2017 by flywlyx

[ShotgunNinja]

It is possible to move crew from a part to another one in-code. It is also possible to trigger decoupling (or any other action) in other modules (even if these are in other parts). The 'abandon ship' event in your module can be triggered by action groups (abort, or custom ones). 

Personally I would go like this:

• have a REKTpod module added to all your emergency pods
• have a 'get the hell out of here' event in the pod module, and associated action
  • can be triggered by the player, clicking on a button in the part UI
  • can be triggered by action groups (it may even default to the abort action group)
• when the 'get the hell out of here' event is triggered:
  • scan the vessel for kerbals
  • move the first one inside the pod
  • look for a stock decoupler module in the emergency pod itself, or in the first parent part
  • trigger the decoupler module 'decouple' action

[steedcrugeon]

26 minutes ago, ShotgunNinja said:

It is possible to move crew from a part to another one in-code. It is also possible to trigger decoupling (or any other action) in other modules (even if these are in other parts). The 'abandon ship' event in your module can be triggered by action groups (abort, or custom ones). 

Personally I would go like this:

• have a REKTpod module added to all your emergency pods
• have a 'get the hell out of here' event in the pod module, and associated action
  • can be triggered by the player, clicking on a button in the part UI
  • can be triggered by action groups (it may even default to the abort action group)
• when the 'get the hell out of here' event is triggered:
  • scan the vessel for kerbals
  • move the first one inside the pod
  • look for a stock decoupler module in the emergency pod itself, or in the first parent part
  • trigger the decoupler module 'decouple' action

This sounds like a good implementation, It would work with all the existing parts of REKT.

if I was to try and extrapolate from, say Kerbalism, this sort of plugin language, where would you advise I look?

I don't mind having a stab at writing my own but if I had some reference to similar instances of code I could at least try to reverse engineer the thing, possible.

[ShotgunNinja]

See here for some basic skeleton code that may get you started writing and compiling plugins.

You create a module class, inheriting from PartModule. Then you add an Evacuate() KSPEvent, and an EvacuateAction() KSPAction that simply call Evacuate(). Tweak both methods metadata (the KSPEvent/KSPAction properties) so that they show the string you want in the UIs, and so that the event button is only available in flight (and not in editor).

using System;
using System.Collections.Generic;
using UnityEngine;


namespace REKT {

 
public class REKTpod : PartModule
{  
  // this is the event: it add a button on the part UI
  [KSPEvent(guiActive = true, guiActiveEditor = false, guiName = "Evacuate!", active = true)]
  public void Evacuate()
  {
    // TODO: (1) find first available kerbal
    // TODO: (2) move available kerbal inside REKTpod
    // TODO: (3) find decoupler module in this part or the parent one
    // TODO: (4) trigger decoupler module 'Decouple' event
  }
  
  // this is the action: it add an available action to the part, for use in action groups
  [KSPAction("Get the hell out of here")]
  public void EvacuateAction(KSPActionParam param)
  {
    Evacuate();
  }

  // this function is called to generate the part tooltip info
  public override string GetInfo()
  {
    return "hey, this actually work!";
  }
}
  
} // REKT

 

Now you only need to implement Evacuate() itself (note that the following has not been tested at all).

// (1), (2): get first crew member, move it into REKTpod

// here we scan all the parts in the vessel
foreach(Part p in vessel.parts)
{
  // we skip parts with no crew
  if (p.CrewCapacity == 0 || p.protoModuleCrew.Count == 0) continue;

  // we get the first crew member
  ProtoCrewMember crew = p.protoModuleCrew[0];
  
  // remove it from the part
  p.RemoveCrewmember(crew);
  
  // and add it to the REKTpod
  part.AddCrewmember(crew);
  
  // we moved the crew member, no reason to keep scanning other parts
  break;
}

// (3) find decoupler module

// first we try to look in the REKTpod part itself
ModuleDecouple decoupler = part.findModuleImplementing<ModuleDecouple>();

// then we fallback to look in the parent part
if (decoupler == null && part.parent != null) decoupler = part.parent.findModuleImplementing<ModuleDecouple>()
  
// (4) decouple
  
// if a decoupler module was found
if (decoupler != null)
{
  // simply call its 'Decouple' event directly
  // this is equivalent to the user clicking on 'decouple' in the part UI
  decoupler.Decouple();
}

 

Edited January 30, 2017 by ShotgunNinja
fixed some minor stuff