Search the Community

We have the runway and the launchpad, but what about a third place to launch your crafts? This could sprout a whole new set of parts, crafts, and vessel types, and open even more possibilities. Maybe a dock for all your sea operations? Or the helipad on the VAB as a separate place for all your VTOL crafts? Maybe even a garage to test your rovers and cars! What do you think it should be, and do you support the idea of a third one?

So, my Problem is that Ksp will start and will begin to load the files needed for the game After 3/4 or so, the game will close and i get a notification i think that has something to Do with the mods because i tried to download the manually After ckan could Not finden the right gamefolder. So I got all mods out of the gamedata Folder and now i get a Black Screen whenever i launch the game dont know what happend and needed help

So as not to pollute the SpaceX thread with non SpaceX discussion, let us do so here. What would it take, in terms of engineering, to assure all weather launch capability? @sevenperforce @DerekL1963 Feel free to tag any other of the usual suspects in here.

they worked a lot on the general public internet isro portal the past few month ^^ mooaaar launch video moooaaaarrr ^^ http://www.isro.gov.in/gslv-f09-gsat-9/gslv-f09-gsat-9-lift-and-onboard-camera-video on a side note what i wonder since a while is what are all thoose falling stuff just after launch(s)

Fixed by deleting all files in the ckan folder

I am wondering if there is a mod like this already, or if it is even possible. After thinking on the subject a bit, I came to the conclusion that my ideal base construction mod would NOT be something based on any sort of parts themselves. Instead, it would be something that lets you build actual buildings (i.e. the same kind of object that the actual space center's buildings themselves are). Once a building is constructed, it could either be upgraded with funds (if on Kerbin/a populated world), or with some sort of "Parts" or "Supplies" resource (if on NOT-Kerbin/an unpopulated world). At its core, it could simply be a mod that lets you build the Kerbal Space Center the way YOU want it to be layed out. You would start out with a single building that lets you purchase/place another building, in a vaguely sim-city style, where you want said building (in a career mode, the first one you'd get would probably place would be the rocket launchpad, and some of the administrative buildings, which for purposes of balance would all cost 0 for the level 1 version). The starting building itself could be upgraded to increase the number of different buildings you can build. A necessary aspect of the mod would be the launch button in the vehicle designer bringing up a short list of all nearby launchpads and runways (in case you decide to build more than one, such as having two runways facing different directions). Another necessary aspect would be the ability to switch between different space centers, and a part that allows you to build the lowest level version of the building you build all other buildings from (in a sense, using the part places a new space center at that location). So you could build another KSC on the north pole if you wanted or something. Lastly, there would need to be a tag or value for a planet that basically tells the mod whether or not it is a populated planet, so that you can't just construct bases on other planets that work the same way that the KSC does. Either way, once you had this, the next step would be to apply it to other planets. On other worlds, instead of currency, there would presumably be some combination cost of ore (easy to get there), parts/supplies (have to bring with you until you have a building capable of manufacturing it from ore and energy), and in some cases construction time based on energy and how many kerbals are there to work on it. In the event a building is destroyed, it would leave rubble behind that you can select and repair for the appropriate resources, just like the default buildings. If the mod were to just keep itself light, it could be that you can only build structures for things like hangars (buildings that store/unload a nearby vessel until you want it to be spawned again either outside the hangar, or at the base's launchpad), habitation (basically, like the training center except you cannot recruit new astronauts there, only store the ones you have so you can put them into any ships you take out of hangars). If you wanted to go further, you can also have VABs and/or SPHs, which could only use parts that you actually have there, or which can only work if you have some sort of factory building to produce the parts there (the level of which could effectively correspond to what research level of parts can be used there). I could go on listing various things that could be cool, but I've already rambled enough. Are there any mods that let you build actual BUILDINGS? Not just building-like parts, but true, proper buildings? .

