[1.5] KOOSE mini reentry pod aka escape pod

[TiktaalikDreaming]

Nope, not layers.

The parachute deployed canopy is ignored in the VAB calculation based on the mesh name.  I've usually stuck to having my own system for naming parts, esp when components are called out in the config.  But this has burnt me before, and it seems it's burnt me again.  The parachute canopy name shall be canopy, or twill not be ignored.  Fixed in 1.1.6, which contains this fix, and nothing else.  All my other musing are already there or still in my head.

I have a sudden urge for spaghetti. 

[Tonka Crash]

@TiktaalikDreaming Is there a reason that you used multiple capitalization schemes in your part names?

Most other mods seem to use the same scheme across all their part names so wildcards are easier to use in patches affect all parts. You have:  KOOSEparachute,  KooSEpod,  KooseHShield,  KooSECradle so patches have to address each part by name instead of just using a wildcard like KOOSE*. It's probably too late to change it as this would break games using the parts unless the player hand edited his save file to change the part names before loading.

Edited August 29, 2018 by Tonka Crash

[Dave-Daring]

Brilliant, this shall now be a part of all my Kerbin orbit space stations, though some of them I put at 500KM so a small service module will be needed for those making history has something that will do for that.

 

Edited August 29, 2018 by Dave-Daring

[TiktaalikDreaming]

6 hours ago, Tonka Crash said:

@TiktaalikDreaming Is there a reason that you used multiple capitalization schemes in your part names?

Most other mods seem to use the same scheme across all their part names so wildcards are easier to use in patches affect all parts. You have:  KOOSEparachute,  KooSEpod,  KooseHShield,  KooSECradle so patches have to address each part by name instead of just using a wildcard like KOOSE*. It's probably too late to change it as this would break games using the parts unless the player hand edited his save file to change the part names before loading.

That's because I'm inconsistent and couldn't really think of an easy way to fix it up after. But, I can now think of a fix thanks to squad's feature to hide parts that they introduced to obsolete the old parts when adding new ones like the mk1-3 pod.

Thanks for the reminder

[Tonka Crash]

@TiktaalikDreaming Got a new bug. I can't remember the last time I used a Koose Pod, it's probably been well over a month since I needed to deploy one. I haven't been seeing rescue contracts lately in Kerbin orbit where I have a Nest .

I tried today and the parachute when it deploys is miniscule and doesn't slow the descent. I found I was out of date, but after updating against github the problem remained. You can barely make out the red and white canopy in the chute part. This is the current github. I had previously updated on 8/22 if that helps pin down when the problem started.

I can generate some logs if you can't reproduce it. I stuck a pod on a Flea with a decoupler between them for testing. Jeb was not amused.

I did find I could fit Mk1 and Mk2 capsules in the pod bays if you offset the parachutes so they are almost flush. My Minmus station now has a set of heavy rescue capsules for returns to Kerbin.

Edited September 30, 2018 by Tonka Crash

[TiktaalikDreaming]

Dammit.  I probably stuffed something exporting parts.  I'll take a look.

Re: fitting other pods.  The KOOSE is almost the same width at the base as the Mk1 pod, but is shorter, so the other pods will generally be narrower where they intersect the nest.  So, it should all be OK to fit the Mk1 in there.  Assuming you sort the chutes and docking nodes so they're not in the way.

[MaverickSawyer]

17 hours ago, Tonka Crash said:

I did find I could fit Mk1 and Mk2 capsules in the pod bays if you offset the parachutes so they are almost flush. My Minmus station now has a set of heavy rescue capsules for returns to Kerbin.

Okay, that's freaking GLORIOUS.  

[TiktaalikDreaming]

21 hours ago, Tonka Crash said:

@TiktaalikDreaming Got a new bug. I can't remember the last time I used a Koose Pod, it's probably been well over a month since I needed to deploy one. I haven't been seeing rescue contracts lately in Kerbin orbit where I have a Nest .

I tried today and the parachute when it deploys is miniscule and doesn't slow the descent. I found I was out of date, but after updating against github the problem remained. You can barely make out the red and white canopy in the chute part. This is the current github. I had previously updated on 8/22 if that helps pin down when the problem started.

I can generate some logs if you can't reproduce it. I stuck a pod on a Flea with a decoupler between them for testing. Jeb was not amused.

I did find I could fit Mk1 and Mk2 capsules in the pod bays if you offset the parachutes so they are almost flush. My Minmus station now has a set of heavy rescue capsules for returns to Kerbin.

I think this might have been due to breaking the animation links when renaming the canopy. So after killing another kerbal because I forgot to reload the database I've found it didn't update drag cubes, and a third kerbal plummeted to their (actually reverting to hanger) figurative death.

