Claw

I used to leave all the aerodynamic stuff off my rockets, but have since started adding it on. Somewhat for sheer looks, but also to get used to having it there for when the aerodynamics get overhauled. I also prefer stock. But since this is an open ended game, you can pretty much play-pretend whatever you want. I would say that I don't let the lack of a feature stop me from playing a certain way. Such as adding nosecones or controlling my reentry speed/angle for heat considerations. You can still do all that without the use of mods. Personally, I got tired of quirky mods causing crashes, or at least more crashes than I already get with stock...

Well, you're on the right track with the design. Your's just so happens to look pretty similar to one of mine. I have multiple versions in this line of TurboJet SSTOs (up to 80t or 100t, I forget). This one isn't as big as what you want, but it happens to be a handy picture I have available. This particular one also doesn't have parachutes on it, but those are easily added. Some differences to make note of from yours: 1) Use TurboJet engines, instead of basic jets. 2) Don't asparagus your strap on tanks. Simply make them smaller and isolate them. Otherwise you either end up with an fuel/oxidizer imbalance in your main tank, or you end up carrying too much fuel around. 3) Ditch any oxidizer in your strap on tanks. (Can't tell from your pic.) 4) As has been hinted at, fly fairly horizontal at 25-ish km and let the TurboJets build up some speed. That's why you want to use them. 5) You need some more rocket fuel for your mainsail. For this family of lifters, I find that I typically need as much rocket fuel on bottom as what I'm carrying on top. Incidentally, I also wait a bit longer before firing up my main engine. I think my 40t lifter also has a few more TurboJets on it. If you want to keep your number of Jets as it is, then you'll definitely need more rocket fuel. You can also parachute the TurboJets and decouple them when you're done with them. That'll give you a bit more dV for your main engine's orbital insertion. If you do that, put the engines on a hotkey to shut them down before decoupling... (insert funny picture here) EDIT: Ahh here. I found a few more examples if you care to look. The album was for a challenge, but shows how much you can lift on just TurboJet engines. 236t at launch, it ended up with all that junk (8x 200-8 fuel tanks) + 3/4 of an orange tank when it reached orbit. I honestly can't remember the mass on orbit, but maybe around 100-110 tons. Only the first 6 or so pictures apply to this thread, but you can see that the ascent (picture #2) is done purely on TurboJets. Plus Taki mentioned a space plane. So I put that on here too. It was another example I made a long while ago to help someone else out.

What operating system? I'm running Windows. When I go to the VAB/SPH and shift-click on the parts list, nothing unusual happens. When you Shift-Click on the craft, it selects the whole thing. In either case, you should never have to Shift-Click to pickup or place parts. And like Taki said, you use ALT-Click to copy an existing part (but not to place it). So I suppose that leads me to the question, are you using any mods? I think some of the editor extensions add hotkeys which toggle various symmetry and angle snap modes.

Sorry for the delayed response back. There will only be a vInfo section under certain circumstances. Camwin does have a vInfo section. ACTIONS { } vInfo { vesselName = Camwin Kerman vesselType = 9 rootUId = 2072884961 } This section belongs at the end of the kerbal's VESSEL structure (right after ACTIONS). Danlong doesn't have a vInfo section, but I also didn't need to create one for him. I'm not sure why fixing the idx didn't work for you. I was able to quickload and your guys were fixed. Really, the rest of their vessel structure looks fine too. That makes me suspicious of your KSP version. Make sure you have version 0.23.5.464. There was a bug with the first release (version 0.23.5.459) which caused the poor guys to not recover. You can check your version number by going to your KSP directory and opening the buildID.txt file. It should look something like this inside: build id = 464 2014-04-01_17-03-49 Branch: master

Yes, they can cause wobble and instability. However, they can do that anywhere since wobble is more of a function of a craft's flexibility and inertia. If you want to speak in general terms, having them way out on the end for an already bending/wobbly ship will tend to make it worse. In my demo above, I can replace the two central fuel tanks with modular girders and make it wobble more than with the fuel tanks. If I use big fuel tanks with modular girders, I can make the whole thing come apart. And I can do that with reaction wheels in the center or at the ends, but it's definitely worse at the ends. In my experiment, I only ever ran two reaction wheels at a time (that was part of the demonstration). If I were to turn on more of the reaction wheels, it would turn a lot faster. In fact (just for you ), I just ran it with all the wheels on and it took 12.2 seconds for a full 360.

Depends on what you mean by efficiency. I couldn't find my old post on this subject, so I went ahead and recrated my old experiment (and took it 1 step further). I'll spare you my actual demo that you can do at home with a hammer, but here you are. So for this album, I made a completely symmetric craft fore/aft. There are two reaction wheels near the very center, two forward, and two aft. There are also three probe cores, but they don't really serve any purpose (other than to actually control). Gravity is hacked and all reaction wheels start disabled. Probe core torque is also disabled (for all experiments). Note the position of the CoM in the SPH. Also note the starting position of the CoM in the second picture relative to the runway stripes. For all test runs, I turned only two reaction wheels at a time. Then I recorded how long it took to yaw through 360 degrees, and took note of the center of rotation (using the runway as a fixed reference point). After a test, I reverted back to launch to do it all again. Center Two Reaction Wheels Time: 23.6 seconds Aft Two Reaction Wheels Time: 23.8 seconds Fore Two Reaction Wheels time: 23.4 seconds Aft/Fore Two Reactions Wheels Time: 23.5 seconds I only repeated each of these once (because I've done this countless times), so before you run off and conclude that putting the reaction wheels at the front buys you 0.2 seconds, bear in mind that I was manually timing inputs and 360 degrees. So for all practical purposes, a 0.2 second spread pretty much means there's no difference. Additionally, if you look at each of the pictures you will see that the center of rotation is still around the center of mass. If we were to say "the craft wants to rotate around the reaction wheel," the pictures would be dramatically different. As it is, I challenge you to tell which one is which (without the titles). A real mind bender is to see if you can figure out if I didn't purposely mix up the pictures...

Yes, but moment of inertia is completely separate from the distance from CoM where you are applying the torque. Applying torque at the end of a beam vs. the center of a beam has no effect on Moment of Inertia. This is false. This comment comes up repeatedly and it simply isn't true from the standpoint of "effectiveness." Torque is equally as EFFECTIVE regardless of location. Placement has other side effects such as bending, but leverage does not come into play when you talk about how capable a given amount of torque is. Yes. Except to say that RCS is more effective at the extremities for rotation. This is the important part in terms of practicality. Torque modules can cause bending, which can be catastrophic or at a minimum, cause strange effects to your craft (depending on size and flexibility). Yeah, spreading them out works best for most situations. But C7's comment is still misleading. They do NOT cause offcenter rotation. There are other reasons why you want to scatter torque modules around, but the craft will always rotate around the CoM. On a similar note, putting torque modules at the center of mass also does not guarantee that your space station won't wobble itself apart. It does tend to reduce the chances, but doesn't eliminate the possibility.

If you want autopilot kerbal walking, try this. (Assuming your shift key is still setup to make your kerbals run.) 1) Hold "W" to make him walk forward. 2) Hold "SHIFT" to make him run. 3) Release "W" and he should still keep going. 4) Release "SHIFT" and he should keep going. Now the trick is to stop him. 1) Hold "W" 2) Hold "SHIFT" 3) Release "SHIFT" 4) Release "W" and he'll stop. Hopefully you can see the pattern there. You can still use the keyboard for most anything else, and the mouse will pan the screen to change the direction of travel. (I think on Mun/Minmus, the gravity is low enough that you won't see a difference between walk and run, but the kerbals will still walk.)

Welcome to the forums! Thanks for posting the save file. You have the easy fix... Keep a copy of your quicksave in case of a mistake. Then open it with notepad or some other very simple text editor. I recommend editing your quicksave.sfs, because it's easier to quickload and check it with KSP open in another window. Go to the end of your file, where the crew listing is. The very end of the file has kerbals you haven't hired yet, so go a little above that. You are looking for this section: CREW { name = Danlong Kerman brave = 0.4985804 dumb = 0.8804786 badS = False state = 1 ToD = 6451509.50999685 [COLOR="#FF0000"]idx = -1[/COLOR] } CREW { name = Shelvin Kerman brave = 0.3672598 dumb = 0.06527674 badS = False state = 1 ToD = 4543614.48291874 idx = 1 } CREW { name = Camwin Kerman brave = 0.6407303 dumb = 0.6080619 badS = True state = 1 ToD = 4407195.47947788 [COLOR="#FF0000"]idx = -1[/COLOR] You need to change the highlighted red parts. It should say "idx = 0" instead of "idx = -1". Save the file, then quickload. Camwin will probably still fall down (into ragdoll state), but he'll get up again. Let me know if that doesn't work. Good luck! -Claw

It's a known thing. It was reported as a bug a while ago, but has been declared an "Easter Egg" called Tiny Chutes. (I still disagree since it can result in catastrophe...) If you quicksave/quickload while they are partially deployed, they are tiny but go back to normal at the deployment altitude. Unfortunately, if you do it when they are fully deployed, they come back tiny and you get to lithobrake.

I also posted my method here. http://forum.kerbalspaceprogram.com/threads/75759-Asteroid-Rendezvous-Outside-of-Kerbin%E2%80%99s-SOI

Edit your first post and click "Go Advanced." Select "Answered" from the dropdown, then save. Glad you got it sorted out.

Did you check my thread that I posted? It has a variety of fixes based on what problem you have. It's not simply a thread which says "update to 0.23.5.464." There's a specific fix for kerbals who were flung from external command seats, as well as kerbals labeled as debris.

Give this a try. http://forum.kerbalspaceprogram.com/threads/75586-Master-Thread-Unresponsive-Kerbals-in-EVA

Yep, you're right I did. It comes up a few posts later though. Although you provide more insight for motors. Thanks! I tend to build mine lower to the ground than the example you posted, so I don't run into the wheelie problem as much. Good advice.

That looks beautiful. Is that all stock?

Here. This is a bit of a recycle off of a previous post of mine, but it seemed like a good place to start. The junior and regular sized docking ports are reasonably obvious since each side is pretty distinct. The Sr docking port is a bit harder, because both sides are relatively flat. I've included the shielded docking port too, but that should be pretty obvious since you can only connect it one way. Each docking port has a lighter ring on the docking side. Those two sides must meet at a reasonably flat angle for the ports to dock. You can be pretty far off, but if your ship is large then the ports will have a hard time swinging the ship around to lock. If you are meeting up face to face correctly with the docking ports, then you may be experiencing one of the docking port bugs. In that case, you'll have to edit the save file, find the "broken" port(s), and edit the state to "ready" to reset them. By the way, welcome to the forums!

There's nothing wrong with leaving it unanswered for a bit. You do want the CoL above and behind, however... You typically only want it very slightly above. In line up/down is actually fine also. You don't want the CoL tooo far behind because your craft will "lawn dart." Meaning that it will constantly want to pitch nose down. I would say that based on your descriptions, this is not THE problem, but could contribute. Bad lawn dart behavior occurs just about throughout the flight envelope. So you would likely notice it on takeoff. If your craft is at 15 tons and 0.45 lift/ton, then it's probably under powered/under lift. If you don't want to add an engine, you need to add some lift. Also, I "generally" find that if you takeoff and your AoA is at 10 degrees or more down low, you'll probably have issues at altitude. This is pretty close to how I fly my profiles as well. A bit different, but it's a good basic profile. At face value, I would disagree with this statement because in the OP, the description at altitude leads me to believe the plane is flying at 30+ AoA. You've already passed the point where CoT vs. CoM is the root cause. This is, of course, based on what I'm reading here but pictures are worth a thousand posts. I would also disagree with this as a "complete" fix. It will increase your lift/ton so it may help. Unfortunately, if adding canards doesn't immediately fix the problem it will make it much worse. That's because there's a bug with KSP that causes the lift on flight control surfaces to increase with AoA all the way to 90 degrees. This effectively can cause your CoL to shift forward at high AoA which causes the plane to flip backward and go out of control. This would be one of my guesses based on what I'm hearing. Not enough thrust OR not enough wings. All that being said, CoT vs CoM could also contribute, as can the placement of control surfaces. But in my experience, a plane that is at 35 AoA in the heart of the TurboJet envelope has other problems. Not to mention that at that AoA, you've really cut back on your air intake, further hurting your thrust production. Like I said earlier, pictures or a craft file would help a ton.

By rule 1, the design all totaled up together, should be about 1 TurboJet per 12 tons. That includes fuel, wings, payload, etc. What I will say is that for overall design philosophy, if you want to build a plane that carries payloads to space you have to decide how big the max payload will be. Then design your airplane around that. So if you want to carry 18 tons into space, you'll need at least 2 turbojets to start off with. After you add all your engines, wings, fuel, structure, etc, you would want it to weigh roughly 24 tons. If the design starts getting up to the 30 tons with all that stuff, then you need to think about adding an extra engine or increasing the fuel/wings. I'm not sure if that's clear. Hopefully it answers your question.

Well, it would help if we had a picture before I make a broad statement like "you has a design flaw." But it does sound like your plane might be missing something. Having 35 deg AoA can be caused by several things. It's really the fact that you have to have such a high AoA that's contributing to the "if I let my nose down for a moment, then drag will straighten my ship." It may also be a Center of Mass (CoM)/Center of Lift (CoL) relationship problem. Or it could be...(a whole bunch of other things). So instead of listing all the possible causes which might make your plane act how you're describing, I'll list my basic design rules of thumb for space planes. These are my basic design rules that act as a place to start. You can adjust each one to get the look and performance you want. 1) 1 TurboJet per 12 tons of craft. Up to a maximum of 15 tons. There's not really a minimum. 2) ~3 ram intakes per TurboJet. Minimum recommended is 1 per TurboJet. Maximum is as many as you want, but once you go past 3, you have to double the number of intakes to see much effect. (so 6, then 12, then 20+) 3) ~150ish units of liquid fuel per TurboJet. Minimum of 100 units (as you get more experience). 4) 0.5 to 1.0 lift rating per ton. I usually aim for around 0.75 per ton to start off. You can use a variety of wing parts to get there. Minimum is 0.5 units/ton. Recommended Max is 1.0 units/ton because after that you don't gain much benefit and suffer from drag. The way these work is that if you lower the numbers in one rule, you should raise the numbers in another. So for example, a 12t craft would be: 1 TurboJet, 3 Intakes, 150 fuel, 9 units of lift. You could also increase the number of intakes and reduce the lift and get 1 TurboJet, 6 Intakes, 150 fuel, 6 units of lift. Or if you wanted it to fly a bit further: 1 TurboJet, 3 Intakes, 200 fuel, 12 units of lift. These rules of thumb don't have an exact exchange rate. (Such as 50 units of fuel requires 3 units of lift.) It's just a place to start your design, then gives you some guidance on how to adjust as you build. Phoenix ninja'd me (because I'm slow this morning), but Keptin's article that Pheonix posted is also really good. If you feel up to posting a picture, you will probably get more specific advice. Good luck!!

Well, I wasn't quite able to follow the conversation but the discussion about goo/materials is confusing. You can use and reset the goo/material as much as you like until you want to "keep" the data. You can then leave it in the pod/bay and recover the whole thing, or have a kerbal remove the data via EVA. If you remove the data via EVA, the goo pod/material bay is no longer resetable (and therefore can't gather more science) until you clean it with a mobile lab.

Ahh, yes. Well please forgive my previous (repetitive) post. Looks like I explained how you already felt about rovers. Pecan is right about the probe cores. More generically about the navball, it will point in the direction of a couple of parts. Namely any probe core, manned type pods/capsules/etc, cockpits, the external command seat, and docking ports. MechJeb can also be used as a control point reference. Unfortunately if you don't have any of those oriented the right way, you can't do anything about it after the fact (you might be able to add one with KAS?). If you do have one of those parts oriented the right direction, you can use it to orient the navball by right-clicking and selecting "control from here."

No problem. I did (and still do) a lot of lurking for ideas on the forums. I can't remember for sure, but you might have to do the brakes in the SPH. I thought you could do this while driving also though. (I'll have to check, maybe I'm remembering wrong.) You do bring up a separate point though which I forgot about. Disabling the motors can sometimes help control, but not nearly as much as disabling steering. It will definitely affect the top speed, but not by much. Disabling brakes really only affects flipping over while braking. You can also control that by tapping "B" and that will pulse the brakes. A lot of people will use RCS or ion drives pointed upward to push the rovers against the ground. That will increase your traction and help keep from flying off the surface. To each their own I suppose. I could also have said "don't bother," but it's really up to what you want to do. If your goal is pure science gain and efficiency, rovers will be much slower. But it's also a completely different game experience. If you enjoy building and driving rovers, then do it. Here is one method I chose in order to deal with the slowness factor and the explosive rovers. I built the one below for the Polar Challenge (drive from KSC to the North Pole). It took me several iterations, but I finally managed to make a design that is capable of full speed crashes at 4x physical time warp without damage (or at least, minimal). It's also able to flip itself back over. It's a rescue vehicle that carries a driver and medic, and has space for two patients. Practical top speed on level terrain is about 23 m/s. I haven't converted it into a space based rover, but I suspect I could replace the medevac space with science equipment and still retain a two crew capacity.

