jkool702

To help with science grind, i reccomend installing [X]science mod. This lets you know what science is available in your current biome, and makes the "collect data everywhere" part much more efficient. For funds, if you get tired of repeating the same contracs over and over (in particular the "take tourists to kerbin orbit" and "launch a satellite to kerbin orbit" ones) download mechjeb and let it automate it. I'm a big believer that you should try to do stuff first without mechjeb's help, but once youve repeated something 20 times and could do it in your sleep mechjeb helps reduce the grindyness of doing it again.

This may not directly help your problem, but its good to get in the habit of disabling one battery pre-launch. Then, if you find you run out of electricity for whatever reason, you have one battery you can manually enable/disable as needed to make maneuvers, stage, etc. I've noticed that electricity has a tendency to slowly drain for no reason, so an alternate method would be to have all electricity sources enabled/disabled by some hotkey, then only enable them when you want to do something. Batteries cant be drained when they are off.

When you say you dont want to refuel in the mission does that also mean you would be against having an ISRU on the lander and topping off the lander on Laythe? In 1.0.2 I built a huge lander with 8x rockomax 64 tanks (the orange ones) and 32 aerospikes (4 on each tank) specifically for a laythe landing that is capable of doing what you are asking and more. Since it can top off on the ground it can visit multiple biomes, and it has the TWR and deltaV to get a VERY large payload off the ground and back into laythe orbit.

So I'm not familiar with kOS, but i have an idea you might be able to try. I think the cross product you would need to take is (vector to center of kerbin) x (current velocity vector) (note that these might need to be reversed or else it might be off by a negative sign). You seen to be able to get the vector to the center of kerbin, maybe there is an easy way for kOS to pull up a vector describing your current velocity? If not, maybe you can numerically approximate it? i.e. make vector from position(@t=t0) to position(@t=t0+eps)?

One suggestion I didnt see yet is to download the Kerbal Joint Reinforcement (KJR) mod. In some of my KSP monstrosities that i've built the part count is high in large part due to having an unreasonable amount of struts. KJR, as the name suggests, reinforces joints and makes it so you need far fewer struts (often no struts at all), decreasing part count significantly. Also, someone mentioned welding and linked UbioZur's welding mod. The mod page says its not compitable with anything after 0.90 (Tho it says its apparently being worked on - hopefully). Are there any welding mods that are compatible with the most recent versions of KSP?

So unfortunately what you're asking isnt particularly easy to calculate by hand. You know that old expression "Well, at least its not rocket science"? Well, this IS rocket science. I admittedly am not a rocket scientist, but am pretty good at math and physics, so i'll give you a list of steps you would need to do to get a pretty decent approximation. Im not sure if this is the "right" way to do it, but this is what I would do, and if anyone believes this is incorrect please say so. I'll tell you what equations you need to use and you can google them. For launching: 1) Figure out how much delta V you have. Use the Rocket equation for this. You will need to repeat for each stage. 2) Figure out how much horizontal delta V you need. Balance the force of gravity at a particular radius with centripetal force at that radius and solve for velocity. Make sure you account for the fact that the planet may be spinning (IIRC Kerbin spins at something like 200 m/s - this will reduce delta V needed for an equatorial orbit) 3) Figure out how much vertical delta V you need. This is tricky. Use gravitational potential energy to find out how much energy you need to get to a particular altitude. Convert this energy into kinetic energy to find out how much velocity you need. Use impulse-momentum theorem to determine actual delta V, corrected for gravity losses and based on TWR ratio. You will need to integrate this since mass is constantly changing on your ascent. Note that if atmosphere is present thrust also changes as a function of altitude. Note this disregards air resistance, so this would be more valid for ascents that dont approach terminal velocity. If you could figure out an approximate drag curve integrate it to get total drag and use this in the impulse momentum equation to get a better delta v estimate. 4) Combine vertical and horizontal delta V. Depending on ascent profile i think total delta v needed will be between (Vx + Vy) and sqrt (Vx^2 + Vy^2), though id imagine closer to (Vx + Vy). If you dont account for air resistance delta V will be more. Change orbits (no plane change) 1) Figure out energy for initial and final orbit, and then change in energy (google energy in an elliptical orbit). This is change in potential energy. 2) Convert this change in potential energy to a change in kinetic energy. Note that delta V required for a certain change in kinetic energy depends on your current velocity - this is why it is more efficient to change orbits at certain points (most notably the periapsis (highest velocity) and apogee (lowest velocity)) Change Planes 1) Use trigonometry to find the change in velocity in the X direction and the Y direction (you can assume the X direction is in the same plane as your current orbit, and the Y direction is perpendicular to it). This will be based on your current velocity. Call these Vx and Vy 2) delta V is between (Vx + Vy) and sqrt (Vx^2 + Vy^2) TL;DR manual calculations for plane changes and orbit changes are pretty easy, though the game provides these delta V values via maneuver nodes. Calculating a launch on a planet with no atmosphere is hard but doable (requires calculus). Calculating a launch on a planet with atmosphere is very hard, and you would be better off using a cheat sheet for that.