[TiktaalikDreaming]

12 minutes ago, TiktaalikDreaming said:

I think this might have been due to breaking the animation links when renaming the canopy. So after killing another kerbal because I forgot to reload the database I've found it didn't update drag cubes, and a third kerbal plummeted to their (actually reverting to hanger) figurative death.

And fixed up.

Billy-Bobfred's fifth nearly identical fight resulted in a gentle landing and no death.  For which Billy-Bobfred was understandably happy with.

 

[Tonka Crash]

@TiktaalikDreaming I found a config file error in the KOOSECradle.cfg. The node names for the node definitions must be the same name in the explosiveNodeID for the ModuleDecouple.  Without this in agreement the nodes do not decouple. This applies to all 6 nodes for the pods. It doesn't matter what the names are (KOOSE1 thru KOOSE6) or (pod1 through pod6) as long as they agree in both the Node definition and the ModuleDecouple definition. This also affects the CLS.cfg as the node names are used there as well. The simplest fix is to change the NODE definition names to pod1 thru pod6 and it should agree in the other config files.

	NODE
	{
		name = KOOSE1	// <-- The name for the node here 
		transform = dockingNode1
		size = 0
		method = FIXED_JOINT
	}	
             
	.
	.   
	.

	MODULE
	{
		name = ModuleDecouple
		ejectionForce = 75
		explosiveNodeID = pod1 //<-- must agree with the name for the node here
		menuName = Detach Pod 1
	}

 

Edited October 3, 2018 by Tonka Crash

[TiktaalikDreaming]

7 hours ago, Tonka Crash said:

@TiktaalikDreaming I found a config file error in the KOOSECradle.cfg. The node names for the node definitions must be the same name in the explosiveNodeID for the ModuleDecouple.  Without this in agreement the nodes do not decouple. This applies to all 6 nodes for the pods. It doesn't matter what the names are (KOOSE1 thru KOOSE6) or (pod1 through pod6) as long as they agree in both the Node definition and the ModuleDecouple definition. This also affects the CLS.cfg as the node names are used there as well. The simplest fix is to change the NODE definition names to pod1 thru pod6 and it should agree in the other config files.

	NODE
	{
		name = KOOSE1	// <-- The name for the node here 
		transform = dockingNode1
		size = 0
		method = FIXED_JOINT
	}	
             
	.
	.   
	.

	MODULE
	{
		name = ModuleDecouple
		ejectionForce = 75
		explosiveNodeID = pod1 //<-- must agree with the name for the node here
		menuName = Detach Pod 1
	}

 

You're dead right.  That snuck in from editing multiple versions on several computers.

I found a fixed up, working version on my PC at work, and was going to push that out until I noticed it was old in several other ways.  Synced to current and fixed properly and pushed back up now.

I've edited to have the names match "KOOSE#" as those are the attach node points, and changing those names will break existing (likely non-functioning) craft using the nest.

So far, it's not even a git package.  But the git files have the fix.

[Tonka Crash]

6 hours ago, TiktaalikDreaming said:

I've edited to have the names match "KOOSE#" as those are the attach node points, and changing those names will break existing (likely non-functioning) craft using the nest.

I'm not sure how much it's required by the the CLS patch (patches\KooSE_CLS.cfg ) explicitly identifies the passable nodes by name, so it needs to be in agreement with the KOOSECradle.cfg node names.  It doesn't look like it currently is. 

Edited October 4, 2018 by Tonka Crash

[TiktaalikDreaming]

6 hours ago, Tonka Crash said:

I'm not sure how much it's required by the the CLS patch (patches\KooSE_CLS.cfg ) explicitly identifies the passable nodes by name, so it needs to be in agreement with the KOOSECradle.cfg node names.  It doesn't look like it currently is. 

Thanks. Your doing pretty good at correcting my distracted scatter brain effects. I knew there was a reason for not re-releasing yesterday, just didn't know what it was.   Thanks heaps for your help.

[Tonka Crash]

Not a problem. 

[TiktaalikDreaming]

So, it looks like using decoupling nodes doesn't work too well.  Or it works for the first KOOSE off the nest, and then not for any others.

I'm going to mess around with some options and make sure to keep all my nodes named right, and check if I've broken CLS on the way.

But, as is, it's non-functional.   At least when I was testing

[TiktaalikDreaming]

OK, well, moving the decoupler node from the nest to the pod itself seems to have fixed all the issues I was having.

So, new version on Git, the Nest just has stack nodes.  I'll check if I can make those docking nodes to better serve other purposes later.

