[WIP] Apollo-like crew module (Updated download 17.2.2014)

[Ledenko]

There's nothing stopping you from integrating it with the docking port assembly, though, like BobCat's Orion did.

As a side note, though, there's one interesting problem with that Orion. Two parachute modules don't coexist well on the same part. I.e. you need to manually cut the drogues on BobCat's Orion to make the main parachute apply it's parameters.

The only workaround I could think of so far is to set the auto-cut speed parameter on the drogue chute and minimum pressure parameter on the main chute so that they auto-cut right when the main chutes would deploy. The downside is that it ties the whole assembly to landing on Kerbin and nowhere else.

Yeah, that's how I'll do it, it makes sense. About drogues though - is there a reason besides realism for not making the partially deployed chute actas a drogue in terms of drag?

[Mihara]

About drogues though - is there a reason besides realism for not making the partially deployed chute actas a drogue in terms of drag?

Not really.

[Ledenko]

It works! Sort of...

It flies, the parachute deploys and it lands safely. At least in my tests, but it wasn't in space yet - I'll have to change it first.

As it is, the collider for the parachute intersects with the CM collider, it doesn't seem to create phantom forces but it does mean once it's properly attached it's impossible to remove (can't click it).

So, the docking port/parachute will have to be a completely separate part for it to work properly, the EVA is missing and it could probably use a ladder attachment of some sort. But it does have a flag decal case on the back! And you can see the tiny canopy as it's resting below the part.

Look at it go!

"Works" by way of eh, good enough.

Fully deployed, it kinda looks as it should. Kinda sorta. The canopy and wires are still untextured and the wires themselves look like strips of rubber.

The flag decal thingy.

So yeah, there's still work to be done, but as a baseline, it actually works. Big thanks to everyone who helped me, I ran into issue with the parachute that left me utterly clueless but thanks to you guys, it behaves as it should.

[cnnrduncan]

That looks really cool! Good work!

[Sapphire]

It's so pretty! This is gonna be at the forefont of my futuristic space program.

[Kerbal01]

Mine too!.

[Sapphire]

So, question time!

What kind of parts are gonna come with this thing? So far it looks like...

-command pod

-parachute/docking port attachment

-parachute cover

-escape tower (?)

Is this pod gonna have special functions? Will it have small onboard RCS tanks? Will it have light-up windows like B9 or FASA? Will it carry 3 Kerbals like the standard pod, or two, or four?

And here, take my stars! Really looking forward to this, your pod is beautiful.

[Ledenko]

Wow! Thanks for the kind words!

Sapphire, to answer you:

- three separate parts, command pod, parachute/docking port with with the parachute cover being part of the parachute module, so it'll disappear once the parachute deploys and a LES, but that'll come after the CM and chute/dock

- I'm making it as an alternative to the stock Mk1-2 pod because I don't fancy its asymmetry, meaning three crew members and

- no RCS capability, from what I've seen, the real Apollo CM had RCS only for rotational control, something that can be accomplished with reaction wheels (as long as you don't run out of power, but should be enough for reentry)

- I like the windows lighting up idea, I'll have to look into how that's done, thanks!

I had basically zero time during the weekend, but I hope I can get something done soon

[Ledenko]

Well, after messing around for ages with setting it up, I have something that basically works and could be called early release, alpha, version 0.110 or whatever.

Here it is: https://dl.dropboxusercontent.com/u/27552313/KP0110.zip

Please note! Being mostly untested, I have no idea what it's potential for save game breaking it is. It's not using any mods but since this is my first complex part, it's possible it'll cause some issue I'm not even aware of.

It's still mostly untested, but it seems to work, EVA hatch and "ladders" are functional, docking port seems to work (the thingy on top of it might interfere with a docking cam though, in fact I'm pretty sure it'll do that) and the parachute functions, even though the animation is messed up as I animated the wrong axis. At least it points the right way...

So, currently known bugs and/or issues:

Docking port thingy interferes with docking cam (probably)

The not-fully-deployed animation for the parachute is stretched the wrong way + edit: the texture is a placeholder

There's a texture issue on top of the docking port, weird flickery triangles

edit2: the way the heat shield and attachment node are positioned it only really works with tall/wide decouplers such as the stock 2.5m one, with low decouplers you'd need part clipping. I might move the attachment point lower and make an automatic shroud so it doesn't leave a gap, but the prospect scares me (figuring out Unity is a pain).

Feedback much appreciated!

Edited October 3, 2013 by Ledenko

[Sapphire]

Noooooo! It came out today, while I'm at school away from my main KSP install, and right in the middle of midterm week.

Regardless I was able to fool around with it a bit (as in, simply a quick zip to orbit then back down) at lunch on my laptop.

In terms of bugs, I think you're a bit pessimistic in terms of it destroying your game. I've never seen a part without a plugin break a game, and this one is no exception. Though in my short flight, I noticed two things:

1. The reaction wheels don't seem to use electricity. Can anyone else confirm?

2. The pod itself likes to flip over oddly on splashdown. I'm not sure if that can be fixed, though, it looks like all pods do that weird flipping thing.

I haven't tried docking yet, I'll have to find time to do that tomorrow or at some point during the weekend.

[Mihara]

Pod flips over on splashdown because it's center of mass is in the model zero, and the added weight of docking ports and parachutes tips it over. For best results in that case, you need CoMOffset.

If reaction wheels don't use electricity, the config file definitely isn't to blame, it's written correctly.

[Sapphire]

Pod flips over on splashdown because it's center of mass is in the model zero, and the added weight of docking ports and parachutes tips it over. For best results in that case, you need CoMOffset.

If reaction wheels don't use electricity, the config file definitely isn't to blame, it's written correctly.

I just confirmed it was an error on my end. I tried reinstalling KSP, and now the reaction wheels and electricity drain on the capsule work. I don't get it, my laptop copy of KSP is stock...

[Ledenko]

Ha! And you doubted it's game breaking potential

When I started making this I built from the assumption that object origin should represent the CoM but it just dawned on me that CoM in model origin could create similar issues as with the parachute which, derpy as it is, uses a CoMoffset to not spin crazily. Another thing to fiddle with

[Mihara]

A couple minor complaints if I may while you're fiddling...

• Does it really need 1024x1024 textures? Memory is life in KSP mods, I'm afraid.
  
• Does the docking port part really need those textures of the module itself? If it does, you'd better reference them from the config file, instead of duplicating them -- there's no longer a limit of one part per directory, even, you can crossreference textures and models more or less whichever way you please. If it doesn't, they shouldn't be there, as KSP will load them and keep them uselessly in memory.
  

[Ledenko]

About 1024x1024 - I honestly don't know. I know a thing or two (out of several billion) about modeling and I reduced the poly count as much as possible. When it comes to texturing I'm just awful at it, both in terms of making something that looks nice and is efficient at the same time. But I do want it to look good, at least for myself - my reasoning was "this is the hero module, this is what's gonna be there from the start till the end". I will test it of course, it might very well look just fine at 512x512.

The parachute does use those files because at some point, parts of the parachute model were supposed to be integrated into the CM until that turned out to be a bad idea. I tried putting them into the same folder, didn't know how to properly set it up in the configs so the parachute used the CM model and it was 5am So yeah, I'll put them into one folder to not duplicate textures as soon as I figure out the configs.

To be honest, I was thinking about slightly remodeling and re-UVing the models right before reading your post, it's just that with my limited home computer time, the idea is frightening!

fake edit: thinking about the various detail texture size, it could very easily do with a smaller texture as there's mostly flat colors. There will be fiddling.

[Mihara]

About 1024x1024 - I honestly don't know. I know a thing or two (out of several billion) about modeling and I reduced the poly count as much as possible. When it comes to texturing I'm just awful at it, both in terms of making something that looks nice and is efficient at the same time. But I do want it to look good, at least for myself - my reasoning was "this is the hero module, this is what's gonna be there from the start till the end". I will test it of course, it might very well look just fine at 512x512.

While everywhere you will see advice to reduce poly count, with current KSP, it's actually somewhat unwise to reduce poly count if you plan to make up the lost detail with a normal map -- especially if you don't have that much detail. The reason is that you rarely, if ever, have enough polys on screen to stress a modern GPU in KSP -- the only exception would be with an ocean planet on screen, and even then I'm not sure if it's actually GPU being stressed or CPU choking on regenerating all the procedural terrain polygons -- but number of parts is a chokepoint because it directly affects physics processing time, which is limited by the use of only one core, and size and quantity of textures directly affects whether KSP crashes due to out of memory or not, because it's a 32-bit application that, for some bizarre reason, wants to keep all the textures in memory at all times. Eventually, both of those problems will be optimized away, but that "eventually", by the looks of it, won't happen earlier than in a year, and even then I wouldn't bet on it. A high-poly model takes away from the resources you have extra of (GPU processing time) but a multi-texture normal mapped model takes away from resources that are strictly limited (RAM).

[Ledenko]

I realize as much much, but honestly didn't consider it a lot for a two, eventually three part addon. What started this holy crusade against textures anyhow? It started about a week ago or so, didn't it?

[Mihara]

I realize as much much, but honestly didn't consider it a lot for a two, eventually three part addon.

Which is perfectly reasonable until you realize you want -- and use -- hundreds of those little addons, which is the position I'm in.

What started this holy crusade against textures anyhow? It started about a week ago or so, didn't it?

Probably the fact that Krupski released an MBM to PNG converter which allowed a lot more people to actually look at the textures and despair. Me, I've been advocating everything-reuse since 0.20 and MODEL nodes.

[Ledenko]

I completely missed that app! And it would have been so useful some time ago when I was trying to make a stockalike module. Still managed to somehow create a pretty good replica of stock textures

Heh, I use a fair number of addons, but they're mostly plugins to add functionality, rather than adding parts. I have a few larger mods for that, but I tend to not even use them much.

[Sapphire]

This actually goes really well with Sumghai's Orion service module.

[Moon Goddess]

That is a beautiful shot,

Let me say though, I don't wanna go for your space program, as big as that pod is it's pretty cramped to go all the way to Duna and back in.

[Ledenko]

Wow, that really is a nice shot.

Moon, the pod's so cramped, I'm not sure the poor kerbals can fit their helmets through the hatch

[Sapphire]

That is a beautiful shot,

Let me say though, I don't wanna go for your space program, as big as that pod is it's pretty cramped to go all the way to Duna and back in.

If it's any consolation, The big transfer stage (with comfy living quarters) is on the other side of the planet.

[Moon Goddess]

So that means one of 2 possiblities...

Either A) it's a long cramped ride home...

You're space program is willing to waste a lot of Delta-V for a photo-Op and you'll be redocking to the habitat.

Or I guess C) You didn't tell them they aren't coming home.

I'm most inclined to believe coz god have I wasted Time, Money, Delta-V for a perfect photo.

[Sapphire]

You're space program is willing to waste a lot of Delta-V for a photo-Op and you'll be redocking to the habitat.

That's the one. The KSP install on my laptop (the one I'm on now) isn't my main install. My main stuff is running on my main space program on my desktop at home, so I just do things like part testing on this laptop.