Jump to content

[1.3] REKT Escape Pod Mod - v0.4.5.1 (more fixes)

steedcrugeon

By steedcrugeon
in KSP1 Mod Releases

 Share

Recommended Posts

steedcrugeon

steedcrugeon

Posted
Posted (edited)

BETA Version (v0.4.5.1)

I feel happy enough with the state the mod is in at present to open this up for a 'Beta-test'. Without further ado I present my first Mod release:

Introducing the Recoverable Emergency Kerbal Transport (REKT) escape pod mod.

2ewi40z.png

c9utDOZ.png

DNWcoeW.png

This part mod pack is designed to introduce another means of safely recovering your Kerbals from a mission which may have gone wrong, or possible as a deliberate means of evacuating an orbital station as it makes its graceful descent on a sub-orbital trajectory.

qaM51RR.png

Command:

  • REKT mk1A - Single Kerbal pod with built-in airbrakes for atmospheric re-entry
  • REKT mk1C - Single Kerbal Cryogenic† pod with built in RTG.
  • REKT mk1D - Single Kerbal lightweight pod with inbuilt communications equipment and additional provisions (where applicable)*
  • REKT mk1N - Single Kerbal pod with built-in retro-rockets, which can be automated**, for non atmospheric sub -orbital trajectories
  • REKT Miniature Probe Core - for flying kontainers, has a built in MonoProp thruster.
  • OTAV Core - Single Kerbal lifting body style pod.

Utility:

  • REKT Kompatible Kontainer - a simple freight pod which can store a multitude of provisions***
  • REKT Kompatible Kontainer (KIS Variant) - unsurprisingly, a KIS variant of the REKT Kompatible Kontainer
  • REKT Auxiliary Miniature Parachute - a smaller, slim-line a parachute designed to fit well under the ITA.

Coupling:

  • Surfacemount Hardware REKT - A surface attaching single pod decoupler.
  • Inline Triple Adapter - a 1.25m Inline triple REKT mounting adapter, you might want to cover this with a faring...
  • Inline 12 Hub - A 2.5m inline adapter with the functionality of the Inline Triple Adapter but four times the capacity!
  • OTAV Docking Port - lightly angle inline docking port designed to mate with the front hatch of an OTAV core.
  • OTAV Ring Dock - specialised round docking apparatus, 2.5m dia. Designed for use with OTAV docking clamps.
  • OTAV Clamps - splecialised apparatus to mate an OTAV core pod to the OTAV Ring Dock

Electrical:

  • Standard Utility REKT Fuel-cell - A compact monoprop fuel-cell

Engines:

  • REKT Payload Retro Rocket - a miniature SRB, derived from the same ones in the mk1N, intended for use with the freight pods
  • OTAV engine - small LFO engine derived from the Thud engine.

Aero:

  • OTAV Winglets - bespoke retractable wings for use with the OTAV core.
  • OTAV flap - a precise control surface for use with the OTAV core.
  • OTAV Air Fins - Stabalisaing apparatus to help assist atmospheric flight and incorporating an air-brake.

OTAV Parts

  • OTAV Parts have additional dependencies separate from the REKT mod:
  • REKT-OTAV Deployable Lift Generators rely on using the RetractableLiftingSurface module created by @linuxgurugamer the current version at time of release is bundled with this mod.
  • the OTAV integral landing gear is driven by @Shadowmage 's KSPWheel. They will NOT work without it. current version at time of release is bundled with this mod.
Spoiler

W2Vvel4.png

duX5rEp.png

Additional note - These parts may receive more attention/extra bits if there is interest in it's development.

Localisation is now Supported - as of 23/06/2017 release (any translations offered would be helpful!)

DOWNLOAD:

Primary: Github

Secondary: SpaceDock

download and copy the SHED, KSPWheel and RetractableLiftingSurface directly into the your KSP GameData folder.

Licensing: 

The contents of the REKT mod are distributed a CC-BY-NC-SA International License (please refer to the license file on github for further details). Any included mods  are under their own licenses.

Highly Recommended Supporting Mods:

REKT is a stand-alone parts mod and does not have any other mod dependencies, that said, it has been designed around the utilisation of supporting mods and it is highly recommended that you add them to your collection (they are very useful in their own right).

Module Manager will implement the supporting modules, so you'll need that to (if you haven't already got  it).

The REKT mk1C is compatible with @JPLRepo's DeepFreeze Mod (designed specifically for this purpose)

*Supported Life Support Mods:

  • TAC LS
  • USI LifeSupport
  • Snacks

**Landertron is required for automatic functionality

***InterstellarFuelSwitch is required for variety of cargoes

†DeepFreeze is required to use the 'cryogenic' aspects of the pod. [Its will act as a normal pod with an RTG without this mod. It can be removed from your REKT installation if desired]

KIS functionality is now supported through the REKT Kompatible Kontainer (KIS Variant) 

I must extend my thanks to @Snark, @Kerbas_ad_astra @DStaal and @linuxgurugamer for their input and help. Also thanks to @njmksr and @MaverickSawyer for preliminary testing.

And thanks goes to @CobaltWolf and @dboi88 for help and guidance with texturing.

Also I owe much thanks to @Pak who helped me fix the aero setup for the OTAV (finally).

Change log:

Spoiler
Minor Update to v0.4.5.1 - 05/07/17
Fixes:
- Up-to-date version of RetractableLiftingSurface (1.4) fixes roll problem
- amended OTAV localisation patch typo
- Fixed KSPRescuePod patch courtesy of DStaal
 
Update to v0.4.5 - 06/2017
Fixes:
- Fixed OTAV Hatch obstruction issue
- Further revisions to the OTAV model aerodynamics
New:
- Added Landing gear to the OTAV model using KSPWheel
- KSP-AVC version file now added. Compatible with KSP-AVC/MiniAVC (if present)
Other:
- OTAV Folder re-structure
- Deprecated old OTAVcore and OTAVairFins
- OTAVairBrake now removed (no longer supported)
- Implemented Localisation
- Implemented 'SHED WORX' Agency

Update to v0.4.4 - 20/05/2017

Fixes:

- corrected Agency config error

- restructured the SHED/Parts folder splitting REKT and OTAV

- revised model for OTAVcore

- revised OTAV textures

- Minichute scaling issue during animation

New:

- Inline 12 Adapter

- normal Textures added to all REKT mk1 pods.

Other:

- implemented revised emergency power generator for the Cryopod

v0.4.3.1  - recompiled v0.4.3 (see below for contents).

Update to v0.4.3 - 18/01/2017

Fixes:

- minor textures tweaks

- re-modelled the OTAV airbrake

New:

- RPM now supported

- OTAV in-line dock added

- OTAV ring dock added

- OTAV docking clamps added

Other:

- Indicator lights patch updated

- Community Tech Tree patch updated

- Deprecated the OTAV AirBrake

Update to v0.4.2 - 27/12/2016
Fixes:
- Correct RAMP RealChute Patch Syntaxt error (causing parachute to break).

New:
- Added OTAV IVA.

Update to v0.4.1 - 23/12/2016

Fixes:

- Implemented buoyancy update to mk1A, mk1N, freight Pod and KIS pod.

New:

- Added mk1C Cryo Pod (This part requires the DeepFreeze mod to be present in order for the Cryogenics to function).

- Added Probe Core

- Added OTAV parts

- Updated Indicator Lights Patch

Update to v0.4 - 27/11/2016

Fixes:

- corrected a texture issue with the rektMk1A

- changed some of the rescale factors and moving some attachment nodes to transforms on various models.

- adjusted the Module Manager patches to accommodate for the new parts.

New:

- Monoprop Fuel Cell added

- New KIS container added

- Mini SRB added (Landertron compatible)

Update to v0.3.1

Added the missing 'Spaces' folder. IVA's should now appear.

Update to v0.3 - 30/10/2016

Fixes:

Stopped Kerbals sligding off the pod when on EVA.

Adjusted 'door' attachment node.

Removed the option to surface mount to the Inline Triple Adapter to resolve 'detaching issues'.

Other minor config node and module corrections.

New:

IVA's for all pods.

RAMP (REKT Auxiliary Miniature Parachute) desgined specifically to resolve the stock chute clearance issue.