I didn't realize this when I first started using the Mobile processing lab, and was also wondering why the rate of return was so low. As soon as I figured this out I VERY quickly maxed out my tech tree with thousands of science to spare!

I actually prefer a method which hasnt been described here yet - I keep the fuel tanks in orbit and send down a lander with drill and ore tanks, but put the ISRU on the lander (rather than in orbit). This works particularly well for large landers since the addition of the ISRU is a (relatively) small amount of weight (My last minimus lander for this purpose held 21,000 units of ore), and has the big advantage that the lander can refuel on the surface so it always leaves the surface with full tanks. This is particularly advantageous if you tend to be overly cautious with suicide burns, since you can afford to be be very fuel inefficient on the way down. This way may not be the most efficient in terms of "Amount of ore wasted" or "in game time used", but I feel it is the most efficient in terms of "real world time used".

I'd somewhat agree with you then the space tourism contracts can get kind of annoying, but I've never had trouble making money off of them. Do you have funding rewards turned down?

I've had this issue as well. May be associated with having a probe on board, although I feel power usage should still be zero if you arent using the probe. One way I've found around this is to manually turn off any batteries you have on board, and turn them back on when you need them.

are there any mods which re-tool atmospheres such that they actually taper off into nothingness instead of (in the case of Jool and to a lesser extent Eve) having substantial atmosphere just below the limit of space?

As many people (including myself) have indicated - we learned how to do this without using mechjeb first, and only used mechjeb to do it after this part of the game was second nature. Once you can do this in your sleep its becomes tedious, not fun, to continue to do over and over again. At this point the part of the game where you "learn something new" is (for me) heavily based on designing ships that can do difficult tasks. Take launching from Eve for example: the challenging part isnt actually piloting the take off, but rather designing a ship that CAN take off from Eve and getting that ship to Eve's surface is what is challenging and fun. So, without telling anyone how they should play the game, id recommend that you should learn how to do stuff without mechjeb, and once you completely understand it and dont get enjoyment from adjusting an orbit or taking off or landing for the 1000th time let mechjeb automate it and switch your focus to other aspects of the game.

Thanks for the reply. I kind of expected that hyperthreading made little to no difference, but figured someone out there had actually tested it out. And yes I'm very hopeful that 1.1 will bring nice performance gains. My i7 seems severely under-utilized right now :/

Are there any mods for the current version of KSP (1.0.4) that weld/fuse joints to reduce part counts? I looked for Ubizor's mod after seeing this thread and couldnt find it updated for anything past 0.90.

In not sure if this sub-forum is the right place for this, but my question is: Does hyperthreading (on intel CPU's) make a difference in performance in KSP? Since KSP performance is more-or-less limited by single thread CPU performance it seems like splitting a single physical core into 2x logical cores might have detrimental effects on performance? I looked into this issue for running matlab codes that were compute limited a while back and pretty much came to the answer that "System resource monitors will show 1/2 as much CPU utilization with hyperthreading enabled, but performance is essentially the same." Does anyone know how this effects KSP?

If you install the mod [X] science! it'll tell you which biome you are currently in and which experiments are available. Very handy, and seems like it could clear up a lot of this KSC biome confusion

I've had this exact same issue - SAS simply brings the craft to the wrong vector. Its not an issue of lack of SAS / reaction wheels, since you can still manually steer correctly. I also seem to remember it did a decent (but not perfect) job at holding the current heading, but prograde / retrograde didnt work at all. I dont know WHY this happens but can confirm its not an isolated incident in 1.0.4. I've also had a similar problem as this in 1.0.2, making me think this is a long standing bug. I dont think this it tied to a specific SAS unit, as when this happened to me a lvl 2 Jeb was piloting and I didnt have SAS iirc. It also doesnt sem tied to RCS use, as I had RCS off (asnt even on this craft) and it still happened. The only thing that fixed this for me was actually returning the flight to kerbin and recovering and launching a new flight. Resetting the game didnt work, but thankfully my next flight worked correctly. EDIT: I also seem to remember that when I turned SAS off this craft would decide to pitch up and rollaround in circles for no reason whatsoever (like I was holding "s" only I wasn't). Dont know if this is a related bug or if that craft was just kraken bait.

Mechjeb, though I fervently believe in doing everything without mechjeb initially until its second nature. Only switch to mechjeb when hard, challenging and fun turns into tedious and boring.

I could be wrong, but I think thats exactly what it means... Rocket eq: delta_v = ve*ln(m_initial / m_final) EDIT: I think what you may be thinking of is that doubling the rockets and leaving the payload the same will not double delta_v, due to the natural logarithm in the rocket equation. doubling the amount of rockets and the payload: m_initial --> 2*m_initial m_final --> 2*m_final new rocket equation: delta_v = ve*ln(2*m_initial / 2*m_final) = ve*ln(m_initial / m_final) Hense, double the rockets equals double the payload. Alternately you could think of shooting up two individual identical rockets with identical payloads, and then just strutting them together. Double the rockets and double the payload. Note the above logic ignores strut weight, so doubling the rockets does result in just under double the payload, unless you use certain mods (such as KJR).

So I realize that Earths atmosphere doesnt just "cut off" like in KSP, rather there is a gradual transition into less and less air pressure until it is effectively the same vacuum as in interplanetary space. In KSP i tend to think of the edge of the atmosphere at the point in which orbits are indefinitely stable, so I guess what I'm actually asking is: "At what height would a satellite in an circular equatorial orbit of Earth need to be such that the orbit does not effectively decay over the course of many, many years (say a human lifetime)?" Some numbers I found from a quick google search 100 km: where "space starts" 380 km: googles answer to "how tall is earth's atmosphere" 400 km: ISS orbit height ~600km: end of thermosphere / start of exosphere 10,000 km: end of Earth's Exosphere, where it is pretty much impossibly to distinguish the air from the vacuum of interplanetary space. (seems to be some variations on this altitude?) Since the ISS isnt entirely stable (needs help to stay in orbit), I'd guess the answer to my question is somewhere between 400km and 10,000km. I guess 10,000km would be the more official "end of atmosphere" height where orbits would be 100% stable almost forever, but I'd imagine that orbits much lower would be stable for a very long time (by human standards).

because MOAR BOOSTERS sounds better than more solid rocket motors

I had this happen on the ship i used 2 mun missions ago - during the flight it started wobbling then wobbled more and more and more until it tore itself apart for no reason at all. This happened 5-6 times. Thank goodness for quick saves. Of course my next mun mission was even worse - SAS didnt work at all, without touching the controls the ship would go full pitch up and go into spins, things exploded at 50k feet in reentry when they were only 300 degrees.... TL;DR The kraken is alive and well.

I have a very similar ASUS laptop, but a couple generations older (i7-3610QM, gtx660m) and I have found the CPU runs at about 80 C and the GPU runs at about 85 C when under load. Ive come to accept these is just normal operating temps

Today I made my first Mun mission in my new career (restarted with 1.0.4). It went very well... Well, there was this issue where my ship was apparently Kraken bait and spontaneously disassembled itself 5 or 6 times during the trip, but OTHER than that it went very well. Thank goodness for quick saves.

I never knew that...I always assumed you would still have to unlock it in the tech tree first. Good to know.