Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

130 Excellent


About purpletarget

  • Rank
    Krash & Learn

Contact Methods

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Locked Until Further Notice at OP Request
  2. 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
  3. 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 i
  4. 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.
  5. "Any fool can calculate...." -Sylvanus P. Thompson Don't let math intimidate! When playing KSP, Math can be your greatest ally! True story.
  6. 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 headin
  7. 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
  8. Deepest sympathies Cdr_Zeta for your loss... I wish you all the best in sorting out whatever come next. Hold fast!
  9. 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.
  10. 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.
  11. This is old school KSP... girders used for landings was how Mun landings were cheated before landing legs appeared in the game. Nicely done.
  • Create New...