Released as v0.2 - BETA "REKT Escape Pod Mod" - 25/10/16 This is the first release version - Please note it is still in BETA and feedback is welcomed. It is HIGHLY RECOMMENDED that you use this mod with the following mods:

IndicatorLights

Landertron

Imminent Additions (Soon™)t:

rework to OTAV clamps to include RCS

rework to OTAV core to include RCS

new part - OTAV OMS block

Planned additions:

IVAs for the pods (still WIP on those at present)

Create the mk1C - a REKT equivalent Cryo-Pod, specifically designed for use with DeepFreeze

Properly update TAC-LS patch

Finish the mk1C animation components

Additional MM config patches for the StageRecovery Mod to enable more autonomy of the pods (and allow for concurrent multiple suborbital trajectories without risk of the core game 'scrapping' the pod.

Further integration of Indicator Lights (extra, more clever bitz). 

Accessories!

KIS variant of the Freight Kompatible Kontainer

More adapter parts (bigger, better).

Way down the pipeline is for a custom plugin that would replace the 'probe module' in the mk1A (and possibly mk1N).

Feedback and suggestions:

Always welcome, if you have any ideas which you might like to see implemented let me know and i'll see what can be done!

Edited by steedcrugeon
minor update v0.4.5.1 with fixes
Link to comment
Share on other sites
Deimos Rast

Deimos Rast

Posted
Posted (edited)

a lot of pods have retro rockets for braking, but airbrakes?! Madness! I like it.:)

that being said, the fact that you included landertrons is awesome, as I am a big fan of that mod.

My only suggestion is move some of the pictures from the dev thread over here, since the ones here currently don't show it off that well (i.e. either covered in flames or at a distance).

Cheers.

 

EDIT:

I got a chance to play with it a bit; here's my feedback.

- Really like the Tri-Decoupler idea, but when I used it, it didn't work (pods stayed attached). Activated via action group; saw the smoke fire - pods stayed firmly in place. This might be user error - will try again. (EDIT2: Turns out I may have forgotten a decoupler or three). Although, looking at the configs, it should have worked without the decoupler. Maybe switch it to an anchored decoupler instead of a regular decoupler?
- Your attachnodes are where your hatches are. This makes it impossible to EVA from an attached pod.
- Add airbrakes to Brake actiongroup? I can see pro's/con's either way.
- EVAing = sliding off the "ladder", almost impossible to climb back in after a couple of seconds outside
- Is it a probe or does the kerbal have command? CommNet seems to think it's a probe, but it's connection was non-existent.
- Only tried the Airbrake REKT, but it sinks in water.
- Add Kontainer to FuelTank category. Tags on Kontainer seem to be from Hitch-Hikers?
- Airbrakes work perfectly and I measured their drag on the way down - it successfully slowed my pod to safe parachute speeds.
- Consider using "GenericSpace1" for your placeholder Internal IVA. It'll give you a portrait and a barebones IVA.

Request: Would like to see custom parachutes that fit under the decoupler head.

 

REKT Kontainer has a missing "{" in the ModuleFuelJettison, which seems to have been converted into an extraneous "}" down below. 

	RESOURCE
	{
	name = Ore
	amount = 0
	maxAmount = 90
	}

	MODULE
	
	name = ModuleFuelJettison
	}


}
		
	
	
}

 

Edited by Deimos Rast
Link to comment
Share on other sites
steedcrugeon

steedcrugeon

Posted
  • Author
Posted
7 hours ago, Deimos Rast said:

a lot of pods have retro rockets for braking, but airbrakes?! Madness! I like it.:)

that being said, the fact that you included landertrons is awesome, as I am a big fan of that mod.

My only suggestion is move some of the pictures from the dev thread over here, since the ones here currently don't show it off that well (i.e. either covered in flames or at a distance).

Cheers.

 

EDIT:

I got a chance to play with it a bit; here's my feedback.