I recently reinstalled KSP after a long period of not playing it. It worked perfectly fine for two days with no bugs, then yesterday it wouldn't load past "Loading Asset Bundle Definitions" upon launching. I have uninstalled and reinstalled the game from several versions and it always has the same problem. I am at my wits end for how to fix this issue, please someone help me? Computer: Razer Blade Stealth Software: Windows 10 Home, Version 1607 Processor: Intel(R) Core(TM) i7-6500U CPU @ 2.50 GHz RAM: 8 GB System Type: 64-bit operating system, x64-based processor

I have not been playing KSP a lot the last few years after I quit building space planes. Was a bit hard to find something fun to do motivating me to play but eventually I decided to use KOS and do some scripting. I cant code or script realy so that was interesting After doing some scripts that could take a specific rocket up in orbit or a spaceplane up and land I decided I needed something "Universal". Even with a handful of scripts and rockets when I played career with limited parts one have to invent rockets as the parts are unlocked so realy my new shiny rockets and there scripts where useless until the "end game". So I needed something that worked with most rockets. That is when I started to work on my "Universal Rocket Launch System" or URLS as I like to call it. Its written for KSP 1.2.2 and KOS, I suppose never versions "should work"? You can download the script here. https://dl.dropboxusercontent.com/u/27196441/urls.zip The goal with the scrip is to put ANY payload in a 100-103km Low Kerbal Orbit. Now Im no programmer or scripted, And Im definitely not good at maths so my "formulas" might be a bit strange but they get the job done at least tough there not always as precise as I would like them to be. The script consist of a number of guidance modes. But basically the rockets pitch is calculated and set based on its altitude using a formula I created. The rockets velocity is calculated based of altitude to using a formula I derived and the engines are throttled accordingly to maintain proper acceleration trough the gravity turn. I actually derived my gravity turn formula used for the pitch with a rocket I called the Delta I. It could naturally do a gravity turn so I recorded that data, created a simple script that mimicked that and also tuned the thrust of the stages accordingly. Once I had this simple script I had enough data to create the gravity turn formula I mentioned earlier and the formula for the target velocity and all other formulas I needed. Now the problem is that not every rocket behaves like the one I used as a benchmark, the Delta I. The most common problem I noticed was either a to powerful first stage and a weak second stage and this created a problem. If the second stage is to weak aka low TWR it will not gain altitude fast enough, basically it will fall short of the intended profile of the gravity turn. Since the velocity is calculated based on altitude a second or 3:e stage could actually find it self costing at a pitch up attitude and just run out of fuel since the script did not demand full thrust because the orbital speed at that altitude was meet. As fare as the script was concerned the orbital velocity at that altitude was correct and sure it was but since vertical velocity was around zero the stage would just cost until the fuel ran out. So my next guidance mode I had to create is also based of altitude BUT the formula I derived calculates what time the rocket should be at that altitude. If we assume the rocket turns as programmed by she script and accelerates properly we should always know at what time our rocket should be at a specific altitude. So this secondary guidance mode basically calculates the time the rocket should be at Altitude X and it checks that against the time since launch and if we are ahead or behind to much this guidance mode takes control over the throttle. This mode wont allow the velocity of the rocket to go below 90% of the velocity that was the target, simple reason is that we dont want the rocket to fall out of the sky but other then that it can override the velocity as much as desired to "catch up". This secondary guidance mode will allow even a second or 3:e stage to coast in to orbit. Usually when the second or 3:e stage struggles to get in to orbit its usually enough just to move fuel from that stage to the previous stage, that gives more D/V on previous stage and a lighter second or 3:e stage giving them better TWR. The last guidance mode is basically there to put the rocket in LKO and this mode is activated either when the AP is deemed high enough or the rocket is high enough in orbit. To be able to understand what the script is doing I created a User Interface. It will show useful data the script uses and what guidance modes are in use and what part of the script has completed. This is very useful when designing a rocket to fly with the script. One can pretty easily determine if a stage has the proper TWR or not for example or adjust thrust limits on solid rocket boosters for example since the script has no control over those. I will now explain what the screen shows from top to bottom Apoapsis altitude - this is just apopasis altitude in meters so pretty strait forward Periapsis altitude - this is your periapsis altitude in meters. Vertical speed - this is your rockets vertical speed in m/s so useful to tune thruster limits and engine configurations. Vertical speed target - this is the vertical speed in m/s your rock should travel at the first 1000m after launch. Orbital Velocity - this is the orbital velocity in m/s of your rocket and its used for simplicity from launch to LKO. Velocity deviation - this shows the difference between the calculated velocity and the actual velocity in m/s the rocket is travelling at. Positive number and the rocket is going to fast and a negative number and the rocket is going to slow. Time in flight - this is the time the rocket has been flying since launch shown in seconds only. Deviation from ideal trajectory - this will show you how much behind or ahead in time in seconds the rocket is on its trajectory, ideally you want no deviation but some will eventually occur as the rockets vertical speed declines the accuracy is reduced. Target pitch - this shows the pitch the rocket is suppose to have not what it is, apparently it was very "hard" to script something that would show the rockets actual pitch so you should check this pitch value against the navball to make sure your rocket actually has the authority to pitch over as demanded. Then we have guidance modes. Only one guidance mode can have full authority at a time and what mode has authority will be shown with the word "Active" next to it. Vertical Velocity - This guidance mode is used the first 1000m of the accent, the rocket tries to go strait up and accelerate at a predetermined rate. Orbital Velocity - This is the primary guidance mode for the gravity turn and the one you want to spend most of the time in. It controls the velocity of the rocket according to altitude and should work for any rocket with good enough TWR. Time deviation - this is the secondary or fallback guidance mode. Its primary job is to take control from "Orbital Velocity" guidance mode if the rocket for example has an excessive TWR, like solid rocket boosters that was not properly configured with a thrust limit. Its more commonly activated when a second or 3:e stage has a to low TWR and it will make sure full throttle is used to try and coast the rocket in to orbit. I have also had instances where boosters smashed one of my main engines of and then this mode could save the rocket to. You dont realy want to be in this mode because then your rocket is not balanced to work well with the script but since this guidance mode is based on altitude it will be less accurate at say 50km or higher since the vertical speed decreases and the rockets starts to level of so even the best rockets might spend 10-20 sec in this mode before going in to the last guidance mode. This mode is also triggered if the rocket is 5 seconds behind or ahead of its intended point in time. Orbital Manoeuvrers - this is the last guidance mode and its basically there to get your in to LKO. It is activated either when the rocket has high enough altitude or when the AP is high enough. We dont want the AP to go higher then the intended LKO do we. The last part in our User Interface is Mission parameters. The word complete will be shown next to a mission parameter when it has been executed. Gravity turn - gravity turn is completed. LKO - rocket is in a stable Low Kerbal Orbit. Payload delivery - payload has be deployed. Deorbit burn - the orbital stage has done a retro burn and will now reenter Kerbin at 30km altitude and burn up. Now there area few other things that needs to be mentioned about the script. If an attribute in the User Interface reads "null" the that only means the data is no longer correct or available and therefore no data is shown to confuse the user. The script will check for engine flameouts and will stage as long as there are flamed out engines. The script will also check for active engines and stage until active engines are detected. Every time the rocket stage it will default to full thrust on the engines just to make sure it wont fall behind on its intended trajectory since the TWR will usually be lower with a new stage then an empty one. The scrip uses action group 10 to jettison faring or anything else you want to get rid of, this will happen at 54000m. If you want to jettison your faring earlier you can have that in your staging sequence as usual. The reason I opted for 54000m to jettison fairings is the the fact that I got destructive wobble with 3.75m parts up to about 50000m. Since the script is universal I need a safe altitude to deploy the fairings. The script will stage one last time in orbit to jettison then payload, but action group 9 is also triggered and can be used to separate a payload from the last stage and also extend antennas if you need an uplink to control the payload. Also the scripts formula to estimate velocity is a bit off in the early part of the gravity turn compared to the rocket it was designed for (Delta I) so its pretty common for it to report that the rocket is a bit behind in velocity but still show that the rocket is on time aka no Time Deviation. Try out the Delta II rocket supplied with the script for a good benchmark rocket to use as a reference. For the first stage I usually use a TWR of 1.5 based of the Vacuum numbers, if I use the atmospheric numbers I tend to go with 1.3. The scrip is primarily intended to make launches easy and routine and not to make them the most efficient to save that little bit of fuel. You should tune your rocket so it spends most time in the "orbital velocity" guidance mode for best performance but the script is intended to fly pretty much anything that can be flown manually tough its not designed for space shuttles. I have tested pretty much all my rockets, good and bad once and also most stock rockets in KSP and they do work (staging order might need tuning tough). You can download the script here. https://dl.dropboxusercontent.com/u/27196441/urls.zip It will include the Delta II rocket (improved version of the Delta I but performance the same) and also a Soyuz ST (picture below) that I designed using the script. I would recommend flying them first to get an idea of how the script works and how you can use it to tune your rockets. So now its up to you to break my script and tell me what it cant do So feel free to post any good or bad launches in this thread.