Welcome to the forums! This is a fine forum for asking such questions. Also, don't let people hate on you for using MechJeb. It's unfortunate that people have to be defensive about any mods they use. In any case, your design looks great. If you didn't know already, there are a few things you can do to help with the rolling and flipping. - Deactivate the brakes on the front tires, and turn it on for the back tires. You can do that by right-clicking on each one. - Deactivate steering on the back tires, and turn it on for the front tires. (Also by right clicking.) - Have your controls for rolling/pitching/yawing with SAS separate from your rover controls of turning/going forward. You can actually use SAS to counteract the tendency to flip. Like you said, I find that I tend to leave it on most of the time. If you take a sharp turn, adding roll torque into the turn also helps keep it from flipping. (Sounds like you've already discovered workarounds for most of this yourself. ) Generally speaking, you want your rovers to only have what you need on them. So, for example, if you only ever planned on bringing Jeb down to ride in it, then avoid taking up the extra space/weight of having room for 3 kerbals. Of course, if you want a rover you can use for lots of tasks then design it to suit those needs. That may mean overkill for certain missions. Also, on low gravity worlds (like Minmus) you actually want it to weigh MORE. That's because tire traction affects speed. So if your rover is too light then the wheels don't grip so well. Also, you can darn near launch yourself into orbit on Minmus by going up a hill too fast. Anyway, I'm sure there are more things people will add in. Good luck.

Not quite the same thing, but possibly this is related to the career saves getting locked out when v0.23.5.459 came out. If you had already completed the tech tree and loaded your save into 459, it might have been converted to a sandbox game. In that case, you wouldn't have noticed if you never went back into the R&D facility or did any science till now. Try the fix below in the link to edit your save. (Keep a copy, of course. In case that's not clear in my instructions below. ) EDIT: I guess I should have also said that a way to confirm your save has been converted is by trying to open the R&D facility. Old career mode save file locks out R&D science facility – [FIX] There was a bug with the first release of v0.23.5 that caused the R&D facility to be locked with old save games. 1) Make a copy of your save games and keep them somewhere safe 2) Update your KSP to v0.23.5.464 3) Go to the link below and follow the steps on how to fix your save file. Like I said, make sure you keep another copy somewhere safe. http://forum.kerbalspaceprogram.com/threads/74503-How-to-make-your-0-23-career-save-to-work-with-0-23-5