michelcolman

For some reason, if I pause full-screen KSP and switch to another application (KSP invisible in the background), KSP keeps using an enormous amount of system resources. My laptop remains very hot and the fan keeps running at max speed even though the physics are paused, the scene is not changing and the window is not even visible. I think the graphics engine continues to run and composite the same scene over and over again even though it's invisible. If at all possible, could you stop the graphics engine while the game is invisible in the background? I'm running on a 17 inch Apple MacBook Pro, and you could literally use it to bake eggs if I leave KSP paused in the background. I understand it gets hot while playing, but I shouldn't have to quit the game completely to do other stuff temporarily and let the computer cool down a little. Thanks in advance! Michel

SAS is indeed awful, but it looks like this should be very easy for Squad to fix. Current stock SAS flaws (and partial solutions): - When you turn on a guidance mode (e.g. maneuver), it often starts to turn in the wrong direction initially (up to perpendicular to the required direction), then makes some kind of arc that circles around the target. Strange, because the maneuver arrow is pointing in the correct direction so the SAS should know which direction to apply torque in! - It keeps accelerating towards the target direction, overshoots it, then comes back, overshoots again, etc... This, too, should be easy to fix. You know how much torque the reaction wheels can produce. When the rotational speed and angular distance to target are such that max torque would slow it down just in time to come to rest at the target angle, stop accelerating and start decelerating. If angular distance is delta, rotational speed is omega, and max angular acceleration is alpha, then you should start decelerating when delta < 1/2 omega^2/alpha. Maybe start at a slightly larger delta and calculate alpha from delta and omega to avoid missing the target due to rounding errors. If you're not directly on course to the target direction, split up the angular velocity in a component towards the target and a perpendicular component and give each a "budget" of alpha/sqrt(2). When the deviation is small (both delta and omega), use only a small alpha but increase it when necessary due to aerodynamic forces. - It uses a lot of electricity since it's constantly applying large correcting inputs while chasing the target. Like some people indicated, MechJeb has a much better SAS but it's also quite a bit slower. I think it uses a simple speed feedback loop to limit the speed towards the target. Certainly works a lot better than stock, but I often end up helping it to get there more quickly.

Why manipulate the save file? Unlocking the tech tree as quickly as possible is an extra difficulty that makes the challenge that more interesting. Career would be even better, although that would of course introduce an element of luck since many of the contracts are random. But having to work for the money to build the rockets, trying to launch as many simultaneous missions as possible, upgrading the buildings at the optimal time,... now that's a challenge.

I'll try that some time this week. I already had the problem before I installed MechJeb, so I'm pretty sure that doesn't have anything to do with it. Should I also enable verbose output?

Here's another log, with severe stuttering (2 fps) starting at 16:55:50. Nothing in the log suggests any problem at that particular time. https://www.dropbox.com/s/4jlkyvii01tz4am/KSP%20log%20with%20stutter%20from%2016h55%2050s.log?dl=0 Shortly after the stuttering started, I paused, put the computer to sleep, woke it up again, and as usual everything was smooth again. Oh well, if I'm the only one experiencing this, I guess I'll just have to live with it.

Here are two log files. With the first one, I noticed the stuttering problem at 15:33 but it may have started earlier, I had been in the map most of the time. I then put the computer to sleep and woke it up again. Problem gone. There's a whole bunch of NullReferenceExceptions starting around 15:42 but that was after the sleep and everything was smooth at that point. https://www.dropbox.com/s/lnz60jmcgbaejqi/KSP%20with%20bug.log?dl=0 The second log file was from a session that was smooth the whole time. It has some Steam errors because I started the app directly instead of going through Steam (but I've had this stuttering problem with or without Steam). https://www.dropbox.com/s/7buzgcrn7v8pish/KSP%20without%20bug.log?dl=0 Hardware info is here: https://www.dropbox.com/s/2wxedmrw7lfjhry/MacBook%20Pro.spx?dl=0 If I can get a session where I can pinpoint the start of the problem more precisely, I'll send the log here as well. Thanks for any help! Michel