The CYGNSS satellite constellation is launching on an air-launched Pegasus rocket. Watch it here! https://www.nasa.gov/multimedia/nasatv/#public UPDATE 15 Dec 2016: Launch successful!

Hello everyone! This is a thread for you to submit your own spacecraft for me to launch in my 1.2 game, where I'm doing commercial launches now. I'll feature them here on the thread so you can see them in action. Some basic rules: 1. Must be unmanned 2. Tell me the weight 3. Tell me what it's purpose is (Relay network, communications, scientific, etc.) 4. Tell me where to put it (Like in a 100x100 km Kerbin orbit or something like that) 5. Tell me what it's supposed to do 6. Tell me the company that it's from (Like Kerbodyne or something of your own) 7. Must be stock 8. Don't make it like on of those rediculous 100-relays-in-one-launch kind of things. I can launch only 4 small probes per launch. 9. Send me the link to it on Kerbal X. That's it! It may take me a while to get to launching your spacecraft depending on where you want it or whoever has submitted something before you. Like if you want something to Moho or Dres, you'll have to wait until my rockets get advanced enough to do it. Special thanks to @TheEpicSquared for giving me the idea and letting me do this.

Solved: So the update was a Steam update, and that somehow corrupted some drivers for the graphics card. I realized that after trying a few other games and seeing them fail to launch too (including non-steam games). The specific problem was "Failure to Initialize Direct3D" which I learned when the Hearthstone error message actually specified the exact issue (steam crashes didn't for some reason). The issue was fixed by running windows troubleshooter to fix the corrupted files and restarting the computer when prompted. Posting this because nothing is worse than coming to a forum to find a solution to a problem and seeing something like "NVM I solved it, thread closed" and there being ZERO explanation as to how to fix the problem. Seriously that is the WORST. STOP DOING THAT. Last night (11/04/16) when launching KSP steam preformed a very short update that I assume was just some minor tweaks and whatnot. After this however, whenever I try to launch the game it immediately crashes. To be clear I had no issues launching the game after the "Loud and Clear" update, only after this small tweak last night (haven't played in a couple weeks so not sure which day it came out). Reverting to previous version only shows the last major update (w/out loud and clear). I tried uninstalling and reinstalling the game a few times and that hasn't fixed the issue so I'm kinda at a loss. Here is the error it spits out