- Really like the Tri-Decoupler idea, but when I used it, it didn't work (pods stayed attached). Activated via action group; saw the smoke fire - pods stayed firmly in place. This might be user error - will try again. (EDIT2: Turns out I may have forgotten a decoupler or three). Although, looking at the configs, it should have worked without the decoupler. Maybe switch it to an anchored decoupler instead of a regular decoupler?
- Your attachnodes are where your hatches are. This makes it impossible to EVA from an attached pod.
- Add airbrakes to Brake actiongroup? I can see pro's/con's either way.
- EVAing = sliding off the "ladder", almost impossible to climb back in after a couple of seconds outside
- Is it a probe or does the kerbal have command? CommNet seems to think it's a probe, but it's connection was non-existent.
- Only tried the Airbrake REKT, but it sinks in water.
- Add Kontainer to FuelTank category. Tags on Kontainer seem to be from Hitch-Hikers?
- Airbrakes work perfectly and I measured their drag on the way down - it successfully slowed my pod to safe parachute speeds.
- Consider using "GenericSpace1" for your placeholder Internal IVA. It'll give you a portrait and a barebones IVA.

Request: Would like to see custom parachutes that fit under the decoupler head.

 

REKT Kontainer has a missing "{" in the ModuleFuelJettison, which seems to have been converted into an extraneous "}" down below.

I'll see what I can do with regard to jazzing up the images available. In response to your feedback:

- You are correct the triple decoupler should work as you were expecting it to but I have enabled surface attach in the config which is where the issue may arise from. The pods have to be mounted so that they snap to the corresponding attachment node otherwise the decoupler part of the module won't work. [I may disable surface attach in the next version to prevent this issue from happening, in the mean time try this: when in the VAB rotate your view so the pod is facing the triple adapter's node whilst you can see daylight clearly through the gap and move it slowly in until it snaps (apologies if this is teaching you to suck eggs) to the triple adapter.]

- Attachment nodes are where the hatches are current design intent. My rational is that the pod is meant for escaping, so typically when they are part of a larger vessel you wouldn't really be interested in getting in that way. However the pod parts do have surface attach enabled so if you wanted to build a pod sub assembly using a standard radial decoupler and then drag it to your parent part it could work that way.

- I was tempted to put the airbrakes into the default action group but though against it, there is nothing to stop the user from putting them into that action group themselves though. As you say, pros and cons for both.

- EVA sliding ladder issue. Hmm, I thought this had gone away, I'll investigate and see what I can do to fix that.

- Command/probe problem, this was not an issue I have seen before (in my defence I started building this before 1.2 dropped and have pretty much solidly been working on it when I'm not at work or studying). It was intended that the pods could be used for tourists, as such it would need probe control. I was (naively) hoping that if a Kerbal how could command was present it would override the probe module. I may remove the probe module from all but the mk1D as that does have built in comms, the rest do not.

- Sinking pods issue, yep that's WIP problem. I need to resolve the pod's lack of buoyancy.

- I was tying to avoid the Kontainer being used as a fuel tank, more like a resource/parts storage, hence why it's in Utilities. I'll await more feedback and if is general consensus to move it to the fuel tank category I may revise it's current position.

- Airbrakes, glad they work as intended I spent a great deal of time trying to get the balance to work right. It makes it worth while to hear feedback like yours.

- I had not considered this, it'll be good to know for future but the next revision of this mod (v0.3) will have the proper IVA's.

Response to the request: - I was hoping this wouldn't be asked for (spotted the same clearance issue in preliminary testing) as I don't know how to model parachutes yet.

REKT Kontainer config issue: - good spot, I hadn't seen this one yet. I'll make sure it's captured in the v0.3 revision.

Link to comment
Share on other sites
Deimos Rast

Deimos Rast

Posted
Posted

good to hear back from you.

Airbrakes = why did you go with lifting surfaces instead of the actual aero surface that the stock airbrake uses? Just curious. There are a couple of fields it has that you don't, which may be of negligible worth.

To clarify the probe thinger: I was in Kerbin orbit, and didn't have any issues with control. The CommNet icon registered it as a probe, but that's the only icon I got, no connection bars or anything (this was with the airbrake model). I have the option "requires connection for control" enabled, so I'm pretty sure everything is working as you'd like. It just seemed slightly odd to me, is all.

The decoupler thing: I think the issue is you're not using an AnchoredDecoupler, which all stock radial decouplers are, in the triple decoupler inline piece. That's my take on why it didn't decouple for me. Otherwise, if it is like you say, requiring precise node snapping, that seems a tad difficult. It also doesn't leave much room for a parachute (I had moved mine down a bit).

One final point: I noticed the antenna on the one pod has a windresistance rating, meaning it can be broken at high Q. It used to be with RemoteTech that if the antenna being broken off was a part of the root part, it would cause a kraken attack, so I thought that might be the case here as well. I tested it out, deploying it during reentry, and surprisingly no ill effects happened when it broke off.:)