I don't think the framerate problem is related to overheating, because it goes away after just seconds of sleep, and is then often OK again for half an hour even when the laptop feels even hotter than before. Sometimes it starts again after 10 seconds, but sometimes I can keep playing for a really long time with no issues. I'll see if I can get those log files sal_vager asked about. You mean KSP.log, right? I can't find any "player.log". I'll run the game again and note exactly when the stuttering begins so I can tie it to some event in the log. Below is a copy of all the errors and warnings from the last log file (not sure if it contained a stuttering episode or when that would have started, but maybe something catches your eye already). I only included every warning once even if some reoccur multiple times. I left out some warnings about Steam not being initialized because I usually just run the app directly without going through Steam. But the stuttering occurs regardless whether I launch through Steam or not. [ERR 16:42:20.042] WheelCollider requires an attached Rigidbody to function. [ERR 16:42:24.122] PartCompiler: Cannot clone model 'Squad/Parts/Aero/shuttleWings/elevon' as model does not exist [ERR 16:42:24.122] PartCompiler: Model was not compiled correctly [ERR 16:42:24.122] PartCompiler: Cannot compile model [ERR 16:42:24.122] PartCompiler: Cannot compile part [ERR 16:42:27.617] The hull has more than 255 polygons. This is invalid. [WRN 16:42:27.681] PartLoader Warning: Variable density not found in Part [WRN 16:42:29.970] PartLoader Warning: Variable buoyancySplashPartOriginLerp not found in Part [WRN 16:42:31.229] HighlightingSystem : Edge Highlighting requires AA to work! [WRN 16:42:31.229] HighlightingSystem : Highlighting System has been disabled due to unsupported Unity features on the current platform! [WRN 16:42:29.970] PartLoader Warning: Variable buoyancySplashPartOriginLerp not found in Part I'll send a more complete log and system info later when I find the time. Thanks! Michel

Hi everyone, When I'm playing KSP. after a short while everything slows way down and I can only get around 2 fps even for extremely simple ships or even when just looking at the space center. Clicking on items becomes almost impossible, most clicks seem to get ignored completely and you have to keep trying until it registers. The entire computer gets slow: if I cmd-tab to the desktop, the dock and all other animations are just as stuttery. But everything is butter-smooth again the moment I quit KSP. Sometimes it starts again right away when I relaunch KSP (even the main menu with the yellow text lines stuttering into place instead of sliding smoothly). What's even weirder: every time I have this issue, I close the lid of my laptop, wait until it goes to sleep (which takes longer than usual, up to a minute or so), then open it up again, and all of a sudden the game is smooth again. Really smooth, like 60 fps or so. Sometimes it starts stuttering again shortly afterwards, so I repeat the sleep trick and it's OK again. After a couple of times, it stays smooth for a much longer time, I've been able to play for half an hour or so with smooth animations. Any ideas what might cause this? I have a MacBook Pro 17 inch mid-2010, 2.66 GHz Intel Core i7, 8 GB of RAM, SSD, Intel HD Graphics 288 MB and NVIDIA GeForce GT 330M 512 MB. I know it's getting a bit old, but most of the time it can handle the game just fine, and the stuttering is totally unrelated to workload. It gets really hot while playing KSP, but that does not seem to be related to the stuttering since, after a few seconds of sleep, it's smooth again and sometimes remains smooth for half an hour while still being very hot. Thanks for any insights, Michel Colman

When you fly a rocket using a joystick, it makes sense to have the two primary axes of the joystick coupled to pitch and yaw, and the twisting axis of the joystick coupled to roll. However, when you're flying a plane, you want the primary axes to be pitch and roll, with the rarely used yaw coupled to the twisting axis. Right now it takes a trip to the main menu settings menu to change these settings (it's not even available from the in game settings menu). Ideally we should be able to quickly switch between the two ways of controlling craft. The main menu input settings menu already has different settings for "flight" and "vessel", maybe you can make that "plane", "rocket", "rover"? And it would be great if we could pick the control setup from a context menu on the part. Airplane cockpits would default to "plane", but if for some reason you stick one onto a rocket, you could switch the controls to "rocket" by right-clicking on it and choosing that option. Or, as an alternative, a quick toggle switch to swap roll and yaw? (which is remembered for each individual cockpit/pod so you don't have to toggle every time you switch to a craft of the other type)

Cheating would be a problem, of course. Mods certainly could be disabled, but that wouldn't keep people from modifying the original game using a different method. I would suggest that the game would send a detailed log of the entire flight and this would be downloadable and replayable by anyone. This would serve a dual purpose, being very educational and catching cheaters. No need for anyone in particular to police it: whenever a suspicious record appears, people will replay it and flag it if it's a cheat.

Oh, no mods of course. Challenge mode would disable mods (or be unavailable if mods are present), and each challenge could have a list of allowed equipment (no asteroid mining for minimum fuel missions, for example). There could also be separate categories for records with or without quicksaving. It would be interesting to see what the KSP community can come up with to break records. To fly to the Mün and back in the fastest time, one might use a huge rocket with lots of TWR and delta-v, fire straight up when the Mün is almost overhead, keep accelerating until the last moment, switch to a second set of engines that's pointing the other way to avoid wasting time turning around, do a suicide burn, jump out before the rocket even touches the ground (hard, right at the limit of the landing gear), get the sample, jump back in, fire straight to Kerbin, just enough braking to avoid burning up, parachutes at the last moment (or a retro burn if you could cram all that fuel into the original rocket), recover just as the vehicle touches down. And then at the other end of the spectrum, somebody flying by all the planets one by one with a single smallish rocket using a ridiculously small amount of fuel slingshotting all over the place, with other people going "What? I need that much fuel just to get to Minmus!". Yes, "fly by all planets" should definitely be a challenge.

Feature suggestion: I think it would be a good idea to introduce some sort of online competition with leaderboards for specific challenges. For example: - Take off from Kerbin, get a surface sample from the Mün and get it back to Kerbin with the lowest amount of fuel (fuel in vehicle at launch), or the fastest time, or the cheapest rocket,... - Fly to Gilly and bring back surface samples from all three biomes with the lowest amount of fuel, fastest time, or cheapest rocket - Fly to Eelo, pass at less than 100 km and come back to Kerbin (fastest, cheapest,...) This would lead to lots of competition and possibly new discoveries on how to fly most efficiently. Instead of just taking "enough" fuel, you'd really try to minimize the budget as much as possible and get there and back on vapours, using lots of gravity assists etc. You would need some kind of verification, for example a recording, to catch cheaters. Whenever someone breaks a record, the recording would be sent as well.

1. Of course joint reinforcements help, but I can get a wobbly ship to orbit while MechJeb blows it up. I think it could do with some more damping, or some kind of detection of wobble. It looks like it gets into dynamic instability, overcorrecting for position deviations and making the oscillations larger. When I'm flying manually, and the ship is wobbling left-right, I actually give a right input when the ship is pointing to the right (and needs to go to the left) because I know it will go to the left by itself and I just want it to slow that motion down. MechJeb will give an input to the left and increase the amplitude of the oscillation. But I know this is not an easy thing to program, so I can't really be too harsh on MechJeb for that. 2. Where is that precision rate setting? I don't remember setting a precision rate anywhere, I've just now tried to look for it but I can't find it in any of the windows. In any case, I don't see any need to cycle between full throttle and idle. When I want to fine-tune the apoapsis, I cut the throttle just before, and then add a tiny little bit of thrust to add the last few meters. I actually get better precision than MechJeb (on a simple rocket that MechJeb doesn't blow up). Why would you ever go back to idle, back to full, back to idle, back to full again, etcetera in rapid succession? I'm not exagerrating, the large rocket blew up because of longitudinal compressions (not bending but squeezing) 3. Indeed, once I figured that out it worked correctly. Although you need to use some common sense: today I asked it to execute a maneuver to escape from Kerbin orbit with nuclear engines, it started 10 minutes before the maneuver. pointed the nose towards kerbin (since it was about 90 degrees before the node), entered the atmosphere and burned up. I kind of guessed it was going to do that and sure enough, it did. 4. I'll give that a try, thanks. Inserting to a safe speed first, then switching on the precision landing part for the last bit only, sounds like it may work rather well. 5. I see it regularly after take-off. A bit of blue orbit comes off of Kerbin, then there's a gap, then the top part of the orbit curving back down, then another gap exactly symmetrical to the first, then the last bit of orbit down to the surface. I don't think I ever saw it before installing MechJeb. Doesn't really bother me, it's just strange. But once again, it really is an extremely useful tool as long as you remember that's what it is. It helps you a lot, but you still need to be a pilot.

I do understand the balance issue. In fact I couldn't have phrased it better. Maybe the science tree could unlock some sort of science automation module so you only have to do those tedious bits a few times. On the other hand, it's a game so I guess I can live with the clicking. My original point certainly remains valid in my opinion: if a scientist takes data from an experiment, don't warn him that you need a scientist to reset it afterwards. Just reset it right away. But maybe that's already been planned for 1.1 in the "small menu changes".

I just installed and tried out MechJeb yesterday. My experience: - On a wobbly ship (4 stages, just a few struts but probably not enough), ascent autopilot wobbles a lot, I can do a much better job myself with less control inputs following the target guidance better than the autopilot does. I had to restrict dynamic pressure because otherwise the ship would blow up due to excessive wobble. - For some strange reason, when the first stage was almost empty and apoapsis was nearing its 80 km target, it suddenly started cycling engine power between idle and full several times in rapid succession. This caused a longitudinal compression oscillation that blew up the ship spectacularly. Retried several times with the same result. The craft has 4 stages with the first stage containing 7 Mammoth engines. I don't think the real Jeb would ever cycle those engines up and down like that ;-) - Sometimes maneuver nodes won't execute automatically, but I need to experiment a bit more to figure out what's going on. I made a maneuver, adjusted it with MechJeb, armed maneuver execution, then used warp (manually) until a couple of minutes before the 1 minute maneuver, and then waited. Nothing happened But maybe I did something wrong, Ive only tried this once. - Autoland blew up the rocket due to aerodynamic heating. It just lowered the orbit from an 80 km circular orbit to an intersection with the surface at KSC and then used the rocket engines to accelerate during the descent. Had me frowning my eyebrows but I let it continue anyway, and then I turned out to be right. - Sometimes parts of the blue trajectory line on the map disappear, with two "holes" in the blue line. I never saw this happen before I installed MechJeb, so I suspect MechJeb might have something to do with it, but I'm not sure. Other than that, it certainly is a great and useful mod! Node editing is terriffic, ascent guidance is very educational (I was doing way too little gravity turning apparently), you just have to use common sense and use it only where it's appropriate. Autopilot to be used with caution.

I'm a relative newbie, so this is probably not going to impress anyone, but I was still pretty proud of this special delivery to the R&D Facility. No mods. Took me a couple of attempts, obviously. First one in the water a mile or so from KSC, second in the grass close to the coast, then one on the runway (not exactly convenient to leave it there), then on the roof of an R&D building (which would have been great if the whole thing then hadn't tipped over, fallen off and blown up some fuel tanks next to the building), and finally in an acceptable spot on the concrete. Probably not the best skycrane to do this sort of thing with, it rotated like hell when I engaged the thrusters and then, once above the KSC, I had to be very creative to move it in any particular direction for the exact landing spot. While dangling from the chutes, full thrust for a few seconds so the whole combination went back up and started tumbling like crazy, then short bursts of full thrust every time the engines happened to be temporarily pointing more or less in the right direction, then finally let it come down again when it was above the right place. But hey, I made it and nothing blew up! Too bad you only get science points for samples, and nothing for bringing in an actual complete asteroid. So I disconnected and recovered the craft while leaving the asteroid there. It did yield one nice advantage I hadn't thought of beforehand: it's now really easy to find KSC on the map since it's marked with the unrecovered asteroid!

There are quite a few hidden settings in settings.cfg that are very useful even though they are considered too complicated for novice users. However, it would be great if we could assign hotkeys to those hidden settings by editing the settings.cfg file so we don't have to quit, edit the settings, then start the game up again. For example INCREMENT_CONIC_PATCH_LIMIT { primary = SingleQuote secondary = None } Anything starting with "INCREMENT" increments the variable name behind it, anything starting with "DISABLE" sets the variable to false, etc. By default none of these would be present in settings.cfg, but users could add them as they saw fit. Novice users never even need to know, so it won't confuse anyone. And it's probably easy to implement as no UI is necessary (apart from a simple one line green text message as confirmation)

It would be nice if we could disable the automatic fuel crossfeed system that always steals fuel from the closest adjacent tank. You can choose whether or not fuel passes through a decoupler, but there's no such option for crossfeed between tanks. My second stage was a bundle of 7 orange tanks with Mainsail engines, but some of those tanks were probably considered to be "closer" to certain particular other tanks due to tiny floating point rounding errors. The result was that some tanks were running out more quickly than others, and I suddenly got an asymmetric flameout with empty tanks on one side and half full on the other. I know I could solve it with fuel lines, asparagus staging etc. (and I probably will since it will be more efficient), but it would have been nice to simply disable this crossfeeding. Just add an option to each fuel tank to optionally isolate it from adjacent tanks, like the option to let fuel pass through a decoupler or not.

When a scientist takes data from the mystery goo, he gets a strong warning "this module can only be restored by a scientist!". Duh, I am a scientist! This warning would be appropriate for a pilot or engineer taking the data, but certainly not when the data is being taken by an actual scientist? The warning should probably be omitted when it's a scientist taking the data, or at the very least phrased differently. Maybe even restore the goo automatically, since there's no good reason a scientist would intentionally take data and not restore the goo afterwards. (Same goes for Science Jr., obviously)

I sometimes have a hard time planning an encounter with an object, because the encounter indicators often disappear for no reason, showing a different (and often less optimal) encounter somewhere else instead. For example the day before yesterday, I was doing the first asteroid redirection tutorial and trying to zero in on an encounter at the second intersection with the asteroid orbit (with a fresh maneuver node, not the given one). When I tried to optimize that encounter, it turned out to be impossible to achieve. I kept getting closer, 2 km, 1.5 km, 1.2 km, and then with a tiny extra tweak which I was hoping would get me to within 1 km, the encounter indicator disappeared and jumped to the first intersection instead, with a distance of more than 10 km there. I did not accidentally make a big correction, because a tiny tweak in the other direction brought back the first encounter, but I could never properly line up that one. It kept disappearing so I couldn't get it close enough. Even worse was when I was doing it with maxConics set to 7. The planned orbit went through the asteroid orbit twice (two possible encounters), and then passed by Mun into a new purple orbit which went by the asteroid again. When I was trying to zero in on an encounter on the first orbit (getting close to 1 km), the encounter indicators suddenly jumped to the purple line way in the future! It was impossible to line up an encounter on the first orbit. In the first case I thought a perturbation by the asteroid on the first passage might be to blame (although it shouldn't, since it has no gravity at all), but in the second case that's totally impossible as it prefered to show an encounter on the second, purple orbit rather than the much closer one in the immediate future. Is there any logical explanation for this behaviour, or is it just a bug? (I know, I'll give MechJeb a try, but for the moment I just want to get the hang of stock KSP before spoiling myself with automatically calculated trajectories) By the way, another bug that often happens (and I seem to remember being discussed on the forums as well), is when sometimes it's impossible to add a maneuver node to the blue line and you can only add one to the purple line years in the future. Sometimes you can still find a spot on the blue line that accepts a click (close to the periapsis often works, but not always) and then drag it to the spot you want. But quite often even that doesn't work. I hope that will be fixed in the next version? Thanks, Michel

