Deltac

This has already been discussed in length, but your noticing has been noted.

Those aren't upper stages, one is the Super 25, and the other 2 are cargo. Here's an example of an upperstage. An upper stage is basically a rocket built to be used in the upper atmo/in space, which means it needs something below it to get it that high, therefore "upper" stage.

Here's what I'm going to add into this: If I don't like a mod, or don't feel like using it, I won't post in the associated thread.

Looks like he's making the LOK. If you look at the top of the screen cap, it says lok_v01.max. Sorry buddy, I guess you're not getting your Zond :/ Additional Information: @Denny He's talking about this http://en.wikipedia.org/wiki/Soyuz_7K-L1

Bug Report/ Hot fix: If you have FASA and OLDD installed, and you are using the OLDD LEM instead of the FASA LEM, the props in the ascent stage may be buggy. Image of proof. In order to fix this, delete the prop folder in FASA. That folder just holds the props for the LEM ascent stage for FASA, not anything else (currently). As to why this is causing this bug, no idea.

The License. In short, I'm pretty sure you can release those modified textures so long as you give Denny credit. I'm pretty sure people are going to want to try your texture edits out. I'm also pretty sure my name is not Shirley.

Here is a .craft file for the Apollo and Saturn V. It does not include LEM since that is "simpler" to build. Does not include struts, so good luck!

Then I guess you ignored all of those images showing the full Saturn V

I'm glad to see the Denny's/Frizz alliance is still going on strong. Now for a waffle burger!

no... no no... you aren't... OH GOD SECOND LIFE IS STILL HAUNTING ME! I recognize your Amok Dynamics logo from Second Life. Glad to see another excellent modeler and programmer on the forums!

Your statement makes it sound like Zenit is a fake rocket. It isn't. As far as I'm concerned, his Zenit is based off the real Zenit, just Kerbalized of course. As for Frizz's imagination, he'd probably want to completely overhaul KSP! Frizzank Space Program! or perhaps not.

Alright, Denny, it appears that if we want the Parachutes to be RealChute compatible, we'll need to separate the floats from the chutes. One idea is to separate the floats' animation from the chute animation, forcing users to create an action group for deploying the floats while the parachutes work as normal. I'm hoping there's someone here who can tell us how this could be done as I've never seen parachutes with another animated module. The other method would be just to remove the floats from the chutes, and make the floats a separate animated part to attach to the Apollo CM. Of course the third option would be to leave everything as is for the rest of eternity, but I'm not sure how popular that decision would be. I'm posting this assuming you want suggestions. I'm sorry if I crossed a line with suggestions.

So any ideas for the Apollo Parachute from OLDD, or are we just going to have to pressure Denny some more?

I didn't even look up the info for my orbits. In the beginning, I used 100km orbits, but decided to bring that down to 50km. The LEM Ascent stage has plenty of fuel to get to 10km, then rendezvous with the CSM back at 50km.

For RealChute, there wouldn't really be anything you'd need to do, but because your Apollo Parachutes also have the floats, RealChute is having trouble dealing with it so far. Here's the post I made about it on RealChute. Still waiting on Stupid-Chris for any further advice. As far as I can tell, we might need the floats to be a separate part, but I'm not an expert on RealChute.

No red lines of doom. Here's a link to the output log just in case.

Not sure if sharing configs is allowed, but since you're a moderator, here you go: PART { // --- general parameters --- name = Apollo_CM_parachutes module = Part author = DennyTX // --- asset parameters --- rescaleFactor = 1 MODEL { model = OLDD/ApolloCSM/Apollo_CM_parachutes scale = 0.64, 0.64, 0.64 rotation = 0, 0, 0 } // --- node definitions --- // definition format is Position X, Position Y, Position Z, Up X, Up Y, Up Z, size node_stack_top = 0.0, 0.763, 0.0, 0.0, 1.0, 0.0, 1 node_stack_bottom = 0.0, 0.763, 0.0, 0.0, 1.0, 0.0, 1 // --- FX definitions --- sound_parachute_open = activate // --- editor parameters --- TechRequired = specializedControl entryCost = 5000 cost = 5000 category = Pods subcategory = 0 title = Apollo CM triple parachutes description = Apollo CM triple parachutes // attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision attachRules = 1,0,1,0,0 // --- standard part parameters --- mass = 0.555 dragModelType = default angularDrag = 3 crashTolerance = 12 maxTemp = 1000 breakingForce = 100 breakingTorque = 50 stageOffset = -1 // ----- DO NOT EDIT BELOW THIS POINT ------ MODULE { name = ModuleParachute invertCanopy = true autoCutSpeed = 0.5 capName = ParachutePacks canopyName = DeploySemi semiDeployedAnimation = ParachutesSemi fullyDeployedAnimation = ParachutesFully stowedDrag = 0.22 semiDeployedDrag = 1 fullyDeployedDrag = 500 minAirPressureToOpen = 0.01 deployAltitude = 500 deploymentSpeed = 1 semiDeploymentSpeed = 1 } }

I'm trying to change the config for the Apollo Parachutes for the OLDD Apollo, but I've ran into a problem: Those "balloons" are a part of the parachute model (there's only one model call in the main config for the chutes), and are supposed to show up after the chute is deployed, but the problem I'm having is before pre-deployment, the balloons are visible at launch and in the VAB. When you deploy the chute, however, the balloons disappear until after the chute has been fully opened, which is the normal operation. Simplified: The balloons are visible when they shouldn't be. The balloons are a part of the Apollo Parachute model, and activate with the chutes' animation call, not via a separate animation call. Module Manager Config: @PART[Apollo_CM_parachutes] { maximum_drag = 0.32 !MODULE[ModuleParachute]{} MODULE { name = RealChuteModule material = Kevlar caseMass = 0.2 preDeployedDiameter = 2.5 deployedDiameter = 50 minIsPressure = false minDeployment = 2500 deploymentAlt = 550 cutAlt = -1 timer = 0 mustGoDown = false preDeploymentSpeed = 1 deploymentSpeed = 5 cutSpeed = 0.5 preDeploymentAnimation = ParachutesSemi deploymentAnimation = ParachutesFully parachuteName = DeploySemi capName = ParachutePacks spareChutes = 5 } MODULE { name = ProceduralChute modelDiameter = 6 } EFFECTS { rcpredeploy { AUDIO { channel = Ship clip = sound_parachute_open volume = 1 } } rcdeploy { AUDIO { channel = Ship clip = sound_parachute_single volume = 1 } } rccut { AUDIO { channel = Ship clip = RealChute/Sounds/sound_parachute_cut volume = 1 } } rcrepack { AUDIO { channel = Ship clip = RealChute/Sounds/sound_parachute_repack volume = 1 } } } }

I get the blue-stick issue too sometimes. As far as I can tell, there's no specific condition that causes it to occur. It'll just occur whenever it likes to. Sorry for not reporting it earlier, but there was an Apollo mission to worry about

The red let's Jeb know where to NOT stand, climb on, or eat lunch with.

Did I miss something?

Evidence of collider issues: And extreme re-entry just because I can: More about collider issue: When I launch just the Crew Capsule, it doesn't go through the grate. It seems as though the parts are losing their collision meshes somehow. I think we need Friz for this.

Are you talking about the LEM Ascent Engine? I tested this pack out on a clean install, and the normal map for the ascent engine is messed up. Image 1 Image 2 I'm wondering if other parts are being affected by this as well.

And what's 140 tonnes multiplied our friend, .64? 89.6 tonnes. Things get smaller in KSP. Except for the heads, they keep getting bigger.

That's what's missing, a bakery! I mean baked shadows. Can we have cookies?