Hello i'm back and i decided to put a rocket on the back of my boat this time... and land it........ on the boat Take a look (Same mods) KAS/KIS, VaporVent All pictures here http://imgur.com/a/Di4BB

It should be doable to create an online launcher performance calculator using Orbiter analogous to Dr. John Shilling's calculator: Launch Vehicle Performance Calculator. http://silverbirdastronautics.com/LVperform.html It should have an GUI where you could just plug in the specifications of your rocket and get a reasonably accurate estimate of the payload to Earth orbit, without having to be familiar with Kerbal programming. Bob Clark

Follow the livestream of the Vega launch from Kourou, French Guiana : http://www.arianespace.com/mission/vega-flight-vv07/

The definition of a perfect gravity turn according to Wikipedia (always reliable) is an ascent path such that at any given point (after the pitchover maneuver), your angle of attack is zero. Here's my issue: I want to test using this definition to optimize my gravity turns by keeping my angle of attack at zero, but I have no idea how to calculate the angle of attack for my rockets. Most internet information, such as pages on Wikipedia, focus on angle of attack for aircraft. What is the definition of angle of attack for a rocket? How do I find a rocket's angle of attack using tools in KSP?

I would like to put a ship into orbit around minmus with a minimum of fussing around. I've heard that a 'direct launch' is the lowest dV way to get where you're going. Basically, skip the parking orbit and just go for what you want. Okay. Fair enough. What I want is a rendezvous orbit around Minmus with this here tanker, so that it can refuel an on-station lander. This means that in addition to burning directly into my minmus rendezvous, I also want to have inclination. I'm assuming, since I have zero control over where the KSC is that flying directly into the minmus encounter's no good. But how do I know which way to point my navball to get the properly 6-degrees-inclined orbit after I circularize into LKO? (I'm aiming for an 80km parking orbit to go for my rendezvous burn from.)

Is there a rule of thumb for getting a rocket out of Kerbin's atmosphere? All that I've gathered thus far is that powerful rockets can get into space at shallower angles. Alternatively, a rocket solely designed for Kerbin orbit requires about a 45 degree angle when it's all said and done. Since target assist is not an option from launch, how do I know from rocket to rocket what the angle should be? Also, does career mode build off of the tutorials, or am I better off playing around in sandbox first?

Are there any general tips or methods on how to launch REALLY HEAVY STUFF into orbit. I'm talking about 1 Million kg.(It's going to go to EVE and then to Gilly and land there. Then back home, but it has tons of science equipment from mods and it has a science lab and 2 command pods so thats why its so heavy.)

