• Content count

  • Joined

  • Last visited

Community Reputation

130 Excellent


About purpletarget

  • Rank
    Krash & Learn

Contact Methods

  • Website URL http://www.youtube.com/user/PurpleTargets
  1. 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.
  2. 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.
  3. 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.
  4. "Any fool can calculate...." -Sylvanus P. Thompson Don't let math intimidate! When playing KSP, Math can be your greatest ally! True story.
  5. Moved to Gameplay Questions
  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 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.
  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 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.
  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.
  12. Braker, Reaction wheels are balanced in stock for gameplay in accordance with how the game is meant to function. Is it fully realistic?? Of course not. Neither is the impossible (IRL speaking) density of Kerbin to get earth like gravity in 1/11th scale planet. Some decisions is KSP are made to make it realistic as possible, but also concessions are made to make sure the gameplay is also fun! The problem is that if you relied on "realistic" reaction wheels, you'd need to keep your finger on the ASWD keys for several minutes to get an attitude adjustment up to a couple degree's a minute. It's not a "FUN" way. Even RCS is ridiculously OP relative to IRL counterparts, and maneuvers would not be enjoyable or playable as a game when setting for a single maneuver would take 30 minutes or more of constant attention for small attitude adjustments. This particular issue comes up intermittently, but was pretty much settled out about 3 years ago when the Pod torque systems was pushed to the electric charge dependent reaction wheels as currently implemented in v0.21. There was plenty of these polls prior to that... what's in the game is a reflection of how the dev's and playerbase overall felt about the gameplay balance of reaction wheels. So you can run as many polls as you like and argue your point with everyone that disagree's on you. But the plain and hard truth my friend, is that if you want reaction wheels to be adjusted to your preference, you'll need to mod it yourself, pick up someone else's mod.... or...the Stock solution provided is called "Toggle Torque" or something to that effect on the pod's right click menu... turn off the reaction wheels, and load up RCS to your heart's content. It's your game... and you have the options in stock to play it as you like... but that doesn't mean it is going to be "balanced" to suit only your style of play. There's a bunch of other people who just want to blow things up, or make crazy physics defying weirdness. Welcome to KSP.
  13. It's not just the wheels touching, but the sphere around it will affect the range of motion the wheels are liable to move into when steering etc. The blocking affect will also kick in sometimes if you bottom out the suspension going over large bumps if there's something overtop of the wheels. You may have noticed that the stock prospecting rover has a narrower flatbed in 1.1.1+. If you bottom out the suspension and that happens, and assuming your rover survives the skidding stop, the blocking condition will usually clear if you reload the scene... so jump back to KSC and then back to your ship again. DoesDoodles: When reporting issues like this, posting a screenshot will speak volumes, and greatly assist others in being able to tell you where things are an issue. Eg, the OP's screenshot shows exactly that his clipping problem is the probe body too close to the wheel, and not likely the solar panel at the top of the wheel mount.
  14. You may want to relook at this one in 1.1.1 As per the Patch Notes: If it's still an issue, then feedback will always be good to see in the bug tracker.
  15. Moved to tutorials