purpletarget

Moderator
  • Content Count

    407
  • Joined

  • Last visited

Everything posted by purpletarget

  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 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.
  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 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.
  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 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. If that's indeed the case, it would be awesome if it was logged in the Bugtracker so that it could get to the Dev's attention. Otherwise, unfortunately, just making passing mention of things like this on the forum won't help in having bugs addressed. http://bugs.kerbalspaceprogram.com/projects/ksp?jump=welcome ETA: (Also... try changing the settings and then restart the game to see if it still manifests)
  16. If you want to get even more precise with that, warp to about 3 minutes before the node, and then switch and launch from KSC. The time it takes the gravity turn to get into the polar orbit should align even better with the target orbit, given the 3-4 minutes it generally takes to get into orbit. Although, a 3 degree plane change to adjust isn't too expensive...but the lead time can reduce that further.
  17. You should be able to remedy this by setting the dead zones for your stick. IIRC, there are settings for this in KSP on a per-axis basis, but the fancy sticks usually also come with access to modifying dead zones in the joystick properties as well. Check the joystick settings, or whatever joystick programming software the vendor has supplied. However, it will only work if it's still functional, and the phantom signal isn't twitching past a reasonable threshold for the dead zones. For example, my X-52, the Twist axis on the stick was twitching so bad at centre (again, checking the Joystick Testing within the custom drivers provided) that a dead zone was useless,...so I eventually had to cut it out of the inputs all together...for all games, as it seemed to be a hardware problem at that point. (The stick is several years old, and has seen a few thousand miles)
  18. I'm not sure what the official answer would be on this, however, consider the following possibilities: As Ges said, from a purely technical, game works like this way, the Asteroid is treated for the post parts like a large single piece Ship or Part debris. The game only deals in two body problems for Gravity, and the main source of gravity will be the Planet or Moon in the SOI that the Kerbal Ship and Roid are currently interacting. So the game will only deal with The Planet to Ship, and the Planet to Roid calculations. Ship to Roid calculations would become an N-Body problem, and that's not how the game works. From a practicality point of view, the infinitesimal micro-gravity presented by even the largest E-Class Roids in game is so small as to have nil observable effect in the game anyways. The gravitational effects would take days if not weeks of gametime to change anything about a ships interaction with the roid, and could be undone by reaction wheels or a kerbal sneeze. So there's really little to no point to it, as it wouldn't add anything to actual gameplay. (Pol/Bop can be painfully slow as it is...Roids would be orders of magnitude worse)
  19. Missed ya Ges, Rhetorical question for your niche case though....the OP specified a 6h orbit. So, can you get an Ap past the Mun in that situation to cause this issue? (On larger orbits, sure, hang time for a highly eliptical where the Ap is just inside the SOI and an atmo scraping Pe....could happen. But it's a minutia that I personally wouldn't design on.) If the OP Is interested specifically in the Math, there's a vid here that explains the process of figuring it out. Snark: I'm not sure if the OP had a specific design issue in mind, or if there's just an innate curiosity. However, the charge and designing for operation of a solar powered craft in dark periods can be a consideration for players who have particular power needs, are using mods which require powered craft to be in operation for scanning and the like, or if they want to be able to maintain some kind of orbital effects during actual flight. Especially if someone is trying to shave funds off their missions...then why pay for more batteries than you need??
  20. Basically your worst case (at whatever the worst time of year is) for an inclined orbit won't be any different than you'd see on an equatorial orbit, as the size of kerbin will cast a shadow across the same angular distance for any other orbit on that altitude. IIRC, the KEOSYNC dark time is only about 20 minutes for a circular orbit. The only variance that you might see with a Elliptical orbit, is that the hang time near the Ap could result in a longer period of darkness, where the Ap was positioned roughly centre over the darkside equator... but again, inclination will not affect how often that comes into play, nor for how long.