Hello all, KSP has just started crashing inexplicably as soon as I double-click it to start. It had been crashing frequently before, and after one crash I tried starting it again and it gave the "the game crashed" message almost instantly. I tried again, same thing. Happens when I launch from Steam and directly from the Kerbal Space Program folder. I thought it might be my mods, so I removed them. Still, the game crashed on startup. It doesn't even get to the loading screen, it just crashes. I just tried it in 32-bit, no mods, and it loaded fine so it seems to be a problem with 64-bit. Modlist (started with them in Gamedata but the crash still occurs in stock): output_log.txt, from a modded crash: And one from after removing all the mods from Gamedata: Here's my system specs (or at least the ones I could find ): Insight is appreciated, although be aware I will be travelling on Tuesday and won't be able to try anything from then until July 8th. Thanks!

So it seems that every time I launch anything on top of a vector engine the rocket goes all wonky (sorry for the technical jargon) for a few seconds before the gimballing kicks in and straightens it out... Is this a known bug? Or is it by design and just thrown in to make life exciting? Or is it one of those things that I'm the only one experiencing? Danny

Hi! I still pretty much a KSP beginner, I played a bit before the official release. Now I'm playing on Science Mode and I want to land a Kerbal on the Mun, but I have a problem. I've built a rocket that can easily reach Orbit and even the Mun. But as soon as I add landing struts to the "landing part" I can't seem to launch the rocket from the launchpad straight up. Without the struts reaching orbit is easy, with them I just can't manage because the rocket starts tipping straight away... Is it normal that the landing struts have such a large impact? And what can I do to fix the problem? Maybe I am attaching them wrong, but I tried to balance them out and everything. Below some screenshots of my rocket with and without landing struts. Thanks for your help!! Without landing struts: With 3 landing struts: With 6 landing struts, symmetrical to the tanks below:

Sometimes, after I load a saved game, KSC shows up at a vantage point near the ground by the VAB. Pressing ESC does nothing, pressing the Pause Menu button does nothing. Mod popups all work OK. I have to close and re-launch the game. Screen shot of Loading problem

In 64-bit KSP 1.1, with only one mod (the docking alignment indicator) - launching a fairly large rocket (174 tons in 6 stages): If I save and then attempt to load the vehicle, it shows up on the vehicle list as "116 parts in 13 stages", but there are only six stages on the sidebar. I click "launch". I go to the pad. If I don't do anything for a few seconds, the spacecraft settles in. It appears to be intact, but the first three stages disappear from the stage sequence on the left. If I activate the staging sequence, I get the fourth stage. If I hit the "stage" button before the rocket "settles in", stage one fires as it should, but controls then appear to be locked. I have checked visually - in both of these scenarios, the rocket appears to be intact, just the controls are misbehaving. If I leave the pad after the rocket settles in, then come back, the top half of the rocket falls to the pad immediately upon my return and lights everything on fire. I do not see the bottom half. The spacecraft in question has three probe bodies and no crew. I have tried quitting and reloading, shuffling the stage sequence, and similar with no apparent effect. Has anyone seen similar behavior? Any idea how it might be fixed?

Launch Clamp How-To (Tutorial) I'll probably add detail later, but I wanted to at least get this started. Launch Clamps are one of the more tricky things to make, second only to landing gear/legs, but not nearly as hard. However, you do have to get a lot of the details right. Positions and orientations of transforms matter a lot, and nothing will work right if you get some of the details wrong. An excellent starting point is the FASA Launch tower tutorial by @frizzank, and in fact that's where I learned to make them. At the time that I made the launch clamps for SpaceY, I followed that pretty closely and ended up moving things around in Unity to make it work. Today I rearranged it in Blender so that nothing has to be done in Unity afterward. So this is a "How-To" using my "new method", from Blender. There are probably other ways of doing this, and in some minor ways it differs from the FASA setup, slightly. However just like the FASA tutorial, let's look at the CFG setup first, then what you need to make in Blender afterward. MODULE { name = LaunchClamp // Module name. DO NOT CHANGE. trf_towerPivot_name = Cap // Rotation transform that the tower connects to. trf_towerStretch_name = Tower // Transform that gets stretched to make the tower. trf_anchor_name = Base // Transform that connects to the ground. trf_animationRoot_name = SYclamp1new // Transform that contains the animation // and all animated parts, at some level. anim_decouple_name = clamp // Name of the retraction animation itself. } This is pretty straightforward. The "Cap" is the top of the tower, the part that connects to the clamp itself. The "Tower" is a transform that contains all of the stretchy tower meshes. The "Base" is what sits on the ground, and it will need to contain a collider. The Base's collider acts like a foot and keeps the clamp from twisting, however the clamp's "attachment" to the planet is actually at the Cap's origin, or close to it. Yes, it's a hovering object, technically. So first, in Blender, create four (4) empty transforms. You can hit Shift-A and select "add empty" for each one. Then give them these names: Cap, Base, Tower, Clamp The "Clamp" transform is really just a place to group your animated and non-animated meshes for the clamp itself. Now we'll talk about each one, and what goes in it. Each mesh object you make needs to be a child of one of these transforms (though like I said, "Clamp" is just for organizational use in this case). In Blender, I'm assuming you're working in the default orientation with +Z going up. I do the export as an animated FBX, to import into Unity. Let's start at the bottom and work up: (After importing, the Cap, Base, and Tower transforms will need to have a rotation of 0,0,0 or something "close" to it, either with floating point rounding errors, or some "360" or "-360" values. The "X=90" rotations below are for Blender, so that it gets rotated properly during import to Unity). Base This transform's position must stay at 0,0,0, and it needs a rotation of X=90. As children of it, you will need two mesh objects: One for the base artwork itself, most of which will extend into the ground, but with the visible "foot" of the tower included. Usually this mesh should be designed to have several meters worth that extends into the launch pad, so that if you build a large rocket, and the clamp is placed outside of the pad, the length still reaches the ground outside of the launchpad. Extending down to -6m is probably sufficient. A simple mesh collider that corresponds to only the part of the base/foot that should be above the surface of the launch pad. You can add this later in Unity as a box collider or something if you want, but I use a custom mesh collider here. If you try to make this collider too tall, and encompass the part of the Base that is meant to extend under the launch pad, then the entire thing will "jump" upward to make sure the entire collider is above the pad when it spawns. The bottom of the collider should be at a height of exactly zero (0). Keep in mind that 0,0,0 is the surface of the launch pad. The visible part of the base/foot needs to be above Z=0, and the rest of the base that's hidden inside the pad will be below Z=0. (Note: The Base, Tower, and Cap transforms will never be rotated relative to the launch pad. They do not rotate with your clamp's deployment orientation.) Tower This transform's origin position will be at the bottom of the cap's mesh, and the top of the tower's mesh, centered over the base, at 0,0,Z, where Z is a height that you will define. It has a rotation of X=90. This transform moves with the Clamp and Cap, but is scaled in height so that it can always reach the ground. You can add the visible mesh directly to this transform, probably, but I make a separate mesh object that is a child of it. The Z coordinate for the Tower transform should be above the origin by some number of meters, with enough height to create a tower mesh object from there toward the ground, extending below 0,0,0 a little bit. This mesh's top edge must terminate exactly at the Tower transform's origin. That is, the top edges must not be above or below the Z height of the Tower transform. This is very important, since the mesh is being stretched by scaling it from the Tower transform's origin coordinates, any errors with regard to the top of the mesh will be amplified when the launch clamps are used high off the pad, and will not line up with the Cap. The texture used by the Tower's mesh needs to be repeating along the Y-axis. As the mesh gets stretched, the texture does not get stretched, but rather "tiled" vertically. It's OK to have UVs that use different X positions for different things, but the entire Y-height of the texture needs to be a vertically repeating pattern. (Note: The Base, Tower, and Cap transforms will never be rotated relative to the launch pad. They do not rotate with your clamp's deployment orientation.) Cap This transform's origin needs to be at 0,0,Z (Rotation is X=90), centered over the Tower and Base, with Z at a height that you define. This height should correspond to the attachment point at the front of your clamp, for sanity, since this is where your clamp's head will pivot. The Cap will have two main things as children of it: A mesh object that acts as the "cap" to the Tower stretchy-mesh. It should look like it's a part of the same object, artwork-wise. The bottom of this mesh should match up with the origin of the Tower transform, and extend high enough that no matter which way the Clamp's head gets turned around (on any or all three axes) that there's never a gap or missing or hollow mesh visible. When you attach the launch clamps to a rocket or plane, by default the clamp's head is rotated to correspond to the part it's attaching to, even if that means the clamp sits sideways or upside-down. The Tower transform and its children. The Tower transform is a child of the Cap transform. (Note: The Base, Tower, and Cap transforms will never be rotated relative to the launch pad. They do not rotate with your clamp's deployment orientation.) Clamp This can contain all of the mesh objects and colliders needed for the actual clamp. All animated parts for the clamp retraction will be in here. The colliders that you will "grab" in the VAB will be here. This is the easiest part, since it functions just like a normal animated part in KSP. I usually orient the transform/meshes such that the clamp is oriented with the +Y direction toward the back of the clamp, and -Y in the direction toward the rocket. As far as I can tell it doesn't appear as though KSP cares as much about the positions and orientations of anything other than Cap, Tower, and Base, and therefore you can pretty much do what you want with the head/clamp components. This part of the clamp will function like a surface-attached part, with the Cap/Tower/Base hanging down from the clamp. Putting it together Export from Blender, import into Unity like you would for any other part. In Unity's assets, select the model, set it to Legacy animation (as usual), scale of "1", and name your animation to match the name you used in the part module for the CFG. Export as a MU as normal. Screenshots of the SpaceY launch clamp: