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?