If you fly out to an asteroid and bring home a sample, you get some science points. But today I brought back an entire asteroid, actually landing it gently right in the middle of the Research and Development Department, and when I recovered the craft I got nothing extra! I just got 60 points from the sample I took, but nothing for bringing home the actual asteroid. Surely lots of science can be done with an entire asteroid brought back from space? If you can't give any science points for the asteroid itself for some reason, at the very least increase the multiplier for taking a sample at any of the Kerbal Space Center biomes! The same 60 points as for a sample in orbit was kind of a let-down. Thanks!

OK, I suppose when I first tried it, my pilot didn't have any experience yet. Should be OK now after several Mun missions. I'll give it a try, thanks!

I must have misunderstood something about SAS, because I thought you needed some sort of extra equipment, like the CG-J3, to enable it? The Mk1 by itself doesn't have SAS, does it? The science page lists a number of different pieces of equipment that offer SAS, often only partially (prograde/retrograde, for example). I picked the CG-J3 because it has prograde, retrograde and maneuver. As a side note, I always wondered why you can't just ask the pilot to hold prograde or maneuver direction. I mean, they are pilots, right?

No, I'm sure SAS is draining the batteries. I don't have solar panels, just batteries, a basic Mk1 pod, a CH-J3 fly-by-wire avionics hub, fuel tanks, engines and separators. With batteries full, engines off, SAS on, the batteries slowly drain (which is normal, using the reaction wheels). If I activate warp, they continue to drain (at a rate multiplied by the warp factor, i.e. a matter of seconds at high warp factors). If I go back to x1 warp, turn off SAS, then activate warp again, battery levels remain constant no matter how long I warp. Now I do feel it's normal that SAS drains batteries *if it works*. But if it doesn't actually work during warp, it shouldn't be consuming energy. And in any case, drained batteries can be such a show-stopper that a warning would be more than welcome. I lost count how many times I lost a mission because I accidentally left SAS on.

When I used the word "target", I meant whatever target direction the SAS system has been tuned to. Prograde, normal, maneuver, whatever. When it's not already pointing that way and, for example, you switch it to hold prograde, it starts turning towards prograde but then overshoots it horribly, comes back, overshoots again, etc, until finally stabilizing. Almost invariably, I actually need to counteract its inputs. While it's rotating to the right and approaching the symbol, I have to push "A" to slow it down before it gets there (or cheat by activating and deactivating time warp when it passes through the desired direction). Otherwise, on a relatively large rocket using standard pod control wheels, it takes forever to stabilize.