Cheers.

Link to comment
Share on other sites
steedcrugeon

steedcrugeon

Posted
  • Author
Posted

@jrolson Very nicely presented video, thanks for taking a look at it man!

5 hours ago, Deimos Rast said:

Airbrakes = why did you go with lifting surfaces instead of the actual aero surface that the stock airbrake uses? Just curious. There are a couple of fields it has that you don't, which may be of negligible worth.

The decoupler thing: I think the issue is you're not using an AnchoredDecoupler, which all stock radial decouplers are, in the triple decoupler inline piece. That's my take on why it didn't decouple for me. Otherwise, if it is like you say, requiring precise node snapping, that seems a tad difficult. 

for the airbrakes; liftingSurface allowed me to have more granular control over how the additional drag was imparted to the part. The stock airbrakes module did unusual and unpredictable things to the part in flight which i couldn't get to play nice.

originally i had anchoredDecouplers but (even when i made it invisible) they left an 'artifact' on the jettisoned part which changed the 'control from' point on initial craft switching. Module decouple is neater, by you are correct in that usually it would be used in the vertical plane.

Link to comment
Share on other sites
DStaal

DStaal

Posted
Posted

I dropped in a PR on Github with ConnectedLivingSpaces configs.  Fairly basic: You can enter the escape pods via the door (but only via the door), the rack is fully passable, and the decoupler is passable via it's attachment nodes or if it is surface attached.

Link to comment
Share on other sites
steedcrugeon

steedcrugeon

Posted
  • Author
Posted
14 hours ago, DStaal said:

I dropped in a PR on Github with ConnectedLivingSpaces configs.  Fairly basic: You can enter the escape pods via the door (but only via the door), the rack is fully passable, and the decoupler is passable via it's attachment nodes or if it is surface attached.