And the KOOSE pod has a decoupling node at the top.  All individually separable.  Note that decouplers use staging or right-click menu.  If you stage you will also trigger the solid retros, as it's the same part.  This could be entirely acceptable.  Or less so.

CLS patch also works fine in this set up, which is nice.

I may make the pod look a bit more like a decoupler at the top and less like a docking node. 

 

[Tonka Crash]

I haven't had time to look at your changes since Wednesday. I would look in your ModuleManager.ConfigCache to make sure the KOOSE configs are being interpreted like you expect.

I know my local version doesn't match any release you've posted and I currently have everything working like I expect with CLS. I fired off 4 pods this afternoon. Whenever you've done an update I download it, figure out what's broken, report it and fix my local configs to get back to functional. I'd update github directly but I have never done anything but download from there and am concerned I'd break something.

Removing the decoupler from the nest will break the "heavy" pod configuration I posted above using Mk2 capsules as nothing but the KOOSE pods would have a built in decoupler in the nose. 

Staging the decoupler and the motor at the same time is a bad idea. You don't have a chance to orient the pod for reentry.

[Tonka Crash]

The reason your nest won't fire more than one pod is that you have the explosiveNodeID's all referring to pod 1

Below is a partial screen grab comparing your config and mine. Left side is your config downloaded from github this morning, mine is right side. You've got some extra parentheses and all your decouplers reference Pod1.  Also not shown, it looks like you changed a bunch of lines in the old legacy nest configuration. That's irrelevant to me as I renamed any old parts in my persistence.sfs but is probably a no-no for existing installs using old parts unless you've tested it. The form of mine hasn't changed substantially in a couple months. I think the only change was changed node references from pod# to KOOSE#.

You can ignore the crossfeed lines. I've been turning off features I don't use in the KOOSE parts to declutter the right click menus.

My complete KOOSE install https://drive.google.com/open?id=1fbNxjTAx5h-8PS9UxOLo7b9G9M3lCH8j Compare what I have against your's to see what's off. I use Beyond Compare as a comparison tool from https://www.scootersoftware.com/  I've been using it for close to 20 years. It's one of the first things I install on any PC.

I took the following video using the configs as I have on the right this morning, running the configs I linked to above.

 

 

[TiktaalikDreaming]

The extra parentheses are just too nice that config out of the part without deleting it, in case I eat too add it back. And the chamfer to the legacy part was so I could test more than one config at a time.

And the decoupler nodes all being the same is pure stupid on my part and explains all the problems I had. Derp.

 

[TiktaalikDreaming]

Also taking the time to split off some of the panels that are replicated in UV space to independent areas so I can finally add pod numbering.  Still haven't decided on a style for said numbering tho.

[TiktaalikDreaming]

And, finally, high-tech fancy solutions stand back, we have numbering.

I'm going to just leave the update as is for now and package it after some more testing, and to be honest, time for Tonka to tell me what I stuffed up. 

[Tonka Crash]

I ran my checks and it passes.  All the configs seem good for new built parts. All pods eject and the parachute works. I'm happy!!!  I didn't test deprecated parts. I don't think I'd be as nice keeping the old configs around.

I did find a new glitch I hadn't seen before, but I couldn't care less about this one because I probably won't  be something I'll encounter in use.

I built up a rocket to test the parachute, but stuck the KOOSE heat shield on the capsule with a decoupler underneath. I like the custom shroud you have for this, but I think this is the only time I've ever launched this configuration. I normally haven't bothered with the heat shield for a parachute test.

In the VAB the shroud was there. I took it to the launch pad and the shroud disappears, so it looks like the capsule is hovering over the decoupler. I have no idea what could cause this.

[TiktaalikDreaming]

Yeah, this issue?

I have no idea what causes that.  It doesn't seem to effect anything.

I asked around some other modders a while ago and got no-where, but I'll see if I can find out.

I do almost have a new part, which is of extra use seeing the KOOSE pod is heading away from having its' own decoupler/docking node.

Intending to be a surface attachable decoupler "mini" nest.  The core shares mesh and texture space from the main nest's decoupler ports.  I'd make it a shrouded mini nest but I don't think I have the texture space without adding more files.

[Tonka Crash]

I can see the new part as a useful surface mount decoupler to deploy probes or other small craft.

[RealKerbal3x]

I was just about to build an escape system for my LKO space station when I remembered your mod, @TiktaalikDreaming! Downloaded.

One problem I have is that I can’t get the KOOSEs to de-nest. I’ve tried the staging sequence, action groups and the right click action menu of both the pods and the nest, but the pods still stay stubbornly stuck to the nest. Am I missing a dependency or just being dense?