Pseudo-autopilot module for an escape pod

[steedcrugeon]

I'm toying with making a 'bolt-on' escape pod akin to many a sci-fi film, you know the sort, single kerbal pre-built coffin tube etc. One of the key sticking points I can see is this requirement I have placed on myself:

 "pod must be capable of re-orienting and holding retrograde without user input once stage/launched/deployed" - the logic is that you could put your passengers in one of the pods and fire them out of it and not worry about having to take control of the vessel.

I'm thinking that this would need a specialised SAS along these lines:

public class EscapeAutopilot : ModuleSAS
{
	[KSPField]
	public override bool VesselAutopilot.Enable (AutopilotMode Retrograde)

	public override bool VesselAutopilot.SetMode (AutopilotMode Retrograde)
	
}

I was planning on writing something in the part config file like:

MODULE
{
	name = EscapeAutopilot
	{
		Enabled = true
	}
}

Am I on the right sort of track here or way off?

[Electr0ninja]

I don't think you can retain heading control once a craft leaves the physics load range, the on rails system will just kill them, however if you just want it to face retrograde while the module is active, that can definitely be achieved.

Although if you want a pod that just jettisons and lands outside physics range, you can do so, it will just take a bit of jury rigging.

 

And so far, your code looks decent, but I haven't messed with ModuleSAS classes yet.

Edited October 2, 2016 by Electr0ninja

[pellinor]

Do you really need an active control or would it be enough if the object is aerodynamically stable (supposing an atmosphere)? If you drop a dart from space it should always orient itself along the airstream (hopefully before burning up, so you'd need the right amount of stability).

Edited October 2, 2016 by pellinor

[steedcrugeon]

My plan is that the part would be aerodynamically stable as well. But i'd like to be able to launch multiple from staged so the initial kick and setup as they leave whatever stricken vessel will have them all in physics range. the though being that by the time they are out of physics range they'll all be on a decent retrograde trajectory and the aerodynamics will take over.

@Electr0ninja i was planning to make the part a probe (without occupant control - or possibly with 'crew override') but this jury rigging intrigues me. mMy hope is that, if the crew launched as a batch they would all come down roughly within physics range together, but if I could 'force physics' for the duration of each vessels flight that might work if they go astray (which is quite possible i'd expect). Would the alternative be to have a short script that looks at the descent parameter of each module and then calculates the likelihood of survival given a list of set parameters and then with 'on-rail' physics either destroy the craft on impact of have it magically appear on the surface?

@pellinor I 'm looking at it in the sense that these may either be singly surface attached or in another custom part in block form so when they are staged there is no knowing as to whether thy will be in a decent position for return. a short burst from 'jettison' module should get them clear and then the autopilot will take over the aiming and a slug of SRB will fire to get them home.

Edited October 2, 2016 by steedcrugeon

[Electr0ninja]

If a craft has a suborbital trajectory and leaves physics range it will not land, it will crash and aero will not be applied. It would have to calculate a decent trajectory, have the ship magically appear on the surface with a fail percentage, and cause a time skip to simulate decent for the pods. If I understand you correctly.

Edited October 2, 2016 by Electr0ninja

[steedcrugeon]

8 hours ago, Electr0ninja said:

If a craft has a suborbital trajectory and leaves physics range it will not land, it will crash and aero will not be applied. It would have to calculate a decent trajectory, have the ship magically appear on the surface with a fail percentage, and cause a time skip to simulate decent for the pods. If I understand you correctly.

ah, I understand. This part would need to have another MODULE attached that runs a function to calculate its chances surviving then activate the 'magically-appears-on-surface' after a given delay. More reading for me to do then. 

[Electr0ninja]

That sounds pretty cool.

[steedcrugeon]

Okay can someone more experienced than me possibley point out where i'm going wrong here? Visual studio does no like this code:

 

namespace Test_for_1._2
{
        public class ModuleKEEP : PartModule
        {
            public class escapeAutopilot (Vessel escapePod) base.OnStart;
        
            public class escapeAvionics : ModuleSAS
            {
                [KSPField]
                public override bool VesselAutopilot.Enable(AutopilotMode Retrograde);
                public override bool VesselAutopilot.SetMode(AutopilotMode Retrograde);
            }
		}
}

 

[Crzyrndm]

Yea, that's never going to work. The short version is that your knowledge of basic C# syntax is missing

Some possibly helpful links

• http://www.learncs.org/ - You can't write anything if you don't understand the basics
• http://wiki.kerbalspaceprogram.com/wiki/Tutorial:Creating_your_first_module - Start with something that actually works in KSP

Edited October 4, 2016 by Crzyrndm

[steedcrugeon]

@Crzyrndm Thing is I didn't want to try and nest the class within in a class but even with the correct referenced couldn't drag through the components I wanted without using this weird arrangement.

All I was hoping to achieve was to override the SAS settings without user input by having this function within the MODULE.

I can't find a clear breakdown of the hierarchy of the KSP parts - I'm pretty sure the VesselAutopiot can't be an actual MODULE in the conventional sense but without bounding it to a module how would I be able to call it from a part's config file? The new API is very useful but because it's just a dump from doxygen its not abundantly clear to me.

I understand the basics (and I mean basics) but the VesselAutopilot isn't like adding a heat alarm, or messing about with a lifting surface. At least its not behaving as it would expect  from what I have read and what I have seen in some of the tutorials on this subject (I can't inherit the components I want through it, or VS isn't seeing them).

Edit: oh I think I done a stupid. I may be overcomplicating it

 

Edited October 4, 2016 by steedcrugeon
too slow.

[Crzyrndm]

• You can't "call" anything from a config file. A config file sets variables (and only a limited group of types at that), it doesn't drive any logic
• Unless I'm very much mistaken, ModuleSAS doesn't know anything about how to control the vessel. It's most likely just a data wrapper for telling module command what level of SAS this part is allowed without a pilot present
• VS is freaking out because it doesn't understand what you're writing.
  • Line 5: You can't declare a function with "class" in it's specifier. You can't have parameters in a class declaration.
  • Line 10: Function names can't have "." characters in them.
  • Nowhere is there any implementation for any of these functions/classes

The following is something like how I would envisage the plugin working (note: before you say it doesn't work, it's the start of a module for syntax demonstration since that's the bit you're missing entirely)

class LockHeadingModule : PartModule
{
  // add to parts to trigger locked heading mode when staged
  // module only used as a flag for the vessel module
}

class LockAutoPilot : VesselModule
{
  public override Activation GetActivation()
  {
    return Activation.LoadedVessels;
  }

  public override bool ShouldBeActive()
  {
    return vessel.loaded;
  }

  protected override void OnStart()
  {
    foreach (Part p in vessel.Parts)
    {
      if (p.isActiveAndEnabled && p.Modules.Contains<LockHeadingModule>())
      {
        vessel.Autopilot.Enable(VesselAutopilot.AutopilotMode.Retrograde);
        break;
      }
    }
  }
}

Please, atleast read through a C# tutorial and follow through the KSP wiki tutorial I linked earlier

[steedcrugeon]

This, is the kind of clarification I was looking for. I greatly appreciate it. I'm quite rusty at programming C# and this clearly shows it.

Those first five lines make this much clearer already! I was under the impression that VS would only perceive the PartModule components if there were childed, I did not know you only need to 'flag' them in order for it to be visible to VS!

The reason I was using ModuleSAS was that from what I could read across from the released API was that it is parent to VesselAutopilot and I'd need to set that. (this is what I mean about I cannot find anywhere to see a breakdown).

I can see from your text I really was going about it entirely the wrong way. More reading for me then, thank you for the link I'll check it out shortly.

just to see if I understand correctly does this line:

if (p.isActiveAndEnabled && p.Modules.Contains<LockHeadingModule>())

mean that the part in question, as seen by KSP, has been staged (Active) and is currently being 'flown' (Enabled)  and contains the LockHeadingModule would only function after the part has loaded? Meaning it would have to been loaded as the root part? 

I just want to make sure I'm reading as how I read it at the minute a part containing this module would override the controls if it were loaded separately. Would it need another line of code in order for it to activate after it was staged (if the part is not the root part when loaded).

thanks for your responses so far @Crzyrndm, that have been very informative.

 

[Crzyrndm]

What I meant by "flag" is that I could then search for parts with it in the vesselmodule. ie. the presence of the module in a part acts as my condition for a behaviour

The logic for the vessel module:

• ActiveAndEnabled: Checked part has been staged (That was the intention anyway. I can't recall if that's exactyly what the property means)
• Modules.Contains<LockHeadingModule>(): Checked part contains the flag module (that I'm using to trigger the behaviour)
• The foreach loop goes through every part on the vessel, so it's not just the root part that gets checked
• The activation condition of the vesselmodule indicates that it will run on any vessel spawned in the physics bubble (this is why I used the vessel module. You automatically get 1 per vessel instead of trying to synchronise part modules)

[AndyMt]

Just an idea: you might look into what the StageRecovery mod is doing. Because I think this is exactly covering the "fall back into atmosphere and recover the thing" part.

So as a start you could just implement thrusting retrograde and then let StageRecovery do the rest of the job.