purpletarget

Locked Until Further Notice at OP Request

Locked Until Further Notice at OP Request

Locked Until Further Notice at OP Request

Locked Until Further Notice at OP Request

You can use thrust and ISP at either Vacc or ASL to determine the max flow rate for the engine. The ISP runs linear from the ASL (atmo 1) to Vacc (Atmo 0) ratings... and therefore, so will the thrust difference between the ASL and Vacc values. The pressure curve for Kerbin (and other atmo bodies) is generally available on the wiki. Others have mentioned that there's no easy deterministic formula for this....so I'd probably look at using a iterative approach with a spreadsheet. But, if you have a particular height and speed in mind, you can use basic STD formulas to determine things like what average acceleration you would need to make it to x alt at y speed, and that can lead you back to your TWR calculations to make sure you have the right engine and fuel load for the job. Chances are, your drag losses will be fairly minimal, and you can get close just allowing for gravity losses over your estimated time, unless you're flying a pancake.

There's a bunch of modifiers and multiples in physics.cfg. It is modified by the Mach Number, (DRAG_MULTIPLIER), a couple flat modifiers/multipliers, and then there's also some facing curves... mostly only the tip and tail need to be considered. The A and Cd values can be teased out for each part from the PartDatabase.cfg. There's a post that talks about calculating volume of parts for buoyancy that talks about how the drag cubes are formatted. And THEN there's also another curve to convert the Cd from the file to another Cd value... again in Physics.cfg. There may be another variable in there somewhere, given the change log for 1.2 included some discussion of making some better drag distinctions for pointy and not-so-pointy ships. Just the pressure, as per the usual equations.

The radial decouplers which used to restrict fuel crossfeed, should have toggles in 1.2 to disable the crossfeed, putting it back to the older behavior that you seek.

"Any fool can calculate...." -Sylvanus P. Thompson Don't let math intimidate! When playing KSP, Math can be your greatest ally! True story.

Moved to Gameplay Questions

This is actually fairly trivial bit of trig to figure this out. You probably know how long it takes to get into orbit... so if it takes 5 minutes to get there, then you want to launch a little less than 5 minutes before the launch site passes under the orbital plane you're trying to get into. Next, you need the orbital velocity you need to reach. I don't know about RSS, but whatever that Vo is... have it handy. You also need the ground speed of the planet... (check orbital speed on navball when you're still on the ground if in doubt) From the equator, you'll want an initial heading near the inclination of your orbit, N or S from 090. So if your inclination is 20 degrees, you'll want to be looking at heading towards 070, or 110. But then you need to be looking a little further west to neutralize the ground speed... and that's where the trig comes in. It's actually easiest to draw it out. But basically, if you had 3000m/s for Vo, and 300 m/s for ground speed, you'll be looking at up to around 6 degrees further (for polar orbits)... so 064 or 116... probably more like 068 and 118... but whatever. If you have a launch site at a different lattiude, the main differences is that you won't need to steer as severely to get into the orbital inclination... ie if you were at 20N Lat and wanted a 20 degree inclination, you'd have to launch at 090! And the ground speed will be less, the further north you go. This is an older video using stock, but the principle and math is the same... around the 5 minute mark, it'll take you through step by step. If you really don't want to do the math... you can simply launch and set your gravity turn a couple degrees west of your inclination heading, and watch the orbital prograde marker on your navball. When it's on the right heading (070 for a 020 inclination for example, in orbit mode) then you're probably pretty close to what you need.

The Rovermate's orientation basically looks forward out the larger flat side of the body. So if the flat side is up, the control source is looking UP. The way you have it in your picture, it's looking down. Either one in 1.1.2 will not orient the wheels correctly... the control point needs to be set to try and be level with the horizon at the "front" or "back" of a vehicle for the wheels to work on steering correctly. (This wasn't an issue with earlier versions of the game... but after the last update, wheels are a lot more picky about which way the probe/pod is facing) Generally, the reason the stock prospector works is because it uses the command chair part for control, which are oriented to face the front of the vehicle. As eloquentJane said... a docking port on the front will give you a control point option which can be used to correct the control facing.

Deepest sympathies Cdr_Zeta for your loss... I wish you all the best in sorting out whatever come next. Hold fast!

There is a general bug where orbits in flight aren't entirely stable. http://bugs.kerbalspaceprogram.com/issues/9619 However, 300 km over the Mun shouldn't have degraded quite that quickly, and have no illumination if MJ may have done something while you were away.... Leave your craft on rails via warp out at KSC scene, and it should behave better.

Yes, it's all to do with the orientation of your control point. In your original case, the probe core pointing to the sky won't allow the wheels to behave as expected. In your edit 2 example, the wheels will be slightly better in that your probe is facing the horizon, however... it's still upside down (navball, blue should be on top). Flip your core around right side up, and you'll probably get more desirable results.

This is old school KSP... girders used for landings was how Mun landings were cheated before landing legs appeared in the game. Nicely done.