DeMatt

..."fast" and "maneuverable" are not characteristics of aquatic vessels in KSP. You may want to take a peek at Hooligan Labs or InfiniteDice's Boat Parts.

In the VAB/SPH, you can rotate a part you're trying to place. QE, WS, and AD all rotate in various directions; pressing them alone gives you 90-degree increments, while Shift+key gives you 5-degree increments. Decide where you plan on attaching the part, hover the mouse pointer over the spot, rotate as necessary, click to finalize. Note that the Space Bar resets the part's rotation to default - useful if you can't figure out which way a given key will rotate it.

After wishing for the umpteenth time for a SRB bigger than the Seperatron and smaller than the RT-10, I remembered this thread, and how it scaled down an existing model with just a .CFG file. I can do that, said my brain, and after a few hours of tinkering, produced this: PART { // Kerbal Space Program - Part Config // RT-5 Mini Solid Fuel Booster // // --- general parameters --- name = miniSolidBooster module = Part author = NovaSilisko/shrunk // --- asset parameters --- MODEL {model = Squad/Parts/Engine/solidBooster/model} mesh = model.mu scale = 0.1 rescaleFactor = 0.75 // --- node definitions --- node_stack_bottom = 0.0, -9.4, 0.0, 0.0, 1.0, 0.0, 0 node_stack_top = 0.0, 7.8, 0.0, 0.0, 1.0, 0.0, 0 node_attach = 0.0, 0.0, -3.3, 0.0, 0.0, 1.0, 0 // --- FX definitions --- fx_exhaustFlame_yellow_small = 0.0, -5, 0.0, 0.0, 1.0, 0.0, running fx_exhaustSparks_yellow = 0.0, -5, 0.0, 0.0, 1.0, 0.0, running // fx_exhaustLight_yellow = 0.0, -5, 0.0, 0.0, 0.0, 1.0, running fx_smokeTrail_light = 0.0, -5, 0.0, 0.0, 1.0, 0.0, running // --- Sound FX definition --- sound_vent_medium = engage sound_rocket_hard = running sound_vent_soft = disengage sound_explosion_low = flameout // --- editor parameters --- TechRequired = precisionEngineering entryCost = 3000 cost = 150 category = Propulsion subcategory = 0 title = RT-5 Mini Solid Fuel Booster //manufacturer = Jebediah Kerman's Junkyard and Spaceship Parts Co. description = While the RT-10 is made out of a full-size trash can, the new RT-5 Mini is made out of a smaller, more handy wastebasket. Good for those times when all you want to move is a trash can. // attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision attachRules = 1,1,1,1,0 // --- standard part parameters --- mass = 0.0625 dragModelType = default maximum_drag = 0.3 minimum_drag = 0.2 angularDrag = 2 crashTolerance = 7 maxTemp = 3600 // --- solid booster parameters --- 3.75 stagingIcon = SOLID_BOOSTER MODULE { name = ModuleEngines thrustVectorTransformName = thrustTransform throttleLocked = True exhaustDamage = True ignitionThreshold = 0.1 minThrust = 0 maxThrust = 60 heatProduction = 500 useEngineResponseTime = True engineAccelerationSpeed = 10.0 allowShutdown = False fxOffset = 0, 0, 0.12 PROPELLANT { name = SolidFuel ratio = 1.0 DrawGauge = True } atmosphereCurve { key = 0 230 key = 1 220 } } MODULE { name = ModuleAnimateHeat ThermalAnim = heatAnimation } RESOURCE { name = SolidFuel amount = 54 maxAmount = 54 } MODULE { name = ModuleTestSubject // nowhere: 0, srf: 1, ocean: 2, atmo: 4, space: 8 environments = 15 useStaging = True useEvent = False } } Now, there's a couple things I'm not enthusiastic about: The FX definitions. I did find a list of the things on the wiki, but I'm still iffy about whether I A) picked the right ones, or should've been looking for a rescale function of some kind. The attachment nodes. I eyeballed them in KSP (that's what took the hours), but I'm wondering if I actually did them right. Anybody willing to take a peek?

...have you actually targeted the object? Go to the Map view, find your desired object, left-click on it to bring up the menu, and choose "Set as Target". Then there will be a pair of pinkish markers on your Navball showing the direction towards and away from your target. The yellowish position-and-distance highlight in the ship view only activates within a certain distance - I think it's 100 km, but it could be as little as 50. You'll want to get the hang of Map maneuvers to get that close.

You're trying to go too fast at too low an altitude and pull too tight a turn. Fix one (preferably two) of these factors and you won't tear your plane apart. My suggestion would be to make it a tail-sitter, so you take off and land vertically. For comparison, the MiG-25 has a takeoff speed of <92 m/s, while the F-104 lifts off at <98 m/s. For a conventional plane, with that tankage, I would say you have too little wing surface to permit aerodynamic flight. As-is, you're flying a rocket with really large fins. Turbojets have reduced performance at low altitudes and low speeds. The reduced performance means they're gentler on your craft at takeoff, while still giving a lot of power at high altitude and speed. ... Xavven's "DCS" stands for "Digital Combat Simulator". So that would be a different flight simulator.

If you press the Caps Lock key, you toggle Fine mode on your controls (the arrows on the meters in the lower-left change from orange to blue). This automatically adjusts all your RCS thrusters's output to have the same effective torque. So if you have your RCS thrusters reasonably balanced, e.g. one ring somewhere forwards and one ring somewhere aft, they'll thrust at a balanced rate and not turn your ship when you translate. It will, however, reduce their output.

Did you already "remove" the data from the experiment, say by transmitting it or by processing it? There's no point cleaning an experiment that hasn't had its results observed.

...you aren't time-accelerating, right?

...It's worth noting that the altitude and speed readings in KSP (and in your video earlier) are in Metric, not Imperial, units.So while 6300 metres is three times higher than you think it is, 920 metres per second is a LOT faster than 920 miles per hour.

I think the simplest explanation is that, at high altitude, you don't have a lot of air to push against and make your turn. Think of it this way: when you drive a car slowly, you can make a really tight turn with the steering wheel all the way over. Drive that same car at highway speeds, yank the wheel over, and you've got a pretty fair chance of flipping it rather than turning. Take it gently, and don't even bother trying rudder turns. You can try adding more wing surface (not control surface), and see if that helps.

It's worth noting that the Launch Window Planner goes for the UTTER PRECISELY TOTAL OPTIMAL solution when it picks one. In this case, that means the 3083 m/s transfer listed above. If you're willing to spend a mere 1000 m/s more, then you can get an earlier - and quicker! - transfer: Selected transfer details Departure: Year 14, day 49 at 2:43:12 Arrival: Year 21, day 205 at 4:48:00 Time of flight: 7 years 156 days 2:04:48 Total ÃŽâ€v: 3,919 m/s Selected transfer details Departure: Year 17, day 273 at 3:02:24 Arrival: Year 24, day 8 at 4:24:00 Time of flight: 6 years 161 days 1:21:36 Total ÃŽâ€v: 4,078 m/s My advice is to go play with the Launch Window Planner - put in your current situation details and the transfer you want, then click around on the resulting graph and look at different potential transfers. Launch windows are not "open-and-shut" affairs... they are continuous functions, and the mathematical minimum might be over-optimized for your needs.

No, you can't. They are rocket parts, therefore they have physics calculated for them when they could be interacted with.Since you can do the 5x-10x-50x time acceleration, KSP is able to put them on rails, which means that KSP thinks they're landed and stopped. That slight mm/s twitchiness in the KER readouts is due to physics trying to "fall" them through the ground and failing due to the presence OF the ground and the currently-active brakes. You will get the same twitchiness from all but the most basic rocket, newly placed on the launchpad. You can try increasing the Terrain Detail, Graphics Detail, and Max Physics Delta-Time settings (that is, tell KSP to run more calculations to be more precise), but your description of "35 mods" suggests that you're already loading KSP pretty heavily. MY recommendation would be to split up the components of your base so that KSP can simulate them individually, rather than forcing it to run them as a group.

It's 11 oxidizer to 9 fuel, so there's 249.33L of oxidizer involved. 453.33L combined divided by 11.01 L/s = 41.17 seconds burn time, exactly what KER says. Metro is high enough that the atmospheric effect on the Isp is smaller than our level of precision. You can tell by looking at KER's listed Specific Impulse figure... 370 seconds, to three decimals.

I'm gonna go with "on the ground". I can't think of any possible Kerbin-SOI orbit that wouldn't be easier to reach from "approaching Kerbin SOI" than it would be from the ground. Anyways... why imprison kerbonauts in the environment they've dedicated their lives to reaching?

I test-fly -> I tweak -> I test-fly -> I tweak. Don't think there's a simple algorithmic way of solving for optimum fuel/oxidizer ratios, given all the variables in play. Do know that you can use the SPH tweakables to strip out unnecessary supplies. Got no RCS? Take the monopropellant out of the cockpit. Want less oxidizer, but not enough less that swapping an FL-T400 for a Mk1 Jet Fuel would work? Tweak down the oxidizer in the rocket fuel tank.

What broke was the connection between the two orange tanks in the center stack. As to why... I suspect it's to do with your thrust-to-weight ratio. You have two G's acceleration off the pad, which is a lot for any rocket.My recommendations are as follows: Replace the wings with AV-R8 winglets. I doubt you need THAT much aerial control, particularly if you then add one or two winglets to each of the outer boosters. Move the boosters' decoupler connections to the upper tank. One less joint to pass force through. You've got a Mobile Processing Lab. Assuming you actually put kerbonauts into the thing, that means you can clean Science Jr's and Goo capsules, allowing you to reuse them. So you don't need FOUR Science Jr's and SIX Goo capsules... one Science Jr on the centerline, and two Goo capsules (to be symmetrical) will do. You have a ridiculously large amount of RCS fuel and RCS thrusters. You have five rings of RCS blocks (at 4x symmetry); two rings is plenty for the size of ship you're flying. The 2.5m RCS tank is also overkill. I'd suggest switching from the two long 1.25m tanks to one 2.5m tank. Then, you can use the 2.5m decoupler between your booster and your orbiter, instead of slimming down to 1.25m and back up. If this craft is supposed to dock and fly with a different craft... then I recommend switching from the standard-size Clampotrons to the large Clampotron Sr's. Finally... take it easy when you launch. Don't hesitate to throttle back. You have information readouts from MechJeb... find the Terminal Velocity readout and try not to go over it.

As the title says - I would like to see the RCS fuel tanks moved out of the Propulsion part tab, and join the RCS thrusters in the Control part tab. Generally, when I build my rockets, I'll add an entire subsystem at a time. A stage (engines and fuel tanks), the science bits (except for the SACNC, they all fit together), etc. But it always annoys me when I decide to add RCS, and I have to flip back and forth between the Propulsion tab and the Control tab to add/remove tanks and add/remove thrusters. Additionally, the Propulsion tab is crowded with all the solid- and liquid-fuel gear, while the Control tab is almost empty - shifting the RCS tanks from the former to the latter would (partly) balance out the number of parts in these two tabs.

First, the compliments: yay lights! Pretty shiny twinkly colourful lights I can slap all over my ships and stuff! Now, the suggestions requests: The colourization tweakables on the stock Illuminators are mighty convenient... using them would reduce the number of VAB part entries to two - dim Navlights and bright Strobelights. I really wish there was a different model of light - a projecting cylinder or sphere, like the classic "gumball" light you find on old police cars. Obviously, not directional or rotating. In concert with the previous, I'd adjust the directionality of the existing lights to project only outwards, in a half-sphere, rather than the existing full sphere.

I'm running Windows 7....Just to be sure, I stripped out my mods and tried it again. Apparently one of the mods I had was interfering somehow, because the unmodded installation did work with an EVA.

Try looking through KSP's log file and see if it says anything: If you're using Steam, right-click on Kerbal Space Program, choose "Properties", then the "Local Files" tab, and click on the "Browse Local Files..." button. Otherwise, find your "Kerbal Space Program" directory. The main log file is located there, named "KSP.log", and should open easily with Notepad or your text editor of choice.

My keys for "walk forwards/backwards" and "pitch up/down" ARE the same (they never got changed from the default). That's why I posted that the bug didn't replicate for me with an EVA.

Hrm... I'd never encountered the problem before, but it sounded funny, so I tried it out. I was unable to replicate it with an EVA-ed Kerbal as my source of control; I assume this is due to the EVA's not needing SAS or trim functions. So my successful test setup looked like this: It's worth noting that the SAS only "reverts to trim setting" on the axis (axes) which are being steered.

I believe it has something to do with the way Unity does full-screen graphics - that is, if it can't actually find the screen real estate it's supposed to work with (as in you alt-tabbed away from a full-screen application), it pauses until it gets the screen back. Try switching KSP to a windowed view. That works for me.

I seem to recall reading that the "Soviet Pack" includes functionality from the ECLSS life support mod. That mod doesn't put any life support supplies onboard pods, and will kill kerbonauts outside of breathable atmosphere at 14 kilometres altitude. So, yeah.

Squad already tried changing it, back before v0.23 when they were switching from the old "you have % jetpack fuel remaining" to an actual resource bar, and found that using the intended monopropellant was more hassle than it was worth. Which is why "EVA Propellant", as a resource, exists. So I don't think they're going to change the "infinite EVA fuel stored in pods" any time soon.