[WIP] mini reentry pod aka escape pod

[DStaal]

1 hour ago, TiktaalikDreaming said:

Well, they're docking nodes because decouplers are a stage, and one stage per part.

Put the decouplers on the shroud.  (REKT has a similar part with several decouplers built in.)  Leave the top of the pods as docking ports - then you can rescue them (when they can't deorbit themselves) with a dock.

[TiktaalikDreaming]

Just now, DStaal said:

Put the decouplers on the shroud.  (REKT has a similar part with several decouplers built in.)  Leave the top of the pods as docking ports - then you can rescue them (when they can't deorbit themselves) with a dock.

Similar ideas had started circulating in my head.  Knowing it works (and what mod it works in) helps heaps.  Thanks

It's possible the shroud thing will work with those nodes as just stack nodes as well.  Assuming a docking node will disconnect from a connected stack node.

[TiktaalikDreaming]

Well, quick testing suggests any old stack node will do.

And that I need to make it a teeny bit easier to exit the cradle.  Got myself stuck.  But, it all basically works.

 

[TiktaalikDreaming]

...and, minor tweaks, and all six nodes are working, and the escape pods can escape from the cradle now.

Just have to do that texturing stuff.

[TiktaalikDreaming]

So, I'm thinking of ditching the scolloped semi shroud thing in favour of some sort of door system. Thoughts?

The curves don't seem quite right to me

 

[steedcrugeon]

Looks Ace @TiktaalikDreaming I think parts are very nicely done indeed and I note some similar design philosophy's between REKT and your mod. May I recommend the use of the 'NoAttach' tag for the collider of the escape pod mounting adapter. I find its very useful in deterring people form accidentally putting things in front of fitted escape pods.

[DStaal]

2 hours ago, steedcrugeon said:

Looks Ace @TiktaalikDreaming I think parts are very nicely done indeed and I note some similar design philosophy's between REKT and your mod. May I recommend the use of the 'NoAttach' tag for the collider of the escape pod mounting adapter. I find its very useful in deterring people form accidentally putting things in front of fitted escape pods.

Please no.  Preventing people from being stupid is futile - and this thing just cries out for warning lights and service handrails. 

(And yeah, on this part I think the polygon count on the curves seems a bit low.)

[TiktaalikDreaming]

It does occur to me the curve is formed by shifting heights of the outside curve of 24 vertices, to match a 24 vertex circle on one sixth of the diameter. I may need more subdivision. I'm thinking, I should redo that bit before deciding on doors.

[DStaal]

I do think it looks good, and sleek enough without doors.  (Which would be a possible problem for an escape pod - if you're in an escape pod, it's because there are things going seriously wrong with the ship you were in - are you going to rely on the doors working?). If you can get it so it doesn't look like it was cut out with a set of big tin snips, I think it should be fine.

[TiktaalikDreaming]

38 minutes ago, DStaal said:

I do think it looks good, and sleek enough without doors.  (Which would be a possible problem for an escape pod - if you're in an escape pod, it's because there are things going seriously wrong with the ship you were in - are you going to rely on the doors working?). If you can get it so it doesn't look like it was cut out with a set of big tin snips, I think it should be fine.

Yeah, I'm still inclined to leave it without doors.  But people (including myself) do like a nice animation. 

With more polygons, but without redoing the texture (so the corrugations are all wonky);

I also spotted an issue with the colliders due to not fully thinking through "convex".

And I'm updating colliders on the Koose itself, as they were just a single truncated cone.

[TiktaalikDreaming]

A fair bit happier with the side walls now;

I want to add some more internal structure, rather than just some deformed cubes.  But generally, much happier with how the unwrap now allows nice straight stringers/corrugations.  

 

[TiktaalikDreaming]

On 6/15/2018 at 8:25 PM, steedcrugeon said:

Looks Ace @TiktaalikDreaming I think parts are very nicely done indeed and I note some similar design philosophy's between REKT and your mod. May I recommend the use of the 'NoAttach' tag for the collider of the escape pod mounting adapter. I find its very useful in deterring people form accidentally putting things in front of fitted escape pods.

Some of it is and some of it isn't tagged "no attach".  There's actually 18 collider objects for the docking station.  Most of which are unity 3d objects to keep the CPU load down(ish).

I also updated the colliders on the pod itself, which started as a simple truncated cone.  And that's now also a mix of normal and no-attach now.  No connecting extra RCS to the mono tanks for instance

[Beetlecat]

On 6/15/2018 at 6:17 PM, TiktaalikDreaming said:

A fair bit happier with the side walls now;

I want to add some more internal structure, rather than just some deformed cubes.  But generally, much happier with how the unwrap now allows nice straight stringers/corrugations.  

 

I lost track of KSP stuff for a bit -- really like how this is evolving.

[Tonka Crash]

I just installed this today. Two comments: Is there a right way up for the parachute? It seems a little confusing installing it, but I haven't flown it yet to see if it matters. Maybe change the stripes on the part to chevrons or arrows to indicate up, ////\\\\ instead of ||||||||. Also, could a patch be added to the KooseCradle for ConnectedLivingSpaces compatibility at some point? I've patched it locally for now.

@PART[KoosSECradle]:NEEDS[ConnectedLivingSpace]
{
  MODULE
   {
       name = ModuleConnectedLivingSpace
       passable = true
   }
}

 

[TiktaalikDreaming]

1 hour ago, Tonka Crash said:

I just installed this today. Two comments: Is there a right way up for the parachute? It seems a little confusing installing it, but I haven't flown it yet to see if it matters. Maybe change the stripes on the part to chevrons or arrows to indicate up, ////\\\\ instead of ||||||||. Also, could a patch be added to the KooseCradle for ConnectedLivingSpaces compatibility at some point? I've patched it locally for now.

@PART[KoosSECradle]:NEEDS[ConnectedLivingSpace]
{
  MODULE
   {
       name = ModuleConnectedLivingSpace
       passable = true
   }
}

 

Two answers.

I've looked at ways of simplifying the cute unit's attachment. I hadn't actually considered just altering the look to make it more obvious. It is a passion when the orientation isn't upright (like if it's being installed in the nest).  If I get time this weekend, I'll make some changes.

I am actually working on issues with a CLS patch.  There's an example on the GitHub files (not packed yet; https://github.com/TiktaalikDreaming/KOOSE/blob/master/Parts/KooSE_CLS_RT.cfg).  The problem is, the multiple docked craft seem to trigger CLS into segregating the craft regardless of the settings in the patch.

[Tonka Crash]

Reading about your mod's developmentwith CoM and spinning, have you considered two chutes balanced on either side of the the capsule? I know this would be more work to change the model to add a slot for a second chute, but it might be worth it in the long run.

Edited July 22, 2018 by Tonka Crash
Bonehead typo

[TiktaalikDreaming]

7 hours ago, Tonka Crash said:

Reading about your mod's developmentwith CoM and spinning, have you considered two chutes balanced on either side of the the capsule? I know this would be more work to change the model to add a slot for a second chute, but it might be worth it in the long run.

Yes.  But, if I was to set up 2 chutes on one part, they wouldn't behave like 2 chutes.  Yes, there'd be visual excuses for a CoM as it is matching the centre of where the chute pops out from, but there's all sorts of things that would go wrong.  Or at least wonky.  The main trouble with building a pod with the chute integrated in the same part is the chute creates a drag force at the centre of the chute's part.  So, if it's the main part, then it doesn't provide any directional control.

Also, I'd re-collide with the joys of multiple staging actions on one part.  Or lose the retro deorbit solids.  I did experiment with just a magical central chute to see how it behaved, ignoring the "there's nowhere to release the chute from" feature.  And that still looked dodgy as.  Conclusion: Chutes need to be separate parts, or weirdness ensues.

Edited July 22, 2018 by TiktaalikDreaming

[Tonka Crash]

Last week I finished a contract to put a station in orbit around Kerbin. I had attached a KOOSE Nest so I could drop off rescued Kerbals at the station instead of always spending money on new launches to recover rescued Kerbals to the surface. Caesar  sits around in orbit maintaining the station and waiting for the rescue call, when the Nest is empty, cut it loose and orbit a fully loaded one. 

I finally had a got a Kerbin orbit rescue after a week of retrieving lost engineers around the Mun. Everything worked as planned, but I did run into a few items that could make it easier to use. I'm sorry if these have been mentioned before:

1. In the right click menu of the Nest you have six decouple switches, but I have no idea which switch corresponds to which pod. Being a symmetric part I don't know if it's even docked in the orientation I assembled it in the VAB. Maybe have a number assigned to each switch that's painted on the mesh next to each pod. I ended up mousing around to get the right click menu of the pods to use the decouple node switch on the pod instead of trying to do it on from the Nest. I don't know if localization matters here. 
2. I use the Indicator Lights mod. I've come to rely on it to figure out where Kerbals are hiding in my stations. It would be nice if there were a light either on the Nest,on the reentry heat shield or at least visible from outside the Nest to show which pods are occupied. After I transferred the Kerbal and rotated the camera to figure how to decouple her pod, I got confused over which one I put her in. Even then I quicksaved, decoupled, and made sure I had her in the pod that came out before reentry.
3. I play with Connected Living Spaces and I could not move a Kerbal into the pods without turning on the option for unrestricted crew transfers. I'd already fixed the Nest to be passable, but the problem seemed to be the hatches. The right click menu shows a Hatch status: Closed, but I have no switch to open it. I think with open hatches on both the Nest and the Pods they should be passable, but a closed hatch anywhere isolates the pod from being able to transfer crews. To be honest I still haven't downloaded the patch file you linked to earlier, maybe this is solved by that, or it could be another mod conflicting.

After that everything worked as expected and I plan to keep using this.

Edited July 29, 2018 by Tonka Crash

[TiktaalikDreaming]

@Tonka Crash
1: This had been mentioned, and it's in my to do list.

2: I really want to do flashing lights but have yet to figure out how

3: no, my patch doesn't yet work, even with some very explicit permits. I'm thinking of trying after adding a crew capacity to the nest. I'm just about out of other ideas

[Tonka Crash]

I've written a patch to add Indicator Lights to the pod to show if the pod is occupied. This adds 4 lights around the base of the KOOSE pod that stick out enough to be visible while docked in the Nest.  You can take and use it however you want, or not, it doesn't matter to me.

// KOOSE escape pod
//
@PART[KooSEpod]:NEEDS[IndicatorLights]:AFTER[KOOSE] 
{
    MODEL
    {
        model = KOOSE/Assets/Pod
    }
    // 4 lights equally spaced around base
    MODEL
    {
        model = IndicatorLights/Meshes/squareLamp
        scale = 1, 0.15, 1.2
        position = 0.57, 0.0, 0.0
        rotation = -32, 90, 0
    }
    MODEL 
    {
        model = IndicatorLights/Meshes/squareLamp
        scale = 1, 0.15, 1.2
        position = -0.57, 0.0, 0.0
        rotation = -32, 270, 0
    }
    MODEL
    {
        model = IndicatorLights/Meshes/squareLamp
        scale = 1, 0.15, 1.2
        position = 0.0, 0.0, 0.57
        rotation = -32, 0, 0
    }
    MODEL 
    {
        model = IndicatorLights/Meshes/squareLamp
        scale = 1, 0.15, 1.2
        position = 0.0, 0.0, -0.57
        rotation = -32, 180, 0
    }

    // Lights are controllable
    MODULE
    {
        name = ModuleControllableEmissive
        target = IndicatorLights/Meshes/squareLamp
        emissiveName = indicator
    }

    // Controlled by Crew Indcator (Pod Occupied or not)
    MODULE
    {
        name = ModuleCrewIndicatorToggle
        toggleName = indicatorToggle
    }

    MODULE
    {
        name = ModuleCrewIndicator
        emissiveName = indicator
        toggleName = indicatorToggle
    }

}

In the screenshot below, the top and the left nested pod are occupied. The nested pod on the right is unoccupied. If you haven't used Indicator Lights before the light color is controlled by the Kerbal's specialization: green for engineer, blue for scientist, and orange for pilot by default. The colors are set in a config file within Indicator Lights

[linuxgurugamer]

1 minute ago, Tonka Crash said:

I've written a patch to add Indicator Lights to the pod to show if the pod is occupied. This adds 4 lights around the base of the KOOSE pod that stick out enough to be visible while docked in the Nest.  You can take and use it however you want, or not, it doesn't matter to me.

// KOOSE escape pod
//
@PART[KooSEpod]:NEEDS[IndicatorLights]:AFTER[KOOSE] 
{
    MODEL
    {
        model = KOOSE/Assets/Pod
    }
    // 4 lights equally spaced around base
    MODEL
    {
        model = IndicatorLights/Meshes/squareLamp
        scale = 1, 0.15, 1.2
        position = 0.57, 0.0, 0.0
        rotation = -32, 90, 0
    }
    MODEL 
    {
        model = IndicatorLights/Meshes/squareLamp
        scale = 1, 0.15, 1.2
        position = -0.57, 0.0, 0.0
        rotation = -32, 270, 0
    }
    MODEL
    {
        model = IndicatorLights/Meshes/squareLamp
        scale = 1, 0.15, 1.2
        position = 0.0, 0.0, 0.57
        rotation = -32, 0, 0
    }
    MODEL 
    {
        model = IndicatorLights/Meshes/squareLamp
        scale = 1, 0.15, 1.2
        position = 0.0, 0.0, -0.57
        rotation = -32, 180, 0
    }

    // Lights are controllable
    MODULE
    {
        name = ModuleControllableEmissive
        target = IndicatorLights/Meshes/squareLamp
        emissiveName = indicator
    }

    // Controlled by Crew Indcator (Pod Occupied or not)
    MODULE
    {
        name = ModuleCrewIndicatorToggle
        toggleName = indicatorToggle
    }

    MODULE
    {
        name = ModuleCrewIndicator
        emissiveName = indicator
        toggleName = indicatorToggle
    }

}

In the screenshot below, the top and the left nested pod are occupied. The nested pod on the right is unoccupied. If you haven't used Indicator Lights before the light color is controlled by the Kerbal's specialization: green for engineer, blue for scientist, and orange for pilot by default. The colors are set in a config file within Indicator Lights

 Do you think you could do the same thing for the REKT mod?

[TiktaalikDreaming]

22 minutes ago, Tonka Crash said:

I've written a patch to add Indicator Lights to the pod to show if the pod is occupied. This adds 4 lights around the base of the KOOSE pod that stick out enough to be visible while docked in the Nest.  You can take and use it however you want, or not, it doesn't matter to me.

// KOOSE escape pod
//
@PART[KooSEpod]:NEEDS[IndicatorLights]:AFTER[KOOSE] 
{
    MODEL
    {
        model = KOOSE/Assets/Pod
    }
    // 4 lights equally spaced around base
    MODEL
    {
        model = IndicatorLights/Meshes/squareLamp
        scale = 1, 0.15, 1.2
        position = 0.57, 0.0, 0.0
        rotation = -32, 90, 0
    }
    MODEL 
    {
        model = IndicatorLights/Meshes/squareLamp
        scale = 1, 0.15, 1.2
        position = -0.57, 0.0, 0.0
        rotation = -32, 270, 0
    }
    MODEL
    {
        model = IndicatorLights/Meshes/squareLamp
        scale = 1, 0.15, 1.2
        position = 0.0, 0.0, 0.57
        rotation = -32, 0, 0
    }
    MODEL 
    {
        model = IndicatorLights/Meshes/squareLamp
        scale = 1, 0.15, 1.2
        position = 0.0, 0.0, -0.57
        rotation = -32, 180, 0
    }

    // Lights are controllable
    MODULE
    {
        name = ModuleControllableEmissive
        target = IndicatorLights/Meshes/squareLamp
        emissiveName = indicator
    }

    // Controlled by Crew Indcator (Pod Occupied or not)
    MODULE
    {
        name = ModuleCrewIndicatorToggle
        toggleName = indicatorToggle
    }

    MODULE
    {
        name = ModuleCrewIndicator
        emissiveName = indicator
        toggleName = indicatorToggle
    }

}

In the screenshot below, the top and the left nested pod are occupied. The nested pod on the right is unoccupied. If you haven't used Indicator Lights before the light color is controlled by the Kerbal's specialization: green for engineer, blue for scientist, and orange for pilot by default. The colors are set in a config file within Indicator Lights

Nice. Thanks, I'll add that to the patch collection.

21 minutes ago, linuxgurugamer said:

 Do you think you could do the same thing for the REKT mod?

I would guess it would be just a case of changing the locations and the part name of course. Just a guess though.

I did look at indicator lights for inspiration, but I typically want to get my basic functions going without dependencies. Obviously too get the lights to signal occupancy or similar things it needs a module though. And there is one written.

I may just bite the bullet and make my lights using the mod as a dependency. I say that not because the patches indicators "aren't good enough" or any fecal matter like that. But I want the lights integrated in the pod structure and I want a landed/splashed down beacon as well.

Nice work Tonka

[Tonka Crash]

35 minutes ago, linuxgurugamer said:

 Do you think you could do the same thing for the REKT mod?

I'd rather not, I don't use REKT, and I had a need for this one. I did this through trial and error constantly reloading the MM database to dial in the geometry. It took much longer than I expected and this was only one part, REKT has a lot more.

[DStaal]

1 hour ago, linuxgurugamer said:

 Do you think you could do the same thing for the REKT mod?

REKT has modeled-in Indicator Lights support, so you shouldn't need a new patch.  (That is: The lights are built-in, not patched on, and there's a patch to enable.)

[linuxgurugamer]

3 hours ago, DStaal said:

REKT has modeled-in Indicator Lights support, so you shouldn't need a new patch.  (That is: The lights are built-in, not patched on, and there's a patch to enable.)

Oh, great.

Thanks