Thanks for that, I'm just going to tweak the part for the inline triple before I push v.03 when i'll merge your pull request as well (i'm removing the ability to surface attach to the inline triple and just leaving the door nodes).

Link to comment
Share on other sites
DStaal

DStaal

Posted
Posted
13 minutes ago, steedcrugeon said:

Thanks for that, I'm just going to tweak the part for the inline triple before I push v.03 when i'll merge your pull request as well (i'm removing the ability to surface attach to the inline triple and just leaving the door nodes).

You're welcome.  I debated putting in the surface attach, but I thought it might make it a bit easier to work with - in case someone thought they were node-attaching, but missed somehow.  But it was a minor thought; mostly I thought it wouldn't hurt.

And you mean all the nodes on the inline, right?  Not just the doors?  Because otherwise all you can do is transfer the between escape pods you've been stuck in since launch...  :wink:

Link to comment
Share on other sites
steedcrugeon

steedcrugeon

Posted
  • Author
Posted (edited)
6 hours ago, ISE said:

I have an idea pitch, what if you could use deep freeze to go into a cry sleep in one of these escape pods? :D 

And thus the mk1C was born...

I'll have to take a look at the DeepFreeze mods internals and see how to implement it.i was originally thinking it could me just tagged onto the mk1D but I think it should have a different IVA and use a tweaked mk1D model to account for the gykol storage. It'd have to have some serious EC though and I'd need to see where I could trade off other factors to incorporate this. minimal supplies, ditch the SAS in order the keep the probe module and comms array (would you want to be able to wake up the kerbal from remote?) I suspect its more likely (balance wise) to be like this:

- Just enough EC storage to freeze a kerbal (User better add a solar panel in the VAB otherwise you'll have to wait until a CLAW comes along to charge the pod).

- No probe Core

- No comms array

- Minimal Supplies (same as the mk1A and mk1N).

- Have an EVA only activity that allows the rescuing kerbal to thaw out the occupant of the escape pod.

- I'll offset this part with additional weight to simulate the extra equipment and try to balance it out against the existing DeepFreeze parts. The escape pod should not be the go-to pod for cryo stasis, only an alternative. it's added utility must be offset with drawbacks (like weight and).

I think these would be acceptable attribute for a DeepFreeze compatible REKT pod. It would serve a useful purpose in flight whilst being suitably limited when jettisoned. Although could lead to difficult situations if, say, a mutinous Jeb were to jettison Bill in his sleep...

Edited by steedcrugeon
Link to comment
Share on other sites
DStaal

DStaal

Posted
Posted

Actually, for the mk1C, how about instead of Supplies you get an RTG?  Freezers require a constant charge (not by default) to run, and where I'd expect to use these most often is in deep space or the far reaches of the solar system, where you're both far from help and far from a star to supply EC.  You don't need supplies while frozen, so an RTG makes more sense, and would be logical to include.

This of course also justifies extra weight and cost.  :wink:

Link to comment
Share on other sites
DStaal

DStaal

Posted
Posted

As a quick look, an RTG (as far as KSP is concerned) is just a ModuleGenerator with no input resources, so it looks like it should be achievable to have it something that can be activated/deactivated.  I'm not sure if there's a way to only activate it once launched.

On the other hand, being really stingy makes sense - work out how much EC DeepFreeze needs by default to keep Kerbals frozen (this looks like it might be part-dependent...) and then only give that much.  You might also be able to set a low required temp to keep frozen - you aren't going to have other active heat sources, after all - but it makes it harder to use as an alternate to the main freezer pods.

(Of course both required heat and required EC are non-default options in DeepFreeze.  So whether you want to use them as balance considerations is up to you.)

Link to comment
Share on other sites
Deimos Rast

Deimos Rast

Posted
Posted

 

21 hours ago, steedcrugeon said:

And thus the mk1C was born...

I'll have to take a look at the DeepFreeze mods internals and see how to implement it.i was originally thinking it could me just tagged onto the mk1D but I think it should have a different IVA and use a tweaked mk1D model to account for the gykol storage. It'd have to have some serious EC though and I'd need to see where I could trade off other factors to incorporate this. minimal supplies, ditch the SAS in order the keep the probe module and comms array (would you want to be able to wake up the kerbal from remote?) I suspect its more likely (balance wise) to be like this:

- Just enough EC storage to freeze a kerbal (User better add a solar panel in the VAB otherwise you'll have to wait until a CLAW comes along to charge the pod).

- No probe Core

- No comms array

- Minimal Supplies (same as the mk1A and mk1N).

- Have an EVA only activity that allows the rescuing kerbal to thaw out the occupant of the escape pod.

- I'll offset this part with additional weight to simulate the extra equipment and try to balance it out against the existing DeepFreeze parts. The escape pod should not be the go-to pod for cryo stasis, only an alternative. it's added utility must be offset with drawbacks (like weight and).

I think these would be acceptable attribute for a DeepFreeze compatible REKT pod. It would serve a useful purpose in flight whilst being suitably limited when jettisoned. Although could lead to difficult situations if, say, a mutinous Jeb were to jettison Bill in his sleep...

I strongly vote in favor of a DeepFreezer. @JPLRepo is an exceedingly helpful individual. I also customized his freezers to make drop pod variants a while back, which were cool, but if you built one specifically designed for that purpose, even better! Have you played with DeepFreeze at all? You can set alarms (and tie into KAC) for waking up Kerbals. He can tell you more about the IVA, but I believe it requires the Advanced Transparent Pods mod, which he also stewards.

 

Other ideas would be a water landing themed thing with airbags. There are a few options for that, but it's plugin territory.

18 hours ago, steedcrugeon said:

Thats actually a really good take on it @DStaal removes the onus on the user to remember a solar panel. Ideally i'd like it so that the RTG is only actvie once the part is launched. Is that achievable? Or do i just make it so that the inbuilt RTG is really stingey on it's trickly feed? 

Yes. There is a line in the ModuleGenerator "alwaysActive = true" set it to false, then the player will have to hand crank the RTG to get it going:D

Link to comment
Share on other sites
DStaal

DStaal

Posted
Posted

Ok, my Kerbals have been running this new addition to their fleet through it's paces, and have some after-action reports:   (Note all of this is in 1.1.3 with pods slightly modified to work in that version of KSP.  Testing focus so far has been on the mk1A, as it's quicker to deploy to test status, and lessons are expected to carry over.  Testing has been with unmanned pods; The thought being you should be able to stuff a Tourist in an escape pod in an emergency.  Also, I crashed ~6 pods before I landed one, so unmanned testing was warranted. :D)

  • Power is limited.  This is not a major problem in the mk1A, as all maneuvers can be done immediately after separation.  It is expected to be a major issue in the mk1N, where power is needed for touchdown as well.
  • Monoprop deorbiters are plenty powerful, though a bit more fuel would be nice - mk1A can only be used in low Kerbin orbit; it would be useful for it to have enough to deorbit from a 250-350km or so Kerbin orbit, high enough for a mid-range Kerbin transfer station or a science station built to run high-Kerbin experiments.
  • Control setup is surprising.  You thrust towards prograde to deorbit.
  • Parachute setup requires tweaking; my space agency is still iterating on this.  The default opens way to high on my normal reentry profile; bringing the default deploy pressure to 0.5 (up from 0.05) atm appears to work, although mountains can cause issues.  :rolleyes:

It's been a very nice pod to work with.  From the above, what I'd like to see is the control scheme fixed, and possibly a battery in the same profile as the parachute - you can't afford to depend on solar for landing in the mk1N, in my opinion, and it needs a bit more power.  A battery would also alleviate parachute setup: I normally fire my parachutes off manually, but that requires active control, and I usually run out of EC well before I enter the atmosphere.  (Although I'm not sure that mountain landing would have been survivable in any case - the parachutes may not have had enough time to slow down the pod even if they'd deployed as soon as it was safe.)

My Kerbals have always liked the idea of having escape pods handy, but the DERP pods have been awkward and ugly to install and to use, as they require an EVA.  (Though their reentry characteristics are superb.)  The REKT pods look to be much nicer both aesthetically and operationally, once the learning curve on their use is worked out.

Link to comment
Share on other sites
DStaal

DStaal

Posted
Posted

Testing continues - A rack of mk1N pods was sent to Minmus (where bases are set up) for non-atmospheric testing.  Monoprop usage was minimal for these, although testing was done from low orbit.  Battery life was a limiting factor, as expected - even with an extra battery attached it took careful management to maintain power availability until landing.  On the other hand, the idea of attaching a DERP monoprop fuel cell to one worked flawlessly, and supplied more than sufficient power all the way to landing.

Reaction-wheel control was sub-standard, however.  It appears the mk1N has issues being able to hold a position in space - this is awkward, as it is the sole pod that *requires* holding a specific orientation.  The wobbling under SAS was a significant part of the drain on EC - it's recommended therefore that users not turn on SAS until within ~1km of the surface or less, to reduce power usage.

As a side-note, the optional Landertron software pack works fairly well - but users of the pods should be aware that the software only appears to consider *vertical* velocity to the surface.  It is advised to reduce horizontal velocity as much as possible during the initial de-orbit burn.

As a final note: While the mk1A gets set neatly on it's bottom by the parachute, the mk1N is much more likely to tip over during landing.  As these tests were unmanned it is uncertain whether the extended landing rockets provided enough clearance to exit safely, but it is worth bearing in mind for future rescue operations: The pod may need to be rolled over before the occupant can be retrieved.

Also, Bob's idea of hacking a parachute casing to store extra monoprop appears functional, although more work is needed on the paint scheme.  :wink:  Testing has been authorized for the battery and fuel cell variants.  (I’m hacking at these - though I'm trying to figure out how the texturing works in KSP and not having much luck so far.)

Link to comment
Share on other sites
This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
 Share
Go to topic listing
×
×
  • Create New...